O Netcat pára de escutar tráfego UDP

Question

Estou usando o netcat em algumas máquinas Linux (veja esta outra pergunta ), mas vendo algum comportamento inesperado.

Ao contrário do guia na resposta aceita, não estou usando o tunelamento UDP para fazer consultas DNS. Eu tenho um servidor remoto que eu posso fazer logon, mas não instalar o software, e eu estou tentando túnel de tráfego UDP do meu computador para o servidor e, em seguida, configurar um túnel separado para enviar respostas UDP de volta do servidor para minha máquina .

O túnel que vai da minha máquina para o servidor está funcionando perfeitamente, no entanto, no lado do servidor, a instância do netcat que está ouvindo a resposta do servidor UDP fechará o ouvinte depois de receber a primeira resposta. Assim, posso enviar uma solicitação e obter 1 resposta de volta, mas todas as solicitações subseqüentes chegam ao servidor, mas as respostas não são recebidas. Usando o netstat, posso ver que, antes que a resposta seja recebida, o netcat está escutando, mas a porta é fechada depois que a resposta é recebida.

A instância do netcat na minha máquina parece lidar com tudo muito bem. Ambas as máquinas estão executando o netcat v1.10-38. Alguma idéia do que está acontecendo?

    

Answer 1

Portanto, existem várias coisas chamadas netcat; O ubuntu tem até mesmo / etc / alternatives link simbólico para ele.

Acho que parte do seu problema é que o UDP não faz sessões; Eu copiei parte do arquivo /usr/share/doc/netcat-traditional/README.gz abaixo, o que explica muito bem.

UDP connections are opened instead of TCP when -u is specified. These aren't really "connections" per se since UDP is a connectionless protocol, although netcat does internally use the "connected UDP socket" mechanism that most kernels support. Although netcat claims that an outgoing UDP connection is "open" immediately, no data is sent until something is read from standard input. Only thereafter is it possible to determine whether there really is a UDP server on the other end, and often you just can't tell. Most UDP protocols use timeouts and retries to do their thing and in many cases won't bother answering at all, so you should specify a timeout and hope for the best. You will get more out of UDP connections if standard input is fed from a source of data that looks like various kinds of server requests.

OK, então talvez isso não seja uma grande explicação, mas é o que eu pude encontrar.

Se ainda não o fez, talvez queira experimentar todas as opções do netcat que possa encontrar relacionadas com a espera ... experimentou:

• usando -l e também -u para garantir que você esteja no modo "ouvindo"

• -vv para ver exatamente o que está acontecendo

• -q -1 ... o que deve "esperar para sempre" mesmo depois de receber EOF (esperamos, ouvindo de novo?)

Answer 2

Você pode usar socat para isso. Tem opção muito legal fork :

fork After establishing a connection, handles its channel in a child process and keeps the parent process attempting to produce more connections, either by listening or by connecting in a loop (example).

Cliente (sim, isso você executa do cliente):

$ 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