Por que o tcpdump vê uma resposta, mas não o netcat

Question

Estou depurando uma conexão site a site do OpenVPN usando o UDP no netcat.

Eu posso fazer com que os pacotes fluam em uma direção (host A- > host B), mas não na reversa.

root@hosta:~# nc 10.0.3.2 1234 -u

root@hostb:~# nc -l 1234 -u

O mais estranho é que, ao executar tcpdump no host A, eu realmente vejo o pacote UDP chegando do host B:

root@hosta:~# tcpdump port 1234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:36:04.695423 IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
17:36:06.484233 IP 10.0.3.2.1234 > hosta.46603: UDP, length 4

No entanto, o netcat não produz nada. Eu tentei strace no nc e nada é recebido do soquete.

O que mais posso fazer para diagnosticar isso?

    

Answer 1

Com apenas os comandos dados, isso teria sido fácil! O padrão do Netcat é TCP sem -u para o UDP. Enquanto nc -lp 1234 -u ouve as conexões UDP na porta 1234, nc 10.0.3.2 1234 tenta abrir uma conexão TCP.

Sugiro adicionar -v -v ao seu Netcat nos dois extremos, pois ele fornecerá as estatísticas enviadas / rcvd no final. Por favor adicione esta informação e também corrija os comandos que você estava usando para que pudéssemos saber que você tinha sua condição de depuração correta.

Use também tcpdump port 1234 -XX para ver o que há dentro desses pacotes em HEX e ASCII.

No entanto, com base na saída de tcpdump port 1234 , você provavelmente ainda tem os comandos certos, mas vamos brincar um pouco com esse erro para ver como podemos saber isso:

Desde que você tem pacotes UDP

IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
IP 10.0.3.2.1234 > hosta.46603: UDP, length 4

em vez de pacotes TCP como

IP hosta.46603 > 10.0.3.2.1234: Flags [S], seq 1384271454, win 14600, options [mss 1460,sackOK,TS val 1969077197 ecr 0,nop,wscale 3], length 0
IP 10.0.3.2.1234 > hosta.46603: Flags [R.], seq 0, ack 1384271455, win 0, length 0

vamos supor que você o teve e vice-versa:

root@hosta:~# nc 10.0.3.2 1234 -u
root@hostb:~# nc -lp 1234 

Mas, neste caso, você só teria visto o primeiro

IP hosta.46603 > 10.0.3.2.1234: UDP, length 4

e não teria havido nenhum pacote UDP na outra direção!

Então, se você acidentalmente usou o mesmo nc <IP> 1234 -u em ambas as extremidades, você teria as duas linhas, mas as portas não seriam as mesmas, mas algo como:

IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
IP 10.0.3.2.73644 > hosta.1234: UDP, length 4

    

Answer 2

A resposta pode ser semelhante à resposta desta pergunta: Os pacotes encaminhados são visíveis pelo tcpdump, mas não são recebidos por aplicação

É hostA em uma rede diferente de hostB? O hostB retorna ao hostA (ele tem uma rota para o hostA? Se não, o net.ipv4.conf.*.rp_filter está desativado?

A solução se hostB não tem como rota o hostA é adicionar uma rota ou desabilitar rp_filter (filtro de caminho reverso).