Una herramienta de línea de comandos para tunelizar datagramas UDP a través de TCP.
Es particularmente útil para hacer túneles UDP sobre SSH.
La herramienta fue diseñada principalmente para el caso de uso en el que tiene dos aplicaciones que necesitan comunicarse entre sí a través de UDP sin una relación cliente-servidor obvia. Es decir, cualquiera de las aplicaciones puede iniciar un paquete y debe configurarse con la dirección de la otra al inicio (es decir, los puertos no pueden ser aleatorios).
Ejecuta udp-over-tcp
en los hosts de ambas aplicaciones. Cada instancia actúa como una especie de réplica local de la aplicación que se ejecuta en la otra. Si la aplicación en un host escucha en el puerto UDP P, entonces udp-over-tcp
escuchará en el puerto UDP P en el otro host y garantizará que el tráfico a la réplica P vaya al puerto P de la aplicación real. Fundamentalmente, udp-over-tcp
hará esto para los puertos de ambas aplicaciones al mismo tiempo y vinculará los puertos. Efectivamente "pretenderá" que cada aplicación se ejecuta localmente para la otra.
Concretamente, si la aplicación en un host envía un datagrama desde su puerto P al puerto Q (réplica local), el datagrama llegará al puerto Q de la aplicación real (remota) con un puerto de origen P. Esto significa que una aplicación siempre ve la misma dirección (localhost) y puerto (el puerto de la otra aplicación), y ese mismo par de dirección-host también se puede usar en la configuración del mismo nivel para la aplicación.
Con suerte, el siguiente diagrama puede ayudar a comprender la configuración udp-over-tcp
:
El programa viene precompilado para varias plataformas (¡gracias cargo-dist!) y debería ser ejecutable de inmediato y sin dependencias.
Alternativamente, puedes instalarlo a través de Cargo con
$ cargo install udp-over-tcp
Tiene una aplicación UDP ejecutándose en el host X en el puerto A. Quiere que se comunique con una aplicación UDP que se ejecuta en el host Y en el puerto B. Y también desea permitir que la aplicación en Y se comunique con A en X. Genial, hágalo. como sigue:
En cualquiera de los hosts (aquí X), primero cree un túnel TCP hacia el otro host:
ssh -L 7878:127.0.0.1:7878 $Y
A continuación, ejecute udp-over-tcp en ambos hosts, uno con --tcp-listen
y otro con --tcp-connect
. --tcp-listen
debe usarse en el host al que el reenvío permite conectarse (aquí Y). Puede ejecutarlos en cualquier orden, pero la mejor práctica es escuchar primero:
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
En Y, esto escuchará en el puerto UDP $A, los reenviará a través de TCP a X y luego los entregará al puerto UDP $A allí. En X, esto escuchará en el puerto UDP $B, los reenviará a través de TCP a Y y luego los entregará al puerto UDP $B allí.
Ahora configure la aplicación en X para enviar a 127.0.0.1:$B y configure la aplicación en Y para enviar a 127.0.0.1:$A. En otras palabras, mismo puerto, dirección IP local.
Cada argumento toma un número de puerto (como arriba) o addr:port para especificar la dirección. (la dirección predeterminada es 0.0.0.0 para escuchar/enlazar y 127.0.0.1 para conectar/enviar a)
Existen otras herramientas que pueden ayudar con este problema, aunque tienen propiedades diferentes a las de esta herramienta.
Las soluciones que dependen de nc
o socat
no conservan los límites de los datagramas UDP, lo que significa que dos sendmsg
UDP pueden provocar que solo llegue un único mensaje (combinado) a través de recvfrom
. Muchas aplicaciones UDP no son resistentes a esto ya que dependen de UDP para proporcionar encuadres de mensajes.
Udp-over-tcp de mullvad solo proporciona reenvío unidireccional. Se pueden ejecutar instancias adicionales de la herramienta para reenviar en la otra dirección, aunque hacerlo significa que el puerto de origen de los datagramas entrantes no coincidirá con el puerto de destino de los datagramas salientes. Sin embargo, esto probablemente esté bien para aplicaciones de estilo cliente-servidor donde el puerto del cliente no es importante.
Con licencia bajo cualquiera de
a tu elección.
A menos que indique explícitamente lo contrario, cualquier contribución enviada intencionalmente para su inclusión en el trabajo, tal como se define en la licencia Apache-2.0, tendrá una licencia doble como se indicó anteriormente, sin términos ni condiciones adicionales.