O Netcat para de ouvir o tráfego UDP

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

Ao contrário do guia na resposta aceita, não estou usando o encapsulamento UDP para fazer consultas DNS. Eu tenho um servidor remoto no qual posso efetuar login, mas não consigo instalar o software, e estou tentando encapsular o tráfego UDP do meu computador para o servidor e, em seguida, configurar um túnel separado para enviar respostas UDP do servidor para a 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 após receber a primeira resposta. Para que eu possa enviar uma solicitação e obter 1 resposta de volta, mas todas as solicitações subsequentes tornam o servidor aceitável, mas as respostas não são recebidas. Usando o netstat, posso ver que antes da resposta ser recebida, o netcat está atendendo, mas a porta é fechada depois que a resposta é recebida.

A instância 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?

Portanto, existem várias coisas chamadas netcat; O ubuntu ainda possui / etc / alternative simbólico-link-hackery para ele.

Eu acho que parte do seu problema é que o UDP não faz sessões; Copiei parte do arquivo /usr/share/doc/netcat-traditional/README.gz abaixo, que faz um bom trabalho de explicação.

As conexões UDP são abertas em vez do TCP quando -u é especificado. Essas não são realmente "conexões" em si, já que o UDP é um protocolo sem conexão, embora o netcat use internamente o mecanismo "socket UDP conectado" que a maioria dos kernels suporta. Embora o netcat afirme que uma conexão UDP de saída está "aberta" imediatamente, nenhum dado é enviado até que algo seja lido da entrada padrão. Somente depois disso é possível determinar se realmente existe um servidor UDP do outro lado, e geralmente você não sabe. A maioria dos protocolos UDP usa tempos limite e novas tentativas para executar suas tarefas e, em muitos casos, não se incomoda em responder, portanto, você deve especificar um tempo limite e esperar o melhor.

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

Se você ainda não o fez, pode experimentar qualquer opção de netcat que possa estar relacionada à espera ... você já experimentou:

• usando -l e -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 (espero, ouvindo de novo?)

Você pode usar socatpara isso. Tem uma opção muito boa fork:

fork Depois de estabelecer uma conexão, lida com seu canal em um processo filho e mantém o processo pai tentando produzir mais conexões, ouvindo ou conectando em um loop (exemplo).

Cliente (sim, você executa a partir 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