Netcat interrompe l'ascolto del traffico UDP

Sto usando netcat su alcune macchine Linux (vedi questa altra domanda ), ma vedo alcuni comportamenti inaspettati.

A differenza della guida nella risposta accettata, non sto utilizzando il tunneling UDP per eseguire query DNS. Ho un server remoto su cui posso accedere, ma non installare il software, e sto provando a tunnelizzare il traffico UDP dal mio computer al server, e quindi impostare un tunnel separato per inviare le risposte UDP dal server alla mia macchina .

Il tunnel che va dalla mia macchina al server funziona perfettamente, tuttavia sul lato server, l'istanza di netcat che sta ascoltando la risposta dal server UDP chiuderà l'ascoltatore dopo aver ricevuto la prima risposta. Quindi posso inviare una richiesta e ottenere 1 risposta indietro, ma tutte le richieste successive riescono a farlo funzionare correttamente sul server ma le risposte non vengono ricevute. Usando netstat posso vedere che prima che la risposta sia ricevuta netcat è in ascolto, ma la porta viene quindi chiusa dopo che la risposta è stata ricevuta.

L'istanza netcat sulla mia macchina sembra gestire tutto bene. Entrambe le macchine eseguono netcat v1.10-38. Qualche idea su cosa sta succedendo?

Quindi ci sono più cose chiamate netcat; Ubuntu ha anche / etc / alternatives simbolic-link-hackery per questo.

Penso che parte del tuo problema sia che UDP non fa sessioni; Ho copiato in parte il file /usr/share/doc/netcat-traditional/README.gz sotto il quale fa un ottimo lavoro di spiegazione.

Le connessioni UDP vengono aperte anziché TCP quando viene specificato -u. Queste non sono in realtà "connessioni" di per sé poiché UDP è un protocollo senza connessione, sebbene netcat utilizzi internamente il meccanismo "socket UDP connesso" supportato dalla maggior parte dei kernel. Sebbene netcat affermi che una connessione UDP in uscita è "aperta" immediatamente, nessun dato viene inviato fino a quando qualcosa non viene letto dall'input standard. Solo in seguito è possibile determinare se esiste davvero un server UDP all'altra estremità e spesso non si riesce a capire. La maggior parte dei protocolli UDP usa i timeout e i tentativi per fare le loro cose e in molti casi non si preoccuperà affatto di rispondere, quindi dovresti specificare un timeout e sperare per il meglio.

OK, quindi forse non è una spiegazione così grande, ma è quello che ho potuto trovare.

Se non l'hai ancora fatto, potresti voler sperimentare eventuali opzioni netcat che potresti avere a che fare con l'attesa ... hai sperimentato con:

• usando -l e -u per assicurarti di essere in modalità "ascolto"

• -vv per vedere esattamente cosa sta succedendo

• -q -1 ... che dovrebbe "aspettare per sempre" anche dopo aver ricevuto EOF (si spera, l'ascolto di nuovo?)

Puoi usarlo socatper quello. Ha un'opzione molto bella fork:

fork Dopo aver stabilito una connessione, gestisce il suo canale in un processo figlio e mantiene il processo genitore che tenta di produrre più connessioni, ascoltando o connettendosi in un ciclo (esempio).

Client (sì, questo viene eseguito dal client):

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

Cliente:

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

$ dig @127.0.0.1 google.com