UDP-Verkehr durch den SSH-Tunnel

84526
heavyd

Der Titel bringt es auf den Punkt. Ich möchte UDP-Verkehr durch einen SSH-Tunnel senden. Insbesondere muss ich in der Lage sein, UDP-Pakete durch den Tunnel zu senden, und der Server muss sie auf der anderen Seite an mich zurücksenden können. Ich weiß, wie es für TCP-Verbindungen geht. Ist das mit UDP möglich?

61

6 Antworten auf die Frage

34
John T

In diesem kleinen Leitfaden erfahren Sie, wie Sie UDP-Datenverkehr über SSH mit Standardwerkzeugen (ssh, nc, mkfifo) unter den meisten UNIX-ähnlichen Betriebssystemen senden.

UDP-Tunneling über eine SSH-Verbindung durchführen

Schritt für Schritt Öffnen Sie einen TCP-Forward-Port mit Ihrer SSH-Verbindung

Stellen Sie auf Ihrem lokalen Computer (lokal) eine Verbindung mit dem entfernten Computer (Server) über SSH her, mit der zusätzlichen Option -L, sodass SSH mit TCP-Portweiterleitung:

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

Dadurch können TCP-Verbindungen an der Portnummer 6667 Ihres lokalen Computers über den sicheren Kanal an die Portnummer 6667 auf server.foo.com weitergeleitet werden. Richten Sie das TCP auf UDP-Weiterleitung auf dem Server ein

Auf dem Server öffnen wir einen Listener auf dem TCP-Port 6667, der Daten an den UDP-Port 53 einer angegebenen IP weiterleitet. Wenn Sie die DNS-Weiterleitung wie ich durchführen möchten, können Sie die IP des ersten Nameservers verwenden, die Sie in /etc/resolv.conf finden. Aber zuerst müssen wir ein FIFO erstellen. Das FIFO ist für eine bidirektionale Kommunikation zwischen den beiden Kanälen erforderlich. Ein einfaches Shell-Pipe würde nur die Standardausgabe des linken Prozesses an die Standardausgabe des rechten Prozesses übermitteln.

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

Dadurch wird der TCP-Datenverkehr am Port 6667 des Servers an UDP-Datenverkehr am Port 53 von 192.168.1.1 weitergeleitet, und die Antworten werden zurückgegeben. Richten Sie die UDP-TCP-Weiterleitung auf Ihrem Computer ein

Jetzt müssen wir das Gegenteil von dem tun, was oben auf dem lokalen Computer getan wurde. Sie benötigen einen privilegierten Zugriff, um den UDP-Port 53 zu binden.

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

Dadurch kann UDP-Datenverkehr auf dem Port 53 der lokalen Maschine an TCP-Datenverkehr an Port 6667 der lokalen Maschine weitergeleitet werden. Genießen Sie Ihren lokalen DNS-Server :)

Wie Sie wahrscheinlich bereits vermutet haben, wird eine DNS-Abfrage auf dem lokalen Computer, z. B. am lokalen UDP-Port 53, an den lokalen TCP-Port 6667, dann an den TCP-Port 6667 des Servers und dann an den DNS-Server des Servers weitergeleitet UDP-Port 53 von 192.168.1.1. Um DNS-Dienste auf Ihrem lokalen Computer zu nutzen, setzen Sie die folgende Zeile als ersten Nameserver in Ihre /etc/resolv.conf:

nameserver 127.0.0.1
Diese Lösung ist nicht sicher. Es kann nicht garantiert werden, dass TCP-Streams Nachrichtengrenzen beibehalten, sodass ein einzelnes UDP-Datagramm in Teile aufgeteilt werden kann, wodurch jedes Protokoll gebrochen wird. Juho Östman vor 13 Jahren 28
Es kann auch nützlich sein, Port 1153 anstelle von 6667 (vom man-SSH-Beispiel) zu verwenden, der von IRC verwendet wird. phil pirozhkov vor 12 Jahren 2
@ JuhoÖstman Danke für den Hinweis auf diese Fallstricke. Sich des Problems bewusst sein ... Haben Sie eine Lösung gewählt? Würden kleinbotige Meldungen dazu beitragen, dass dies wahrscheinlich funktioniert? humanityANDpeace vor 11 Jahren 1
Die Lösung wäre, jedem Paket eine Länge vor dem Senden durch den TCP-Stream voranzustellen und daraus die ursprünglichen Pakete zu rekonstruieren. Es wäre leicht, ein C-Skript zu schreiben, aber ich bin mir nicht sicher, ob es eine sofort verfügbare Lösung gibt. In der Praxis scheint das TCP in diesem Fall normalerweise die Nachrichtengrenzen beizubehalten, aber es können jederzeit merkwürdige Fehler auftreten. Juho Östman vor 11 Jahren 4
Ich hatte ein anderes Problem damit: Pipe und FIFO werden gepuffert, so dass Rahmengrenzen verloren gehen. So viele UDP-Frames können zu einem TCP-Frame verkettet werden. Julio Guerra vor 9 Jahren 0
`Nc` von Mac OS Sierra beschwert sich über diesen` sudo nc -l -u -p 53 / tmp / dnsfifo`, der "nc: missing port mit Option -l" sagt, aber seltsamerweise funktioniert jeder Befehl ohne Pipe gut, also ist er ziemlich seltsam. Natürlich funktionieren sie nicht wirklich, wenn sie nicht miteinander pfeifen, also ... dlamblin vor 7 Jahren 0
21
nik

In diesem Beispiel (ich glaube, Johns Antwort weist dasselbe an einer anderen Stelle auf), wird beschrieben, wie auf die UDP / DNS-Dienste eines anderen Computers über eine TCP / SSH-Verbindung zugegriffen wird.

Wir leiten den lokalen UDP / 53-Datenverkehr an TCP weiter, dann den TCP-Datenverkehr mit dem Portweiterleitungsmechanismus von SSH an den anderen Computer und dann TCP an UDP / 53 am anderen Ende.
Normalerweise ist das mit openvpn möglich.
Aber hier machen wir es mit einfacheren Tools, nur openssh und netcat.

Am Ende dieser Seite befindet sich ein weiterer Kommentar mit einem Verweis auf ' socat'.
Der gleiche UDP / DNS-Zugriff wird mit

Serverseite: socat tcp4-listen:5353,reuseaddr,fork UDP:nameserver:53
Clientseite:socat udp4-listen:53,reuseaddr,fork tcp:localhost:5353

Weitere Beispiele finden Sie in den Socat-Beispielen .

Diese scheint mir viel nützlicher zu sein als die akzeptierte Antwort. Ich brauchte eine unidirektionale Umleitung des Videostreams (TS / UDP) ... `ssh orig_strm_src socat udp4-listen: 4003, reuseaddr, Gabel STDOUT | socat STDIN udp-sendto: localhost: 4003` nhed vor 12 Jahren 2
FWIW, ich habe eine ausführlichere Anleitung auf meiner Homepage (http://www.morch.com/2011/07/05/forwarding-snmp-ports-over-ssh-using-socat/) geschrieben, in der beschrieben wird, wie socat über SSH für die UDP-Weiterleitung einrichten. Es verwendet SNMP als Beispiel. Peter V. Mørch vor 11 Jahren 0
19
grawity

SSH (zumindest OpenSSH) unterstützt einfache VPNs. Mit der Option -woder Tunnelim sshClient können Sie tunan beiden Enden ein Gerät erstellen, mit dem beliebige Arten von IP-Verkehr weitergeleitet werden können. (Siehe auch Tunnelauf der Handbuchseite von ssh_config(5).) Beachten Sie, dass dies OpenSSH (und möglicherweise Root-Rechte) an beiden Enden erfordert.

Dies erfordert root-Berechtigungen auf der Remote-Maschine, selbst wenn UDP-Ports nicht privilegierter Ports getunnelt werden und PermitRootLogin auf 'no' gesetzt ist. Schade. phil pirozhkov vor 12 Jahren 0
@grawity Vielen Dank für den Hinweis auf diese Option, die auch von philpirozhkov darauf hinweist, dass das Root-Login erforderlich ist. Ich frage mich, ob es eine Möglichkeit gibt, es zu überlisten, ohne die Wurzel zu benötigen? humanityANDpeace vor 11 Jahren 0
@humanityANDpeace: Sie können die Tun- / Tap-Geräte vorab erstellen und sie einem bestimmten Benutzer zuordnen, indem Sie 'ip tuntap add' verwenden. grawity vor 11 Jahren 4
Hi @Grawity. Ich mag Ihre Lösung, kann sie aber nicht zum Laufen bringen. Ich habe das "tun" -Gerät wie folgt vorgefertigt: "sudo ip tuntap add mode tun", aber wenn ich die "-w" -Option wie folgt benutze: "ssh $ Server -w $ port", bekomme ich "Tunnel Device Open" fehlgeschlagen. Konnte keine Tunnelweiterleitung anfordern. "Was mache ich falsch? Lucas Aimaretto vor 6 Jahren 0
11
ssf-developers

Oder Sie verwenden einfach ssf (das für diesen Anwendungsfall gedacht ist) mit einem einfachen Befehl:

Kundenseite:

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

Dieser Befehl leitet den lokalen Port 53 (dns) über einen sicheren Tunnel zwischen localhost und server.foo.com an 192.168.1.1 Port 53 um.

Sie benötigen einen SSF-Server (statt - oder neben Ihrem SSH-Server):

#>./ssfs

Übrigens, sowohl die Client- als auch die Serverseite von ssf funktionieren unter Windows / Linux / Mac. Dies ist eine Benutzeranwendung, so dass Sie kein Tun / Tap oder VPN benötigen.

Um Port 53 umzuleiten, benötigen Sie Administratorrechte - unabhängig vom verwendeten Tool.

Für weitere Informationen, Details, Anwendungsfall oder Download: https://securesocketfunneling.github.io/ssf/

Seien Sie vorsichtig und antworten Sie mit "Hier ist mein Produkt", es handelt sich um Borderline-Spam. Ich empfehle, die [Richtlinien der Hilfe] (http://superuser.com/help/promotion) zu lesen und zu befolgen. heavyd vor 9 Jahren 0
Es ist höchstens ein schamloser Stecker. Auf jeden Fall passt die Lösung zu Ihrer Anfrage. SSF ist übrigens OpenSource und nicht gewinnorientiert. ssf-developers vor 9 Jahren 5
@ heavyd: Wenn er ein paar hacky Skripte veröffentlicht hat, wäre das akzeptabel, aber weil er ein ausgereiftes Open-Source-Tool gemacht hat, ist es nicht so? Es beantwortet die ursprüngliche Frage perfekt. Synthead vor 8 Jahren 10
Ich muss widerwillig zugeben, dass dies genau das Werkzeug ist, nach dem ich gesucht habe, selbst wenn es ein schamloser Plug war. therealrootuser vor 8 Jahren 0
8
Peter V. Mørch

Ich konnte nicht ncmit SNMP arbeiten, da SNMP-Clients ständig einen neuen UDP-Quellport wählen und mehrere gleichzeitig aktiv sein können.

Stattdessen habe ich socatin diesem Blogbeitrag einen Beitrag geschrieben, in dem beschrieben wird, wie das gemacht wird. Am Beispiel von SNMP. Im Wesentlichen mit zwei Terminals, beginnend mit einer Übersicht:

Überblick

Terminal eins:

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

Dadurch wird die SSH-Weiterleitung von TCP-Port 10000 erstellt und socat auf dem Server ausgeführt. Beachten Sie, wie die IP-Adresse des Switches in der socat-Befehlszeile als „Switch“ angegeben wird.

Terminal zwei:

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

Damit wird socat auf dem Client eingerichtet. Das sollte es tun.

das hat für mich funktioniert :) Paul Fenney vor 6 Jahren 0
3
Michael

Ein VPN ist eine bessere Lösung, wenn Sie auf einen UDP-Port zugreifen können.

Wenn Sie nur auf den TCP-SSH-Port zugreifen können, ist ein SSH-Tunnel mindestens so gut wie ein VPN, zumindest für Ping- und Paket-Backtracking.

Verwandte Probleme