Un outil de ligne de commande pour tunneliser les datagrammes UDP sur TCP.
Il est particulièrement utile pour tunneliser UDP sur SSH.
L'outil a été conçu principalement pour le cas d'utilisation dans lequel deux applications doivent communiquer entre elles via UDP sans relation client-serveur évidente. Autrement dit, chaque application peut lancer un paquet et doit être configurée avec l'adresse de l'autre au démarrage (c'est-à-dire que les ports ne peuvent pas être aléatoires).
Vous exécutez udp-over-tcp
sur les hôtes des deux applications. Chaque instance agit comme une sorte de réplique locale sur l'application exécutée sur l'autre. Si l'application sur un hôte écoute sur le port UDP P, alors udp-over-tcp
écoutera sur le port UDP P sur l' autre hôte et garantira que le trafic vers la réplique P va vers le port P de l'application réelle udp-over-tcp
fera cela pour les ports des deux applications en même temps et liera les ports. Cela permettra effectivement de "faire semblant" que chaque application s'exécute localement par rapport à l'autre.
Concrètement, si l'application sur un hôte envoie un datagramme depuis son port P vers le port (réplique locale) Q, le datagramme arrivera au port Q de l'application réelle (distante) avec un port source de P . Cela signifie qu'une application voit toujours la même adresse (localhost) et le même port (le port de l'autre application), et que la même paire adresse-hôte peut également être utilisée dans la configuration homologue de l'application.
Espérons que le diagramme suivant puisse aider à comprendre la configuration configurée udp-over-tcp
:
Le programme est précompilé pour un certain nombre de plates-formes (merci cargo-dist !) et devrait être exécutable prêt à l'emploi sans dépendances.
Alternativement, vous pouvez l'installer via Cargo avec
$ cargo install udp-over-tcp
Vous avez une application UDP exécutée sur l'hôte X sur le port A. Vous souhaitez qu'elle communique avec une application UDP exécutée sur l'hôte Y sur le port B. Et vous souhaitez également autoriser l'application sur Y à communiquer avec A sur X. Super, faites-le. comme suit:
Sur l'un ou l'autre hôte (ici X), créez d'abord un tunnel TCP vers l'autre hôte :
ssh -L 7878:127.0.0.1:7878 $Y
Ensuite, exécutez udp-over-tcp sur les deux hôtes, un avec --tcp-listen
et un avec --tcp-connect
. Le --tcp-listen
doit être utilisé sur l'hôte auquel le transfert permet de se connecter (ici Y). Vous pouvez les exécuter dans n’importe quel ordre, mais la meilleure pratique consiste à écouter d’abord :
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
Sur Y, cela écoutera sur le port UDP $A, les transmettra via TCP à X, puis les livrera au port UDP $A. Sur X, cela écoutera sur le port UDP $B, les transmettra via TCP à Y, puis les livrera au port UDP $B.
Configurez maintenant l'application sur X pour envoyer à 127.0.0.1:$B et configurez l'application sur Y pour envoyer à 127.0.0.1:$A. Autrement dit, même port, adresse IP locale.
Chaque argument prend un numéro de port (comme ci-dessus) ou addr:port pour spécifier l'adresse. (l'adresse par défaut est 0.0.0.0 pour écouter/lier et 127.0.0.1 pour connecter/envoyer)
Il existe d'autres outils qui peuvent aider à résoudre ce problème, bien qu'ils aient des propriétés différentes de celles de cet outil.
Les solutions reposant sur nc
ou socat
ne préservent pas les limites du datagramme UDP, ce qui signifie que deux sendmsg
UDP ne peuvent faire arriver qu'un seul message (combiné) via recvfrom
. De nombreuses applications UDP ne sont pas résilientes à cela car elles s'appuient sur UDP pour fournir le cadrage des messages.
L'udp-over-tcp de Mullvad fournit uniquement un transfert unidirectionnel. On peut exécuter des instances supplémentaires de l'outil pour transférer dans l'autre sens, mais cela signifie que le port source des datagrammes entrants ne correspondra pas au port de destination des datagrammes sortants. Cependant, cela convient probablement aux applications de type client-serveur dans lesquelles le port du client n'est pas important.
Autorisé sous l'un ou l'autre des
à votre choix.
Sauf indication contraire explicite de votre part, toute contribution intentionnellement soumise pour inclusion dans le travail par vous, telle que définie dans la licence Apache-2.0, bénéficiera d'une double licence comme ci-dessus, sans termes ou conditions supplémentaires.