Архитектура fxTunnel: как устроены безопасные туннели на Go

Обзор архитектуры fxTunnel

fxTunnel — open-source инструмент для безопасного туннелирования HTTP, TCP и UDP трафика, написанный на Go. В основе лежит клиент-серверная модель: клиент инициирует исходящее соединение к публичному серверу, а сервер маршрутизирует внешний трафик обратно. Горутины Go мультиплексируют тысячи соединений через один зашифрованный канал, а сама система делится на три слоя — data plane (передача трафика), control plane (управление туннелями) и transport layer (HTTP, TCP, UDP).

На практике это означает: один бинарник без зависимостей, который обрабатывает разнородный трафик — от HTTP-запросов и тестирования вебхуков до UDP-датаграмм для игровых серверов. SaaS-сервис на fxtun.dev работает из коробки, а self-hosted вариант доступен для тех, кому нужен полный контроль.

Компоненты системы fxTunnel

Система состоит из трёх компонентов: CLI-клиент, маршрутизирующий сервер и control plane. Клиент открывает TLS-соединение изнутри сети, обходя NAT и файрволы. Сервер мультиплексирует тысячи потоков через одно соединение и маршрутизирует трафик по домену (HTTP) или порту (TCP/UDP). Control plane управляет жизненным циклом туннелей через heartbeat-мониторинг.

Клиент (CLI)

Клиент fxTunnel — это CLI-приложение, которое устанавливает зашифрованное соединение с сервером и пробрасывает трафик на локальный порт. Он инициирует подключение изнутри сети, поэтому NAT и файрвол не создают препятствий. Архитектурно клиент выполняет три задачи: аутентификацию, поддержание управляющего канала и мультиплексирование данных.

┌─────────────────────────────────────────────┐
│  fxTunnel Client (CLI)                      │
│                                             │
│  ┌───────────┐  ┌──────────┐  ┌──────────┐ │
│  │ Auth      │  │ Control  │  │ Data     │ │
│  │ Module    │  │ Channel  │  │ Mux      │ │
│  └───────────┘  └──────────┘  └──────────┘ │
│         │              │             │      │
│         └──────────────┼─────────────┘      │
│                        │                    │
│              ┌─────────▼────────┐           │
│              │  TLS Connection  │           │
│              └──────────────────┘           │
└─────────────────────────────────────────────┘

Пример запуска клиента:

# HTTP-туннель — проксирует HTTP-запросы на localhost:8080
fxtunnel http 8080

# TCP-туннель — пробрасывает TCP-соединения на localhost:5432
fxtunnel tcp 5432

# UDP-туннель — передаёт UDP-датаграммы на localhost:27015
fxtunnel udp 27015

Клиент автоматически переподключается при разрыве соединения и поддерживает heartbeat для раннего обнаружения проблем с сетью.

Сервер (маршрутизация и мультиплексирование)

Сервер — центральный компонент, который принимает подключения от клиентов и маршрутизирует внешний трафик. Каждый входящий запрос сервер сопоставляет с зарегистрированным туннелем по URL (для HTTP) или порту (для TCP/UDP) и пересылает данные соответствующему клиенту через мультиплексированное соединение.

┌──────────────────────────────────────────────┐
│  fxTunnel Server                             │
│                                              │
│  ┌─────────────┐    ┌─────────────────────┐  │
│  │ HTTP Router │    │ TCP/UDP Port Router │  │
│  │ (по домену) │    │ (по номеру порта)   │  │
│  └──────┬──────┘    └─────────┬───────────┘  │
│         │                     │              │
│         └─────────┬───────────┘              │
│                   ▼                          │
│         ┌──────────────────┐                 │
│         │  Session Manager │                 │
│         │  (мультиплексор) │                 │
│         └────────┬─────────┘                 │
│                  ▼                           │
│         ┌──────────────────┐                 │
│         │  Client Pool     │                 │
│         │  (TLS-соединения)│                 │
│         └──────────────────┘                 │
└──────────────────────────────────────────────┘

Ключевые особенности серверной части:

• Мультиплексирование — множество логических потоков данных проходят через одно физическое TCP-соединение, что снижает overhead на установку соединений.
• Маршрутизация по домену — для HTTP-туннелей сервер анализирует заголовок Host и направляет запрос нужному клиенту.
• Маршрутизация по порту — для TCP/UDP-туннелей сервер выделяет публичный порт и перенаправляет весь трафик на этот порт клиенту.
• Горячая перезагрузка — добавление и удаление туннелей происходит без перезапуска сервера.

Control plane (регистрация и heartbeat)

Control plane отвечает за жизненный цикл туннелей: регистрацию, мониторинг состояния и корректное завершение. Он работает поверх того же TLS-соединения, что и data plane, но использует отдельный логический канал.

Жизненный цикл туннеля:

1. Аутентификация — клиент отправляет токен, сервер проверяет его.
2. Регистрация — клиент запрашивает туннель (протокол + локальный порт), сервер выделяет публичный адрес.
3. Heartbeat — клиент и сервер обмениваются пинг-понгами каждые N секунд для обнаружения разрывов.
4. Завершение — при отключении клиента сервер освобождает ресурсы и публичный адрес.

# Упрощённая последовательность control plane
CLIENT → SERVER: Auth { token: "xxx" }
SERVER → CLIENT: AuthOK { session_id: "abc123" }

CLIENT → SERVER: Register { protocol: "http", local_port: 8080 }
SERVER → CLIENT: Registered { public_url: "https://abc123.fxtun.dev" }

CLIENT ↔ SERVER: Ping / Pong (каждые 10 секунд)

CLIENT → SERVER: Disconnect { session_id: "abc123" }
SERVER → CLIENT: Disconnected

Heartbeat позволяет быстро обнаружить разрыв соединения — если три пинга подряд остались без ответа, сервер считает клиента отключённым и освобождает туннель.

Протоколы туннелирования: HTTP, TCP, UDP

fxTunnel поддерживает три протокола — HTTP, TCP и UDP. В отличие от Cloudflare Tunnel (только HTTP) и ngrok (HTTP + ограниченный TCP), здесь есть полноценная поддержка всех трёх, включая UDP для игровых серверов, DNS и VoIP. Каждый протокол обрабатывает трафик по-своему — вот как они соотносятся с конкурентами.

Как работает HTTP-туннель

HTTP-туннель — наиболее распространённый тип. Сервер принимает HTTPS-запросы на публичном домене, анализирует заголовок Host, находит соответствующий зарегистрированный туннель и пересылает запрос клиенту. Ответ от клиента возвращается обратно тем же путём.

Браузер → HTTPS → fxTunnel Server → мультиплексор → fxTunnel Client → localhost:8080
                   (abc123.fxtun.dev)                                   (ваш сервер)

HTTP-туннель автоматически обеспечивает TLS на публичной стороне, поддерживает WebSocket (через HTTP Upgrade) и позволяет использовать кастомные домены.

Как работает TCP-туннель

TCP-туннель выделяет публичный порт на сервере и пробрасывает все TCP-соединения к клиенту. Это полезно для баз данных, SSH, Redis и любых TCP-сервисов.

# Клиент пробрасывает PostgreSQL
fxtunnel tcp 5432
# → Публичный адрес: tunnel.fxtun.dev:41234

# Подключение к БД с удалённой машины
psql -h tunnel.fxtun.dev -p 41234 -U myuser mydb

Каждое новое TCP-соединение на публичном порту создаёт отдельный поток в мультиплексоре, что обеспечивает изоляцию между клиентами.

Как работает UDP-туннель

UDP-туннель — уникальная функция fxTunnel среди аналогов. Поскольку UDP — протокол без установления соединения, туннелирование требует особого подхода: клиент инкапсулирует UDP-датаграммы внутри TCP-соединения с сервером, а сервер распаковывает их и отправляет с публичного UDP-порта.

# Клиент пробрасывает игровой сервер
fxtunnel udp 27015
# → Публичный адрес: tunnel.fxtun.dev:52001

# Игроки подключаются через публичный адрес

Обратная инкапсуляция добавляет минимальную задержку, но позволяет пробрасывать UDP-трафик через NAT без проброса портов на роутере.

Безопасность туннелей fxTunnel

Безопасность строится на трёх уровнях: TLS 1.3 шифрование всего трафика между клиентом и сервером, токенная аутентификация при подключении и полная изоляция туннелей друг от друга. К слову, открытый исходный код позволяет любому разработчику провести аудит — то, что с закрытыми решениями попросту невозможно.

TLS-шифрование

Все данные между клиентом и сервером fxTunnel передаются через TLS-соединение. Это защищает трафик от перехвата и модификации на транзитных узлах. Для HTTP-туннелей публичная сторона тоже работает по HTTPS — сервер может использовать сертификаты от Let’s Encrypt или любого другого CA.

Клиент ←── TLS 1.3 ──→ Сервер ←── HTTPS ──→ Внешний клиент
         (мультиплекс)           (публичный URL)

Поддерживается TLS 1.3 с современными наборами шифров. Устаревшие протоколы (TLS 1.0, 1.1) отключены по умолчанию.

Аутентификация

При подключении клиент предъявляет токен, который сервер проверяет. Это предотвращает несанкционированное создание туннелей. Токены можно генерировать на стороне сервера и выдавать пользователям — каждому свой.

# Генерация токена на сервере
fxtunnel server token generate --name "developer-1"
# → Token: fxt_a1b2c3d4e5f6...

# Клиент использует токен
fxtunnel http 8080 --token fxt_a1b2c3d4e5f6...

Токены привязаны к серверу и могут быть отозваны в любой момент без перезапуска.

Изоляция туннелей

Каждый туннель работает в изолированном контексте. Клиент A не может получить доступ к данным клиента B — мультиплексор строго разделяет потоки данных на основе идентификатора сессии. Это критически важно при использовании одного сервера несколькими разработчиками.

Производительность Go-реализации fxTunnel

Сколько overhead добавляет Go? На VPS с 1 vCPU — всего +1-5 мс к латентности, пропускная способность до 500 Мбит/с, поддержка 5000+ одновременных соединений. Горутины расходуют ~4 КБ стека каждая, так что сотни туннелей укладываются в ~50 МБ RAM.

Бенчмарки

Производительность зависит от трёх вещей: пропускная способность сети VPS, мощность процессора для TLS-шифрования и эффективность мультиплексирования. Вот примерные показатели для типичного VPS (1 vCPU, 1 ГБ RAM):

Оптимизации в Go

Почему Go так хорошо подходит для этой задачи? Несколько особенностей рантайма играют ключевую роль:

• Горутины — каждое соединение обслуживается горутиной, которая потребляет ~4 КБ стека. Это позволяет обрабатывать тысячи соединений без тяжёлых потоков ОС.
• Netpoller — встроенный I/O-мультиплексор (epoll на Linux, kqueue на macOS) обеспечивает эффективную обработку сетевых событий без блокировки.
• Zero-copy где возможно — данные передаются между соединениями через io.Copy, который использует splice на Linux для минимизации копирований в userspace.
• Статический бинарник — компиляция в один файл без зависимостей упрощает деплой и снижает время холодного старта.

// Пример: мультиплексирование в горутинах (упрощённо)
func (s *Server) handleTunnel(session *Session) {
    for {
        // Принимаем новый поток из мультиплексора
        stream, err := session.AcceptStream()
        if err != nil {
            return
        }
        // Каждый поток обрабатывается в отдельной горутине
        go func() {
            defer stream.Close()
            // Проксирование данных между публичным
            // и локальным соединениями
            localConn, err := net.Dial("tcp", session.LocalAddr)
            if err != nil {
                return
            }
            defer localConn.Close()
            // Двунаправленное копирование данных
            go io.Copy(localConn, stream)
            io.Copy(stream, localConn)
        }()
    }
}

Результат: тысячи одновременных соединений на одном ядре, а код при этом выглядит как обычный синхронный.

SaaS-сервис и тарифы fxTunnel

Облачный сервис на fxtun.dev позволяет начать работу за секунды без настройки сервера. Бесплатный тариф покрывает HTTP, TCP и UDP туннели. Платные тарифы от $5/мес добавляют кастомные домены и инспектор запросов с реплеем, а тариф от $10/мес — 10+ одновременных туннелей для команд.

Инспектор запросов — встроенный инструмент, который записывает все HTTP-запросы, проходящие через туннель, с телом, заголовками и таймингами. Функция реплея позволяет повторно отправить любой запрос одним кликом — идеально для тестирования вебхуков и отладки интеграций.

Open Source и контрибуция

Весь исходный код лежит на GitHub. Можно провести аудит безопасности, предложить улучшение или развернуть self-hosted версию на своей инфраструктуре.

Как внести вклад:

# Форкните и клонируйте репозиторий
git clone https://github.com/YOUR_USER/fxTunnel.git
cd fxTunnel

# Создайте ветку для вашего изменения
git checkout -b feature/my-improvement

# Запустите тесты
go test ./...

# Отправьте pull request на GitHub

Исправления багов, улучшение документации, новые фичи, тесты, переводы — любой вклад приветствуется вне зависимости от вашего уровня.

Ссылки для разработчиков:

• Репозиторий: github.com/mephistofox/fxtun.dev
• SaaS-сервис: fxtun.dev
• Issues: github.com/mephistofox/fxtun.dev/issues
• Сравнение с аналогами: fxTunnel vs ngrok vs Cloudflare

FAQ

Почему fxTunnel написан на Go, а не на Rust или C++?

Go попадает в золотую середину: достаточная производительность для сетевых задач и высокая скорость разработки. Горутины позволяют обрабатывать тысячи одновременных соединений без ручного управления памятью. А компиляция в один статический бинарник делает деплой на любую платформу тривиальным.

Как fxTunnel обеспечивает безопасность туннелей?

Три уровня работают вместе: TLS шифрует весь трафик между клиентом и сервером, токены аутентифицируют каждое подключение, а изоляция гарантирует, что каждый туннель работает в своём контексте и не может прочитать данные соседних.

Сколько одновременных туннелей выдерживает один сервер fxTunnel?

Даже скромный VPS (1 vCPU, 1 ГБ RAM) уверенно тянет сотни туннелей и тысячи соединений. Каждая горутина расходует около 4 КБ стека, так что RAM редко становится узким местом — обычно масштабирование упирается в пропускную способность сети.

Можно ли использовать fxTunnel без TLS для локальной разработки?

Можно, если окружение полностью изолировано. Но как только трафик идёт через публичную сеть — включайте TLS, иначе данные открыты для перехвата.

fxTunnel — это SaaS или self-hosted решение?

И то, и другое. Облачный сервис на fxtun.dev работает из коробки — бесплатный тариф включён, платные планы от $5/мес за кастомные домены и инспектор. Если нужен полный контроль — можно развернуть свой сервер из open-source кода на GitHub.

Чем fxTunnel лучше ngrok и Cloudflare Tunnel?

Код полностью открыт и аудируем — ngrok закрыт, а Cloudflare публикует только клиент. fxTunnel поддерживает TCP и UDP наравне с HTTP, тогда как Cloudflare ограничен HTTP на бесплатном тарифе. А встроенный инспектор запросов с реплеем дополняет инструментарий разработчика.