Инструмент командной строки для туннелирования датаграмм UDP через TCP.
Это особенно полезно для туннелирования UDP через SSH.
Этот инструмент был разработан в первую очередь для случая, когда у вас есть два приложения, которым необходимо взаимодействовать друг с другом через UDP без очевидной связи клиент-сервер. То есть любое приложение может инициировать пакет и при запуске должно быть настроено с использованием адреса другого (т. е. порты не могут быть случайными).
Вы запускаете udp-over-tcp
на хостах обоих приложений. Каждый экземпляр действует как своего рода локальная реплика приложения, работающего на другом. Если приложение на одном хосте прослушивает UDP-порт P, то udp-over-tcp
будет прослушивать UDP-порт P на другом хосте и гарантировать, что трафик к реплике P идет на порт P реального приложения. Важно отметить, что udp-over-tcp
сделает это для портов обоих приложений одновременно и свяжет порты. Фактически будет «притворяться», что каждое приложение работает локально по отношению к другому.
Конкретно, если приложение на одном хосте отправляет дейтаграмму со своего порта P на порт Q (локальной реплики), дейтаграмма прибудет на порт Q реального (удаленного) приложения с исходным портом P . Это означает, что приложение всегда видит один и тот же адрес (локальный хост) и порт (порт другого приложения), и эта же пара адрес-хост также может использоваться в конфигурации однорангового узла для приложения.
Надеемся, что следующая диаграмма поможет понять настройку конфигурации udp-over-tcp
:
Программа поставляется предварительно скомпилированной для ряда платформ (спасибо Cargo-dist!) и должна запускаться «из коробки» без каких-либо зависимостей.
Альтернативно, вы можете установить его через Cargo с помощью
$ cargo install udp-over-tcp
У вас есть UDP-приложение, работающее на хосте X через порт A. Вы хотите, чтобы оно взаимодействовало с UDP-приложением, работающим на хосте Y через порт B. И вы также хотите разрешить приложению на Y взаимодействовать с A на X. Отлично, сделайте это. следующее:
На любом хосте (здесь X) сначала создайте TCP-туннель к другому хосту:
ssh -L 7878:127.0.0.1:7878 $Y
Затем запустите udp-over-tcp на обоих хостах: один с --tcp-listen
, другой с --tcp-connect
. --tcp-listen
следует использовать на хосте, к которому разрешена переадресация (здесь Y). Вы можете запускать их в любом порядке, но лучше всего сначала прослушать:
Y $ udp-over-tcp --tcp-listen 7878 --udp-bind $A --udp-sendto $B
X $ udp-over-tcp --tcp-connect 7878 --udp-bind $B --udp-sendto $A
На Y это будет прослушивать UDP-порт $A, пересылать их через TCP в X, а затем доставлять их туда на UDP-порт $A. На X это будет прослушивать UDP-порт $B, пересылать их через TCP на Y, а затем доставлять их туда на UDP-порт $B.
Теперь настройте приложение на X для отправки на адрес 127.0.0.1:$B и настройте приложение на Y для отправки на адрес 127.0.0.1:$A. Другими словами, тот же порт, локальный IP-адрес.
Каждый аргумент принимает номер порта (как указано выше) или адрес:порт для указания адреса. (по умолчанию адрес 0.0.0.0 для прослушивания/привязки и 127.0.0.1 для подключения/отправки)
Существуют и другие инструменты, которые могут помочь в решении этой проблемы, хотя они имеют другие свойства, чем этот инструмент.
Решения, основанные на nc
или socat
не сохраняют границы дейтаграмм UDP, а это означает, что два UDP sendmsg
могут привести к поступлению только одного (комбинированного) сообщения через recvfrom
. Многие приложения UDP не устойчивы к этому, поскольку они полагаются на UDP для формирования кадров сообщений.
udp-over-tcp Mullvad обеспечивает только однонаправленную пересылку. Можно запустить дополнительные экземпляры инструмента для пересылки в другом направлении, однако это означает, что порт источника входящих дейтаграмм не будет совпадать с портом назначения исходящих дейтаграмм. Однако это, вероятно, подходит для приложений типа клиент-сервер, где порт клиента не важен.
Лицензировано по любому из
по вашему выбору.
Если вы явно не указали иное, любой вклад, намеренно представленный вами для включения в работу, как это определено в лицензии Apache-2.0, должен иметь двойную лицензию, как указано выше, без каких-либо дополнительных условий.