O traceroute inclui IP não roteável (?)

Eu executei o seguinte traceroute uma vez, enquanto tentava desmontar um problema de rede.

c:\>tracert linode.com -d

Tracing route to linode.com [67.18.186.61]
over a maximum of 30 hops:

  1    <1 ms     *       <1 ms  10.43.51.252
  2     1 ms    <1 ms    <1 ms  10.45.253.33
  3    <1 ms    <1 ms    <1 ms  10.62.254.251
  4    20 ms    23 ms    45 ms  192.118.32.52
  5    47 ms    20 ms    85 ms  207.232.60.250
  6    54 ms    24 ms    79 ms  212.143.8.69
  7     7 ms    79 ms    11 ms  212.143.8.209
  8    89 ms   110 ms   108 ms  212.143.12.75
  9   143 ms   240 ms    94 ms  212.143.14.154
 10   244 ms   179 ms    95 ms  10.50.1.1
 11   176 ms    80 ms   190 ms  195.66.225.105
 12   174 ms   164 ms   157 ms  70.87.255.217
 13   187 ms   185 ms   186 ms  70.87.253.189
 14   189 ms   194 ms   195 ms  70.87.253.18
 15   187 ms   188 ms   190 ms  70.87.253.126
 16   187 ms   185 ms   185 ms  70.87.254.78
 17   186 ms   184 ms   187 ms  67.18.186.61

Trace complete.

Os três primeiros sites são roteadores / gateways locais; ignore aqueles.

Não tenho certeza, no entanto, como a etapa 10 poderia me dar a 10.50.1.1 como destino? Não é um IP irrecuperável que não deve ser encontrado em nenhum lugar de um roteador público?

Os endereços RFC1918 (10/8, 172.16 / 12 e 192.168 / 16) não devem aparecer nas tabelas de roteamento global, pois foram projetados para serem usados ​​em "uma única empresa". No entanto, faz sentido, até certo ponto, usar endereços RFC1918 para seus links ponto a ponto em seu núcleo, mesmo se o tráfego que passa por esses links for para intervalos de endereços IP "globalmente roteáveis", pois isso conserva um recurso um pouco escasso .

O motivo pelo qual aparece no traceroute é que o TTL de um quadro IP expirou em uma interface com isso como seu IP de interface. O lado negativo de fazer isso é que fica mais difícil executar ping na interface e solucionar alguns problemas do problema, mas não há garantia de que você possa fazer isso de qualquer maneira.

Então, eu diria que pode ser um pouco incomum, mas certamente não é inédito.

Isso me parece estranho. Também é perfeitamente aceitável ver IPs privados no meio de uma rota, porque uma única organização pode usar um IP privado em sua rede. Mas, de acordo com whois, 212.143.14.154 e 195.66.225.105 são de propriedade de duas organizações diferentes. Mas talvez essas duas organizações tenham um ponto a ponto entre si, caso em que poderiam usar um IP privado para isso.

O termo não roteável não é totalmente preciso, pois pode ser roteado. No entanto, o deve ser usado apenas por uma única 'empresa', o termo RFC1918 . É por isso que acho isso um pouco estranho.

Eu vi isso acontecendo em alguns roteadores zimbro. Eles tinham endereços IP públicos adequados atribuídos, mas o roteador estava enviando respostas icmp com IP privado vinculado à interface de gerenciamento (inacessível pela Internet pública).

É possível que esteja passando pela rede interna de alguém, por MPLS ou algo semelhante, onde eles estão usando IPs internos.

Eu concordo com Cian. Às vezes, esses saltos de WAN têm um endereço IP privado de loopback. Por algum motivo, isso é retornado no tracert. Um programa chamado Wireshark (realmente bom freeware) pode fornecer mais informações sobre o seu problema de rede.

Manni