Entradas vazias (***) ao usar traceroute em um PC, mas não ao usar traceroute no roteador

Question

Hoje, quando tento rastrear o www.google.com do meu roteador e do meu PC, vi um comportamento estranho.

Traceroute do roteador

traceroute to www.google.com (173.194.38.176), 30 hops max, 40 byte packets
 1  10.74.128.182 (10.74.128.182)  69.669 ms 10.74.128.178 (10.74.128.178)  36.885 ms 10.74.128.182 (10.74.128.182)  38.042 ms
 2  10.74.128.181 (10.74.128.181)  36.468 ms  37.848 ms  35.048 ms
 3  10.64.7.74 (10.64.7.74)  75.262 ms 10.64.7.86 (10.64.7.86)  44.339 ms  40.346 ms
 4  kph-148-48.tm.net.my (203.106.148.48)  40.021 ms  48.847 ms  39.153 ms
 5  10.64.7.90 (10.64.7.90)  41.705 ms  42.232 ms  40.001 ms
 6  10.55.34.234 (10.55.34.234)  48.969 ms  48.335 ms  49.216 ms
 7  * * 72.14.203.186 (72.14.203.186)  47.921 ms
 8  209.85.242.240 (209.85.242.240)  61.557 ms  61.469 ms  47.117 ms
 9  209.85.242.232 (209.85.242.232)  59.473 ms  61.54 ms  55.777 ms
10  72.14.233.105 (72.14.233.105)  64.806 ms  61.513 ms  59.459 ms
11  sin04s02-in-f16.1e100.net (173.194.38.176)  61.45 ms  56.76 ms  55.513 ms

Traceroute do PC

Tracing route to www.google.com [173.194.38.179] over a maximum of 30 hops:
  1     1 ms    <1 ms     1 ms  router.asus.com [192.168.1.1] 
  2   118 ms    81 ms   118 ms  10.74.128.178 
  3    38 ms    37 ms    39 ms  10.74.128.177 
  4    45 ms    50 ms    72 ms  10.64.7.86 
  5    43 ms    41 ms    41 ms  kph-148-48.tm.net.my [203.106.148.48] 
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  And onwards like that…

  Trace complete.

1. Por que existem dois endereços diferentes ( 10.74.128.182 e 10.74.128.178 )? Isso significa que o pacote é roteado para dois roteadores diferentes em um horário diferente? Se for esse o caso, por que o comando tracert no meu PC (Windows 7) não o mostrou?

2. No traceroute do roteador, os dois IPs do primeiro e segundo rastreio ( 10.74.128.178 e 10.74.128.181 ) estão no mesmo endereço de rede, pois ele é classificado como IP de classe A e classificado pelos primeiros 8 bits. 10. Por isso, fico imaginando como um pacote pode ser enviado para dois roteadores que estão na mesma rede?

3. Por que o comando tracert no meu PC mostra resultado vazio * após kph-148-48.tm.net.my [203.106.148.48] , enquanto traços completos foram capturados pelo comando tracert do roteador?

4. No traceroute do roteador, depois da linha 4, que é um endereço público ( 203.106.148.481 ), os próximos 2 saltos são endereços privados ( 10.64.7.90 e 10.55.34.234 ). Depois disso, ele mudou de volta para o endereço público que pertence ao google ( 72.14.203.186 ). Eu pensei que o endereço privado deveria ser não-roteável na Internet? Quando tento pingar esses 2 endereços particulares, recebi a resposta. Por isso, pergunto-me como é possível que o meu PC consiga alcançar os IP nas redes privadas que vêm depois de um endereço público.

Answer 1

O traceroute funciona enviando pacotes IP com valores IP TTL (time to live) IP sucessivamente mais altos: 1,2,3 ... Cada salto diminui o TTL. Quando chega a 0, o pacote não é roteado, e uma mensagem de tempo excedido de ICMP é enviada para a fonte, que é como o traceroute de execução do sistema determina a rota.

1. Esta parece ser a versão do traceroute encontrada em muitas instalações do Linux. Este comando traceroute envia três pacotes para cada valor TTL. Então, o que você está vendo é que dois dos pacotes foram para 10.74.128.182 e um foi para 10.74.128.178 .

2. Como esse é o primeiro salto após o roteador, provavelmente é o endereço de gateway do roteador. É possível que o HSRP ou similar esteja em jogo: provavelmente há dois dispositivos de balanceamento de carga com um endereço IP flutuante. Por exemplo: você usa o endereço de gateway 10.0.0.1, mas nos bastidores isso realmente aponta para 10.0.0.2 e 10.0.0.3 que compartilham a carga. Isso é, de fato, possível HSRP . O roteamento classful não está mais em uso. o intervalo 10.0.0.0/8 é apenas o endereço IP RFC1918 que seu ISP está usando.

3. Diferentes versões do traceroute enviam diferentes pacotes para fora. A versão do Linux que você está usando no roteador envia pacotes UDP por padrão; a versão do windows no seu PC envia pings. Parece que os pings estão sendo bloqueados entre os saltos 5 e 6, mas isso é apenas um palpite. Experimente um utilitário traceroute diferente no seu PC e aposto que você obterá resultados diferentes.

4. Você está certo. Endereços RFC1918 não são roteáveis na internet pública. Então, minha resposta é que, mesmo que você veja um endereço IP público no salto 4, você ainda não saiu do seu ISP. Se você tivesse, não conseguirá obter mensagens expiradas TTL com endereços de origem privados. O endereçamento IP semelhante nos saltos 3 e 5 sugere isso também: ambos usam endereços em 10.64.7.0/24 (provavelmente não é uma coincidência). Basta dizer isso: os endereços IP são praticamente arbitrários e, dentro de sua própria rede, seu ISP é livre para ter roteadores que tenham interfaces com interfaces públicas e privadas. Este é o caso dos saltos 3 e 4. Também é possível que um pacote passe por roteadores sem endereços IP públicos após sair da rede do ISP; neste caso, você não deve receber uma resposta traceroute.