Se nada bloquear o tráfego, traceroutenormalmente termina com o IP de destino como último salto. (10.1.1.10 neste caso)
Normal tracerouteseria assim.
user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
1 10.2.8.2 (10.2.8.2) 0.572 ms 0.692 ms 0.837 ms
2 10.1.9.50 (10.1.9.50) 202.638 ms 10.1.9.78 (10.1.9.78) 202.547 ms 10.1.9.50 (10.1.9.50) 202.139 ms
3 10.1.4.9 (10.1.4.9) 202.508 ms 202.483 ms 10.1.4.13 (10.1.4.13) 204.149 ms
4 10.1.1.10 (10.1.1.10) 202.133 ms 202.100 ms 202.692 ms
user@linux:~$
Recentemente, encontrei um problema em que havia um salto adicional (10.1.1.9) na traceroutesaída (veja o salto 5).
Endereço IP de origem: 10.2.8.8
user@linux:~$ ifconfig | head -2
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.2.8.8 netmask 255.255.255.0 broadcast 10.2.8.255
user@linux:~$
Endereço IP de destino: 10.1.1.10
Salto adicional: 10.1.1.9 ???
user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
1 10.2.8.2 (10.2.8.2) 0.572 ms 0.692 ms 0.837 ms
2 10.1.9.50 (10.1.9.50) 202.638 ms 10.1.9.78 (10.1.9.78) 202.547 ms 10.1.9.50 (10.1.9.50) 202.139 ms
3 10.1.4.9 (10.1.4.9) 202.508 ms 202.483 ms 10.1.4.13 (10.1.4.13) 204.149 ms
4 10.1.1.10 (10.1.1.10) 202.133 ms 202.100 ms 202.692 ms
5 10.1.1.9 (10.1.1.9) 6201.720 ms !H * *
user@linux:~$
Além disso, se você observar os saltos 2 e 3, há endereços IP adicionais (10.1.9.78 e 10.1.9.50)
Por quê isso aconteceu? Nunca vi nada assim antes.
Isso foi por causa da configuração do servidor?
Responder1
traceroutefunciona enviando pacotes de eco UDP ou ICMP com campos de tempo de vida (TTL) aumentando sequencialmente. O TTL é diminuído em 1 por cada roteador que processa o pacote.
Ele espera dois tipos de respostas às suas sondagens.
- Se o TTL atingir 0 quando um roteador o diminuir, ele responderá com uma mensagem ICMP Time-Exceeded e não encaminhará o pacote.
- O destino final responde com uma mensagem ICMP Port-Unreachable (no caso UDP) ou uma mensagem ICMP Echo-Response (no caso ICMP).
Ao receber o segundo tipo, ele sabe que chegou ao destino e para de enviar sondas com TTLs mais altos. Observe quenãobaseie essa decisão no endereço de onde vem a resposta - se receber uma mensagem de tempo excedido do endereço de destino, ela continuará aumentando.
Portanto, seu rastreamento indica que um roteador respondeu com Time-Exceeded e o endereço de destino como origem. Isso provavelmente significa que é um roteador executando NAT e o endereço de destino é o endereço público correspondente a um endereço privado por trás dele.
O que é estranho, porém, é que a resposta final veio de umdiferenteendereço. Normalmente você esperaria que a resposta voltasse pelo roteador, então seu IP privado seria traduzido de volta para o IP público. Nesse caso, você veria duas linhas com 10.1.1.10 como endereço.
Aparentemente, neste caso, o caminho de 10.1.1.9 para a máquina original não precisa passar pelo roteador NAT, portanto seu endereço não é traduzido. O roteamento assimétrico muitas vezes pode produzir tracerouteresultados anômalos. Nesse caso, todas as suas máquinas estão dentro do espaço de endereço privado 10.0.0.0/8, portanto não é de surpreender que existam caminhos diretos disponíveis.
Responder2
Sem saber a configuração do roteador, não há como ter certeza - no entanto, um motivo provável é o NAT de destino, também conhecido como NAT reverso, também conhecido como encaminhamento de porta ou - neste caso - um host exposto.
O roteador 10.1.1.10 pode ser configurado para encaminhar/DNATtudopara o host 10.1.1.9 (=host exposto), incluindo solicitações de IPs privados. De um IP público, você veria um último salto duplo porque o destino real 10.1.1.9 está oculto pelo roteador NAT. Neste caso é possível que apenas a solicitação seja DNATada e a resposta seja encaminhada como está.
Também é possível que 10.1.1.10 e 10.1.1.9 sejam DNATados em outro lugar e o último seja o endereço de resposta padrão. Isso explicaria o grande aumento do RTT.
Responder3
Preste atenção nos horários. Traceroute envia pacotes que solicitam que switches ou roteadores respondam à fonte com a resposta "Estou processando". Mas esses pacotes podem levar seu destino, sua máquina neste exemplo, com ordem variada, dependendo das configurações de TTL e tempo de resposta, dependendo tanto da configuração dos dispositivos entre eles, das tabelas de roteamento e da topologia da rede.