☰

Pacotes retornando, mas o traceroute falha

tag-icon • tag-icon wireshark networking
Pacotes retornando, mas o traceroute falha

Eu recebo esta 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 (Porta Inacessível) 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)

A princípio pensei que fosse um problema de firewall, mas verifiquei e nenhum pacote foi descartado. A única coisa que me vem à mente é que esta é a segunda NIC...

Se eu executar o traceroute para o mesmo host na primeira NIC, obterei o mesmo rastreamento wireshark acima (obviamente com um IP de origem diferente) - mas o comando traceroute será bem-sucedido.

Não entendo como o wireshark pode ver as respostas, mas o traceroute falha na segunda NIC.

Acho que estou faltando algo bem básico aqui....

Responder1

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

Existem 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 filtragem de caminho reverso, mas deixou rp_filterativado.
  • O kernel pode não conseguir corresponder o conteúdo da mensagem de erro ICMP com um soquete local. Isso pode acontecer devido ao pacote ter sido truncado com informações insuficientes disponíveis para tomar tal decisão. Isso também pode acontecer devido a alguma configuração NAT quebrada, onde os pacotes em uma direção são roteados através de um NAT, mas não na outra direção.
  • O kernel pode descartar os pacotes devido a uma soma de verificação incorreta.

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

Responder2

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:

# lista de rotas ip

em cada caixa Linux.

informação relacionada