Netcat hört auf, auf UDP-Verkehr zu warten

Ich verwende Netcat auf einigen Linux-Computern (siehe diese andere Frage ), sehe jedoch ein unerwartetes Verhalten.

Im Gegensatz zu der Anleitung in der akzeptierten Antwort verwende ich kein UDP-Tunneling, um DNS-Abfragen durchzuführen. Ich habe einen Remote-Server, auf dem ich mich anmelden kann, auf dem jedoch keine Software installiert ist, und ich versuche, den UDP-Verkehr von meinem Computer zum Server zu tunneln und dann einen separaten Tunnel einzurichten, um UDP-Antworten vom Server an meinen Computer zurückzusenden .

Der Tunnel, der von meinem Computer zum Server führt, funktioniert einwandfrei. Auf der Serverseite schließt jedoch die Instanz von netcat, die auf die Antwort vom UDP-Server wartet, den Listener, nachdem die erste Antwort empfangen wurde. Ich kann also eine Anfrage senden und 1 Antwort zurückerhalten, aber alle nachfolgenden Anfragen machen es in Ordnung, aber es werden keine Antworten empfangen. Mit netstat kann ich sehen, dass netcat abhört, bevor die Antwort empfangen wird, aber der Port wird dann geschlossen, nachdem die Antwort empfangen wurde.

Die Netcat-Instanz auf meinem Computer scheint alles in Ordnung zu bringen. Auf beiden Computern wird netcat v1.10-38 ausgeführt. Irgendwelche Ideen, was los ist?

Es gibt also mehrere Dinge, die als Netcat bezeichnet werden. Ubuntu hat sogar / etc / alternatives Symbolic-Link-Hackery dafür.

Ich denke, ein Teil Ihres Problems ist, dass UDP keine Sitzungen durchführt. Ich habe einen Teil der Datei /usr/share/doc/netcat-traditional/README.gz kopiert, die eine ziemlich gute Erklärung bietet.

UDP-Verbindungen werden anstelle von TCP geöffnet, wenn -u angegeben wird. Dies sind an sich keine wirklichen "Verbindungen", da UDP ein verbindungsloses Protokoll ist, obwohl netcat intern den "verbundenen UDP-Socket" -Mechanismus verwendet, den die meisten Kernel unterstützen. Obwohl netcat behauptet, dass eine ausgehende UDP-Verbindung sofort "offen" ist, werden keine Daten gesendet, bis etwas von der Standardeingabe gelesen wird. Erst danach kann festgestellt werden, ob am anderen Ende wirklich ein UDP-Server vorhanden ist, und oft kann man es einfach nicht sagen. Die meisten UDP-Protokolle verwenden Zeitüberschreitungen und Wiederholungsversuche, um ihre Aufgabe zu erledigen, und in vielen Fällen werden sie überhaupt nicht antworten. Daher sollten Sie eine Zeitüberschreitung angeben und auf das Beste hoffen.

OK, vielleicht ist das keine so gute Erklärung, aber ich konnte sie finden.

Wenn Sie dies noch nicht getan haben, möchten Sie möglicherweise mit allen Netcat-Optionen experimentieren, die mit dem Warten zu tun haben. Haben Sie experimentiert mit:

• Verwenden Sie sowohl -l als auch -u, um sicherzustellen, dass Sie sich im "Listening" -Modus befinden

• -vv um genau zu sehen, was passiert

• -q -1 ... was "ewig warten" sollte, auch nachdem EOF empfangen wurde (hoffentlich wieder zuhören?)

Sie können dafür verwenden socat. Es hat eine sehr schöne Option fork:

fork Behandelt nach dem Herstellen einer Verbindung seinen Kanal in einem untergeordneten Prozess und versucht, dass der übergeordnete Prozess versucht, mehr Verbindungen herzustellen, entweder durch Abhören oder durch Verbinden in einer Schleife (Beispiel).

Client (ja, das führen Sie vom Client aus):

$ ssh -L 7753:localhost:7753 YourServer.com "/usr/bin/socat tcp4-listen:7753,reuseaddr,fork UDP:8.8.8.8:53"

Klient:

$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753

$ dig @127.0.0.1 google.com