Pacotes retornando, mas o traceroute falha

Question

Eu recebo essa saída do traceroute:

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72

1  192.168.12.1 (192.168.12.1)  1.410 ms  2.076 ms  2.251 ms
2  * * *
3  * * *
etc..

Mas em outro terminal, posso ver as respostas corretas (Port Unreachable) chegando do host de destino:

9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)     
9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)

No começo eu pensei que era um problema de firewall, mas eu verifiquei e nenhum pacote está sendo descartado. A única coisa que vem à mente é que este é o segundo NIC ...

Se eu executar o traceroute no mesmo host na primeira NIC, recebo o mesmo rastreio wireshark como acima (obviamente com um IP de origem diferente) - mas o comando traceroute é bem-sucedido.

Eu não entendo como o wireshark pode ver as respostas, mas o traceroute falha no segundo NIC.

Acho que estou sentindo falta de algo bem básico aqui ...

    

Answer 1

O Wireshark mostrará o que chega na interface de rede. O kernel obviamente viu esses pacotes, mas por algum motivo decidiu que eles não devem ser entregues ao comando traceroute.

Há algumas coisas que poderiam ter dado errado, fazendo com que o kernel decidisse não entregar esses pacotes.

• Você pode ter um roteamento assimétrico que não é adequado para a filtragem de caminho inverso, mas deixou rp_filter ativado.
• O kernel pode não corresponder ao conteúdo da mensagem de erro ICMP com um soquete local. Isso pode acontecer porque o pacote foi truncado com informações insuficientes disponíveis para tomar essa decisão. Isso também pode acontecer devido a alguma configuração NAT quebrada, em que os pacotes em uma direção são roteados por meio de um NAT, mas não em outra direção.
• O kernel pode descartar os pacotes devido a uma soma de verificação ruim.

Destes, acho que o rp_filter parece a explicação mais provável. Você não especificou um sistema operacional, mas parece que ele pode ser um sistema Linux, portanto, tente este comando: head /proc/sys/net/ipv4/conf/*/rp_filter . Você provavelmente veria 1 em cada um deles, o que significa que o filtro está ativado. Tente escrever um 0 para o que corresponde à interface da qual os pacotes estão sendo descartados, bem como para o nome do dispositivo all .

    

Answer 2

Você pode postar a saída da tabela de roteamento de cada caixa aqui? Se você tiver uma rota padrão inválida / ausente, os pacotes não terão um caminho de retorno. Por favor, poste a saída de:

# ip route list

em cada caixa do Linux.