
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_filter
ativado. - 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_filter
que 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 1
cada um deles, o que significa que o filtro está ativado. Tente escrever um 0
correspondente à interface da qual os pacotes estão sendo descartados, bem como ao all
nome 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.