o traceroute não imprime a rota inteira às vezes

Monitorando minha rede, percebi há algum tempo que o traceroute costumava imprimir rotas mais completas do que está fazendo agora ... e, agora, às vezes o traceroute omite alguns dispositivos.

Por exemplo, este é um traceroute mais completo, incluindo meu gateway:

$ sudo traceroute -F xxx.xx.136.5

traceroute to xxx.xx.136.5 (xxx.xx.136.5), 30 hops max, 60 byte packets

 1  * * *

 2  192.168.1.1 (192.168.1.1)  1.607 ms  1.604 ms  1.627 ms

 3  xxx.xx.136.5 (xxx.xx.136.5)  3.286 ms  5.729 ms  7.416 ms

Agora, exatamente o mesmo comando omite meu gateway:

$ sudo traceroute -F xxx.xx.136.5

traceroute to xxx.xx.136.5 (xxx.xx.136.5), 30 hops max, 60 byte packets

1  xxx.xx.136.5 (xxx.xx.136.5)  24.004 ms  28.267 ms  42.343 ms

Esses comandos foram dados na mesma máquina.

Como posso definir para sempre ter a rota inteira?

Qualquer forma de traceroute funciona incrementando o TTL de um pacote IP em um. O primeiro pacote possui um TTL de um e o roteador 1 diminui o temporizador e envia uma massagem de erro via ICMP (tempo de vida excedido). O traceroute padrão * NIX usa UDP, o Windows tracert ICMP, e também existem versões que usam TCP.

Existem casos diferentes pelos quais você não vê um salto:

• As pessoas pensam que o ICMP é mau e o bloqueiam. Isso levará a muitos problemas (por exemplo, descoberta de PMTU).
• As pessoas pensam apenas no Windows e bloqueiam o UDP. Tente correr traceroute -Ideve ao truque.
• você também pode tentar usar o tcptraceroute
• Se um roteador está ocupado roteando pacotes, não tenho os recursos para enviar pacotes ICMP.

Eu prefiro usar tcptraceroutepara um melhor detalhe do roteamento hop-to-hop.

tcptracerouteignora essencialmente a maioria dos firewalls de proteção que ignoram os pacotes ICMP usados ​​por traceroute. Use a porta 80 ou 53.

Se o seu gateway tiver uma opção de log, ative-o. Você pode encontrar uma entrada explicando o comportamento observado. Um roteador pode interpretar ICMP repetido como DOS.

... embora, intuitivamente, se possa esperar que a fonte esteja na rede externa.

Eu descobri o que realmente acontece com o traceroute (e mtr, tpctraceroute, etc) na minha intranet. É o meu próprio roteador que esconde lúpulos conhecidos. Meu roteador (como um TP-Link WAP, com Linux 2.6.15) usa para ocultar os saltos para rotas conhecidas. Portanto, vg, dando traceroute no google, gera apenas um salto, o próprio google, porque meu roteador conhece muito bem a rota (eu fico o dia inteiro usando o google). Mas, basta conectar um PC diretamente no ponto de acesso e, em seguida, dar um traceroute em direção ao google, ele retorna toda a rota daqui para o google.

Então, agora eu sei o que está acontecendo, mas não por que faz isso dessa maneira.

Como solução alternativa, uso o tracerout fornecido pelo linux incorporado em execução no roteador (problemático): ou seja, o roteador que, através do meu PC, oculta saltos, em seu próprio sistema incorporado fornece uma interface que executa o tracerout corretamente ...

Seja como for, obrigado pela resposta!

A implementação de um novo host e notou que a rota de rastreamento mostraria apenas o endereço do gateway local, o endereço na LAN dos hosts, mas todos os outros saltos eram exibidos como * 's.

Quando executei o TCPDUMP no mesmo host enquanto fazia a rota de rastreamento, pude ver que o TTL do ICMP excedia as mensagens geradas pelos nós no caminho, mas TRACEROUTE simplesmente não exibia os endereços IP ... apenas mais * 's.

O host tinha duas interfaces de rede, a Interface A, que tinha uma rota padrão configurada e a Interface B, que tinha uma rota estática para o Destino. Foi na Interface B que eu estava executando a rota de rastreamento, que exibia apenas * 's.

Para tentar resolver o problema, adicionei outra rota estática ao segundo salto, o próximo roteador no caminho, para que eu pudesse trabalhar em um caminho muito mais curto. Quando iniciei o teste, o segundo salto foi exibido apenas como *, mas assim que adicionei uma rota estática à rota de rastreamento de rede, seu endereço IP foi exibido.

Fiz uma rota de rastreamento para o destino final novamente e observei todos os endereços IP que geravam mensagens ICMP TTL excedidas para garantir que o roteamento da Interface B tivesse todas essas redes configuradas estaticamente. Quando fiz isso, agora podia ver todos os IPs listados no resultado das rotas de rastreamento.

Portanto, parece que se a Interface que recebe as mensagens excedidas do ICMP TTL não tiver roteamento de volta para esse endereço, ela não será exibida nos resultados da rota de rastreamento. Tenho certeza de que alguém da comunidade pode explicar por que se comporta dessa maneira, mas um host com várias interfaces executando a rota de rastreamento em uma interface que não possui a rota padrão configurada é praticamente uma perda de tempo.