Por que o traceroute terminou com um salto adicional após o destino?

3

Se nada bloquear o tráfego, traceroute normalmente terminará com o IP de destino como o último salto. (10.1.1.10 neste caso)

Normal traceroute seria 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 pelo qual havia um salto adicional (10.1.1.9) na saída traceroute (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

Lúpulo 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 o salto 2 e 3, haverá endereços IP adicionais (10.1.9.78 e 10.1.9.50)

Por que isso aconteceu? Eu nunca vi nada assim antes.

Foi por causa da configuração do servidor?

    
por Sabrina 04.09.2018 / 17:42

3 respostas

3

traceroute funciona enviando pacotes de eco UDP ou ICMP aumentando sequencialmente os campos Tempo de vida (TTL). O TTL é diminuído em 1 por cada roteador que processa o pacote.

Espera dois tipos de respostas para suas sondas.

  • Se o TTL atingir 0 quando um roteador o decrementar, ele responderá com uma mensagem de tempo excedido de ICMP e não encaminhará o pacote.
  • O destino final responde com uma mensagem ICMP port-inacessível (no caso UDP) ou ICMP Echo-Response (no caso ICMP).

Quando recebe o segundo tipo, ele sabe que atingiu o destino e para de enviar testes com TTLs mais altos. Note que não baseia esta decisão no endereço de onde a resposta vem - se ela receber uma mensagem de Tempo Excedido do endereço de destino, ela continuará incrementando.

Portanto, o seu traço indica que um roteador respondeu com o Time-Exceeded e o endereço de destino como sua origem. Isso provavelmente significa que é um roteador que executa NAT e o endereço de destino é o endereço público correspondente a um endereço particular por trás dele.

O que é estranho, porém, é que a resposta final veio de um endereço diferente . Normalmente, você esperaria que a resposta voltasse pelo roteador, para que seu IP privado fosse traduzido de volta para o IP público. Nesse caso, você veria duas linhas com 10.1.1.10 como o 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 geralmente pode produzir resultados traceroute anômalos. Nesse caso, todas as suas máquinas estão no espaço de endereço privado 10.0.0.0/8, portanto, não é totalmente surpreendente que existam caminhos diretos disponíveis.

    
por 05.09.2018 / 17:14
1

Sem saber a configuração do roteador, não há como ter certeza - no entanto, uma razão provável é o NAT de destino, também conhecido como NAT, ou - neste caso, um host exposto.

O roteador 10.1.1.10 pode ser configurado para encaminhar / DNAT tudo para o host 10.1.1.9 (= host exposto), incluindo solicitações de IPs privados. De um IP público, você veria um double last hop, porque o destino real 10.1.1.9 está oculto pelo roteador NAT. Nesse caso, é possível que apenas a solicitação seja DNATed e a resposta seja encaminhada como está.

Também é possível que tanto o 10.1.1.10 quanto o 10.1.1.9 sejam DNATed em outro lugar e o último seja o endereço de resposta padrão. Isso explicaria o grande aumento de RTT.

    
por 04.09.2018 / 19:24
-1

Preste atenção nos horários. O traceroute envia pacotes que solicitam chaves ou roteadores para responder à fonte com a resposta "Estou processando". Mas estes pacotes podem ter seu destino, sua máquina neste exemplo, com várias ordens, dependendo das configurações de TTL e tempo de resposta, dependendo tanto da configuração dos dispositivos entre, das tabelas de roteamento e da topologia da rede.

    
por 04.09.2018 / 18:52

Tags