UDP-туннели

UDP-туннель публикует локальный UDP-сервис и пересылает входящие датаграммы на выбранный локальный адрес. Для запуска требуется учётная запись.

Описание

Общее описание функционала

UDP-туннелирование пересылает датаграммы между локальным UDP-сервисом и клиентами в интернете через инфраструктуру туннеля. Подходит для DNS, syslog, игровых протоколов и других сценариев, где важна низкая задержка и модель «без установления соединения», с пониманием, что потери и порядок остаются на совести UDP. Сервер выделяет публичный UDP-порт в заданном диапазоне и сопоставляет потоки по правилам сессий и ключей потока.

Как пользователь может использовать

  • Разработчик публикует локальный DNS-резолвер или тестовый UDP-сервис для команды.
  • Администратор собирает syslog или метрики с удалённых хостов на локальный коллектор.
  • Пользователь подключается к игровому или стриминговому UDP-сервису за NAT.
  • Пользователь задаёт в CLI локальный UDP listen и целевой адрес на стороне сервера согласно документации.
  • Несколько локальных приложений используют один адрес -udp-listen: каждое получает ответы только на свои датаграммы.
  • Пользователь учитывает таймаут неактивности и максимальный размер датаграммы, настроенные оператором.
  • Пользователь входит в бесплатную учётную запись перед созданием UDP-туннеля; гостевой режим для UDP недоступен.
  • Отправленные и полученные датаграммы расходуют общий месячный лимит всех туннелей этой учётной записи.

Как это реализовано в сервисе

Клиент подтверждает зарегистрированную учётную запись, создаёт туннель с протоколом UDP и использует выбранный транспорт для передачи трафика. Бесплатного тарифа достаточно, если его лимиты не исчерпаны. Сервер слушает UDP на выделенном порту, сопоставляет пакеты с туннелем и пересылает их через защищённый канал к локальному приложению. Полезные данные каждой датаграммы учитываются один раз в нужном направлении; служебные данные транспорта в лимит не входят.

Как использовать через CLI-клиент

Основной сценарий — публикация локального UDP-сервиса (как в ngrok):

fortunnels udp 9000
fortunnels udp 192.168.1.10:9000

Клиент создаёт туннель и пересылает входящие датаграммы с выданного публичного UDP-порта на указанный локальный адрес. Пока клиент работает, удалённые отправители могут обращаться к вашему UDP-сервису через этот порт.

Расширенный режим reverse-proxy (оба флага обязательны):

fortunnels udp 53 -udp-listen :5353 -udp-dst 127.0.0.1:53

В этом режиме с одного адреса -udp-listen могут отправлять датаграммы несколько локальных приложений. Клиент различает их по адресу отправителя, сервер для каждого поддерживает отдельное соединение с целевым адресом, поэтому ответ возвращается именно тому приложению, которое его вызвало. Это работает через транспорты WebSocket и DTLS, если клиент и сервер поддерживают такой режим.

UDP всегда требует учётную запись. Передайте действующий токен либо используйте -login user@example.test -pass-stdin. Подробности флагов -udp-listen и -udp-dst — в документации CLI-клиента.

Справочник API

Создание туннеля

POST /api/tunnels

Пример:

{
  "protocol": "udp",
  "target_addr": "127.0.0.1:5353"
}

Ответ: идентификатор туннеля и публичный UDP-адрес (схема udp://host:port или поля host/port — как возвращает ваш сервер).

Создание требует действующую сессию или Bearer-токен зарегистрированной учётной записи. Бесплатного тарифа достаточно в пределах его лимитов; гостевой UDP-режим недоступен.

Статус и удаление

GET / DELETE по контракту API туннелей с идентификатором (см. актуальные пути в справочнике сервера).

CLI

fortunnels в режиме udp с флагами локального прослушивания и удалённого назначения (см. -udp-listen, -udp-dst в справке клиента). На один адрес -udp-listen можно отправлять датаграммы из нескольких локальных приложений: ответ приходит тому, кто отправил запрос.

Инспектор UDP

Просмотр записанных датаграмм: GET /api/v1/inspector/udp/datagrams (отдельная возможность продукта; требует прав зарегистрированного пользователя, не гостя).

Ошибки

Датаграмма слишком большая

Пакет превышает udp_max_payload_bytes сервера — отбрасывается или не пересылается (наблюдаемо как отсутствие ответа на стороне UDP).

Нет свободного порта

Не удаётся выделить порт из udp_port_range — создание туннеля завершается ошибкой API.

Таймаут неактивности

Поток UDP закрыт после простоя; следующая датаграмма может инициализировать новый поток или быть потеряна в зависимости от клиента.

401 / 403 на API

Создание или управление без прав или при запрете протокола политикой.

Ограничения

  • UDP не гарантирует доставку и порядок; приложение должно это учитывать.
  • NAT и файрволы могут ограничивать входящий UDP к клиенту агента.
  • Доступность UDP зависит от разрешённого протокола туннеля, правил доступа и свободных публичных портов. Для размера датаграмм действуют ограничения сервиса.
  • Приостановленный UDP-туннель сохраняет публичный порт за собой, но не принимает датаграммы. После возобновления используется прежний адрес, даже если освободился другой порт.
  • После перезапуска сервера действующий туннель возвращается на прежний публичный порт. Передача датаграмм возобновляется после переподключения клиента; потерянные датаграммы не повторяются.
  • Если прежний порт занят другим процессом, сервис может выдать новый публичный адрес. Перед отправкой проверьте актуальный адрес туннеля.
  • Если новый адрес не удалось подтвердить, передача датаграмм может оставаться недоступной. Обновите карточку туннеля и повторите завершившееся ошибкой действие позже; отправляйте данные по адресу, который подтвердил сервис.
  • Раздельная доставка ответов нескольким локальным приложениям за одним -udp-listen требует, чтобы новая версия была и у клиента, и у сервера. Если сервер старой версии, клиент продолжает работать в прежнем режиме: ответ получает отправитель последней датаграммы. При DTLS переход на прежний режим происходит после ожидания до двух секунд при подключении.
  • Число одновременно отслеживаемых локальных отправителей на одно соединение ограничено (на сервере по умолчанию 1024, у клиента 4096). Датаграммы новых отправителей сверх лимита отбрасываются, остальные продолжают работать.
  • Если локальный отправитель молчит дольше тайм-аута неактивности, его соединение с целевым адресом закрывается; следующая датаграмма откроет новое.
  • В режиме reverse-proxy соединение с сервером остаётся открытым, пока работает клиент: при WebSocket — до закрытия потока, при DTLS его поддерживают периодические проверки связи, даже если датаграмм нет.