Traceroute obejmuje nieprzenośny adres IP (?)

9

Raz uruchomiłem następujący traceroute, próbując zdiagnozować problem z siecią.

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.

Pierwsze trzy lokalizacje to lokalne routery / bramy; zignoruj ​​je.

Nie jestem jednak pewien, jak krok 10 mógłby dać mi 10.50.1.1 jako cel? Czy to nie jest niemożliwy do przekierowania adres IP, którego nie powinno być nigdzie w publicznym routerze?

routing networking Mikeage
źródło

Odpowiedzi:

11

Adresy RFC1918 (10/8, 172.16 / 12 i 192.168 / 16) nie powinny pojawiać się w globalnych tablicach routingu, ponieważ zostały zaprojektowane do użytku w „pojedynczym przedsiębiorstwie”. Jednak do pewnego stopnia sensowne jest używanie adresów RFC1918 dla łączy punkt-punkt w rdzeniu, nawet jeśli ruch przechodzący przez te łącza jest przeznaczony dla zakresów adresów IP „globalnie routowalnych”, ponieważ pozwala to zaoszczędzić trochę zasobów .

Powodem, dla którego pojawia się w traceroute, jest to, że upłynął czas TTL ramki IP na interfejsie z tym adresem IP. Wadą tego jest to, że coraz trudniej jest pingować interfejs i rozwiązać problem, ale nie ma gwarancji, że powinieneś być w stanie to zrobić.

Powiedziałbym więc, że może to być trochę niezwykłe, ale z pewnością nie jest to niespotykane.

Vatine
źródło
Użyłem prefiksu z prywatnej przestrzeni adresowej „tymczasowo” (przez kilka miesięcy) dla trasy asymetrycznej. Klienci byli zdziwieni, ponieważ dzięki traceroute z ich komputerów do Internetu widzieli prywatne IP, ale z Internetu na IP, prywatne IP nie było wyświetlane.
Mircea Vutcovici
5

To wydaje mi się dziwne. Całkowicie dobrze jest widzieć prywatne adresy IP na środku trasy, ponieważ jedna organizacja może korzystać z prywatnego adresu IP w swojej sieci. Ale według whois, 212.143.14.154 i 195.66.225.105 są własnością dwóch różnych organizacji. Ale może te dwie organizacje mają między sobą punkt, w którym to przypadku mogłyby użyć prywatnego adresu IP.

Termin „nie routowalny” nie jest całkowicie dokładny, ponieważ można je trasować. Jednak powinien być używany tylko przez jedno „przedsiębiorstwo”, jak używa terminu RFC1918 . Dlatego uważam to za nieco dziwne.

Kyle Brandt
źródło
2
Oczywiście, whois nie jest tak niezawodny
Kyle Brandt
mogą mieć łącze PTP, ale skoro jeden jest izraelskim ISP [połączenie korporacyjne, w tym przypadku], a drugi jest głównym dostawcą usług hostingowych w USA [theplanet.com], wydaje się to dość dziwne.
Mikeage
3

Widziałem, jak to się dzieje na niektórych routerach jałowca. Mieli przypisane odpowiednie publiczne adresy IP, ale router wysyłał odpowiedzi icmp z prywatnym adresem ip, który był powiązany z interfejsem zarządzania (nieosiągalnym z publicznego Internetu).

pQd
źródło
+1 Brzmi dla mnie bardziej prawdopodobne wyjaśnienie
Kyle Brandt
2

Możliwe, że przechodzi przez czyjąś sieć wewnętrzną, przez MPLS lub coś podobnego, gdzie korzysta z wewnętrznych adresów IP.

Cian
źródło
2

Zgadzam się z Cianem. Czasami te przeskoki WAN mają prywatny adres zwrotny. Z jakiegoś powodu jest to zwracane w tracert. Program o nazwie Wireshark (naprawdę dobre oprogramowanie freeware) może dać ci lepszy wgląd w problem z siecią.

Manni

Manni
źródło