109 votes

Trafic UDP à travers un tunnel SSH

Le titre résume assez bien la situation. J'aimerais envoyer du trafic UDP à travers un tunnel SSH. Plus précisément, j'ai besoin de pouvoir envoyer des paquets UDP à travers le tunnel et que le serveur puisse me les renvoyer de l'autre côté. Je sais comment le faire pour les connexions TCP. Est-il possible de le faire avec UDP?

0 votes

Pouvez-vous publier comment le faire pour les connexions TCP ?

0 votes

@GabrielStaples la fonction mentionnée s'appelle "transfert de port". Vous pouvez simplement rechercher "transfert de port ssh". Voici l'un des résultats de recherche - help.ubuntu.com/community/SSH/OpenSSH/PortForwarding. J'espère que vous trouverez ce dont vous avez besoin.

0 votes

@VictorYarema, merci. J'ai aussi expérimenté et écrit un programme de redirection de port UDP de base en Python: socket_udp_port_forwarding.py dans mon dépôt eRCaGuy_hello_world. Je suis sûr que je pourrais le convertir en TCP aussi.

59voto

Dalroth Points 2468

Ce petit guide vous explique comment envoyer du trafic UDP via SSH en utilisant des outils standard (ssh, nc, mkfifo) présents dans la plupart des systèmes d'exploitation de type UNIX.

Réaliser un tunnel UDP à travers une connexion SSH

Étapes à suivre

Ouvrir un port de transfert TCP avec votre connexion SSH

Sur votre machine locale (local), connectez-vous à la machine distante (serveur) via SSH, avec l'option -L supplémentaire pour que SSH effectue un transfert de port TCP :

local# ssh -L 6667:localhost:6667 server.foo.com

Cela permettra aux connexions TCP sur le port 6667 de votre machine locale d'être transférées vers le port 6667 de server.foo.com via le canal sécurisé.

Configurer le transfert TCP vers UDP sur le serveur

Sur le serveur, nous ouvrons un écouteur sur le port TCP 6667 qui transférera les données vers le port UDP 53 d'une IP spécifiée. Si vous souhaitez faire du renvoi DNS comme moi, vous pouvez prendre l'IP du premier serveur de noms que vous trouverez dans /etc/resolv.conf.

Mais d'abord, nous devons créer un fifo. Le fifo est nécessaire pour avoir des communications bidirectionnelles entre les deux canaux. Un simple pipe shell ne communiquerait que la sortie standard du processus de gauche vers l'entrée standard du processus de droite.

server# mkfifo /tmp/fifo
server# nc -l -p 6667 < /tmp/fifo | nc -u 192.168.1.1 53 > /tmp/fifo

Cela permettra au trafic TCP sur le port 6667 du serveur d'être transféré vers le trafic UDP sur le port 53 de 192.168.1.1, et les réponses de revenir.

Configurer le transfert UDP vers TCP sur votre machine

Maintenant, nous devons faire l'inverse de ce qui a été fait ci-dessus sur la machine locale. Vous avez besoin d'un accès privilégié pour lier le port UDP 53.

local# mkfifo /tmp/fifo
local# sudo nc -l -u -p 53 < /tmp/fifo | nc localhost 6667 > /tmp/fifo

Cela permettra au trafic UDP sur le port 53 de la machine locale d'être transféré vers le trafic TCP sur le port 6667 de la machine locale. Profitez de votre serveur DNS local :)

Comme vous l'avez probablement deviné, lorsque une requête DNS sera effectuée sur la machine locale, par exemple sur le port UDP 53 local, elle sera transférée vers le port TCP 6667 local, puis vers le port TCP 6667 du serveur, puis vers le serveur DNS du serveur, le port UDP 53 de 192.168.1.1. Pour profiter des services DNS sur votre machine locale, mettez la ligne suivante comme premier serveur de noms dans votre /etc/resolv.conf:

nameserver 127.0.0.1

46 votes

Cette solution n'est pas sûre. Les flux TCP ne garantissent pas de préserver les limites des messages, donc un seul datagramme UDP peut être divisé en parties, rompant tout protocole.

3 votes

Il pourrait également être utile d'utiliser le port 1153 au lieu du 6667 (exempl de l'homme SSH), qui est utilisé par IRC.

2 votes

@JuhoÖstman Merci d'avoir signalé ce piège. Être conscient du problème... avez-vous trouvé une solution ? Les messages assez petits pourraient-ils être une manière de le rendre probablement fonctionnel ?

52voto

Mark Points 251

Cet exemple (Je pense que la réponse de John indique la même chose à un endroit différent), décrit comment accéder aux services UDP/DNS d'une autre machine via une connexion TCP/SSH.

Nous allons rediriger le trafic local UDP/53 vers TCP, puis le trafic TCP avec le mécanisme de transfert de port de SSH vers l'autre machine, puis TCP vers UDP/53 à l'autre extrémité.
En général, on peut le faire avec openvpn.
Mais ici, nous le ferons avec des outils plus simples, seulement openssh et netcat.

À la fin de cette page, il y a un autre commentaire avec une référence à 'socat',
Le même accès UDP/DNS est réalisé avec,

Côté serveur : socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53
Côté client : socat udp4-listen:53,reuseaddr,fork tcp:localhost:5353

Consultez les exemples de socat pour en savoir plus.

5 votes

Cette réponse me semble beaucoup plus utile que la réponse acceptée. J'avais besoin d'une redirection unidirectionnelle du flux vidéo (TS/UDP)... ssh orig_strm_src socat udp4-listen:4003,reuseaddr,fork STDOUT| socat STDIN udp-sendto:localhost:4003

6 votes

Au fait, j'ai écrit un guide plus détaillé sur ma page d'accueil décrivant comment configurer socat sur SSH pour le renvoi UDP. Il utilise SNMP comme exemple.

31voto

Grant Smith Points 255

Ou vous pourriez simplement utiliser ssf (qui a été conçu pour gérer ce cas d'utilisation), avec une simple commande :


Côté client :

#>./ssfc -U 53:192.168.1.1:53 server.foo.com

Cette commande redirige le port local 53 (dns) vers le port 53 de 192.168.1.1, à travers un tunnel sécurisé entre localhost et server.foo.com.


Vous aurez besoin d'un serveur ssf (au lieu de - ou à côté de - votre serveur ssh) :

#>./ssfs

D'ailleurs, le côté client et serveur de ssf fonctionnent sur Windows / Linux / Mac. Il s'agit d'une application utilisateur, donc vous n'avez pas besoin de tun/tap ou de VPN.

Pour rediriger le port 53, vous aurez besoin de privilèges administratifs - peu importe l'outil que vous utilisez.

Pour plus d'informations, de détails, de cas d'utilisation, ou pour télécharger : https://securesocketfunneling.github.io/ssf/

12 votes

Au plus, c'est un coup de pub sans vergogne. Quoi qu'il en soit, la solution peut correspondre à votre demande. Au fait, SSF est OpenSource et à but non lucratif.

34 votes

@heavyd : Si il avait posté un tas de scripts de hack basiques, ce serait acceptable, mais parce qu'il a créé un outil open-source mature, ce n'est pas le cas ? Cela répond parfaitement à la question initiale.

0 votes

Je dois admettre à contrecœur que c'est exactement l'outil que je cherchais, même s'il s'agissait d'une publicité honteuse.

29voto

James Mertz Points 390

SSH (au moins OpenSSH) prend en charge les VPN simples. En utilisant l'option -w ou Tunnel dans le client ssh, vous pouvez créer un périphérique tun aux deux extrémités, qui peut être utilisé pour transmettre tout type de trafic IP. (Voir aussi Tunnel dans la page de manuel de ssh_config(5).) Notez que cela nécessite OpenSSH (et probablement des privilèges root) aux deux extrémités.

1 votes

Cela nécessite des privilèges root sur la machine distante même pour le tunneling UDP des ports non privilégiés et PermitRootLogin défini à 'non'. Dommage.

0 votes

@grawity Merci d'avoir signalé cette option, qui nécessite même, comme l'a souligné philpirozhkov, la connexion root. Je me demande s'il existe un moyen de le duper pour ne pas avoir besoin du root?

7 votes

@humanityANDpeace: Vous pouvez précréer les dispositifs tun/tap et les attribuer à un utilisateur spécifique en utilisant ip tuntap add.

18voto

Peter V. Mørch Points 319

Je n'ai pas réussi à faire fonctionner nc pour SNMP, car les clients SNMP continuent de choisir un nouveau port UDP source, et plusieurs peuvent être actifs en même temps.

À la place, j'ai écrit un article décrivant comment le faire avec socat dans ce article de blog, en utilisant SNMP comme exemple. Essentiellement, en utilisant deux terminaux, en commençant par une vue d'ensemble :

vue d'ensemble

Terminal un :

client$ ssh -L 10000:localhost:10000 server
server$ socat -T10 TCP4-LISTEN:10000,fork UDP4:switch:161

Ceci crée la redirection SSH vers le port TCP 10000 et exécute socat sur le serveur. Remarquez comment l'adresse IP du commutateur est mentionnée dans la ligne de commande socat comme "switch".

Terminal deux :

client$ sudo socat UDP4-LISTEN:161,fork TCP4:localhost:10000

Cela configure socat sur le client. Cela devrait fonctionner.

2 votes

Cela a fonctionné pour moi :)

0 votes

Pourquoi n'avez-vous pas besoin d'un tunnel distant -R pour renvoyer la réponse du serveur UDP ("switch") vers le client UDP ("manager") ?

0 votes

@bers: socat le fait pour moi

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X