Netcat hört auf, UDP-Verkehr zu überwachen

14124
heavyd

Ich verwende netcat auf einigen Linux-Maschinen (siehe diese andere Frage) ), aber unerwartetes Verhalten.

Im Gegensatz zum Leitfaden in der akzeptierten Antwort verwende ich kein UDP-Tunneln für DNS-Abfragen. Ich habe einen Remote-Server, bei dem ich mich anmelden kann, aber keine Software installiere. Ich versuche, UDP-Verkehr von meinem Computer auf den Server zu tunneln und dann einen separaten Tunnel einzurichten, um UDP-Antworten vom Server an meinen Computer zu senden .

Der Tunnel, der von meinem Computer zum Server führt, funktioniert einwandfrei. Auf der Serverseite wird der Listener jedoch durch die Instanz von netcat, die auf die Antwort des UDP-Servers wartet, den Listener schließen, nachdem die erste Antwort empfangen wurde. Ich kann also eine Anfrage senden und 1 Antwort zurückbekommen, aber alle nachfolgenden Anfragen machen es zum Server, aber es werden keine Antworten empfangen. Mit netstat kann ich sehen, dass netcat vor dem Empfang der Antwort hört, aber der Port wird dann geschlossen, nachdem die Antwort empfangen wurde.

Die netcat-Instanz auf meinem Rechner scheint alles gut zu beherrschen. Auf beiden Rechnern läuft netcat v1.10-38. Irgendwelche Ideen, was los ist?

8

2 Antworten auf die Frage

2
pbr

Es gibt also mehrere Dinge, die netcat genannt 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 das Erklären recht gut macht.

UDP-Verbindungen werden anstelle von TCP geöffnet, wenn -u angegeben wird. Dies sind keine "Verbindungen" an sich, da UDP ein verbindungsloses Protokoll ist, obwohl netcat intern den Mechanismus "Verbundener UDP-Socket" verwendet, der von den meisten Kerneln unterstützt wird. 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 tatsächlich ein UDP-Server am anderen Ende vorhanden ist, und oft kann man es nicht sagen. Die meisten UDP-Protokolle verwenden Timeouts und Wiederholungsversuche, um ihre Sache zu erledigen, und in vielen Fällen werden sie gar nicht erst antworten. Daher sollten Sie ein Timeout angeben und auf das Beste hoffen.

OK, vielleicht ist das keine sehr gute Erklärung, aber ich könnte es finden.

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

  • Verwenden Sie -l und -u, um sicherzustellen, dass Sie sich im "Hörmodus" befinden

  • -vv, um genau zu sehen, was passiert

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

Dies ist jetzt eine akzeptierte Antwort, aber wir wissen nicht, welche der Tipps sich als nützlich erwiesen haben :( törzsmókus vor 11 Jahren 3
1
Andrey Arapov

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

fork Nachdem eine Verbindung hergestellt wurde, wird der Kanal in einem untergeordneten Prozess behandelt. Der übergeordnete Prozess versucht, weitere Verbindungen herzustellen, entweder durch Abhören oder durch Verbinden in einer Schleife (Beispiel).

Client (ja, Sie laufen 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

Verwandte Probleme