Трассировка на прыжке дает тайм-аут

Question

Я просто смотрел на traceroute и пытался понять его поведение. Теоретически я понимаю, как работает IP-маршрутизация и traceroute, но этот случай сбивает меня с толку.

traceroute to google.com.ar (172.217.162.3), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  1.935 ms  1.367 ms  1.271 ms
 2  10.38.0.1 (10.38.0.1)  9.717 ms  11.107 ms  13.901 ms
 3  10.242.3.165 (10.242.3.165)  10.858 ms  11.663 ms  10.366 ms
 4  cpe-200-115-194-173.telecentro-reversos.com.ar (200.115.194.173)  12.070 ms  11.944 ms  11.704 ms
 5  cpe-200-115-194-174.telecentro-reversos.com.ar (200.115.194.174)  11.402 ms  12.110 ms  11.167 ms
 6  74.125.242.209 (74.125.242.209)  13.539 ms  13.080 ms  11.767 ms
 7  216.239.58.217 (216.239.58.217)  10.603 ms  11.635 ms  10.811 ms
 8  eze04s07-in-f3.1e100.net (172.217.162.3)  11.510 ms  11.575 ms  10.955 ms

Там есть частный IP, 10.38.0.1, я попытался отследить и / или пропинговать его. Если мой маршрутизатор разрешает этот переход при разрешении 172.217.162.3, он должен разрешить сам переход как пункт назначения

traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 52 byte packets
1  192.168.0.1 (192.168.0.1)  1.777 ms  1.481 ms  2.287 ms
2  * * *
3  * * *

Ничего такого

Давайте попробуем с traceroute -I, как указано здесь:

Почему traceroute не работает?

traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 72 byte packets
 1  192.168.0.1 (192.168.0.1)  1.686 ms  1.218 ms  1.145 ms
 2  * * *
 3  * * *

Ни ...

В чем дело?

traceroute -v
Version 1.4a12+Darwin

Подключение: LAN подключен к WAN с использованием широкополосного маршрутизатора Cisco DPC3925.

Answer 1

Там есть частный IP, 10.38.0.1, я попытался отследить и / или пропинговать его. Если мой маршрутизатор разрешает этот переход при разрешении 172.217.162.3, он должен разрешить сам переход как пункт назначения

Нет. Прежде всего, traceroute на самом деле не показывает, какой скачок пытался разрешить предыдущий маршрутизатор; он показывает адрес, с которым идентифицируется этот переход , который не всегда является одним и тем же адресом. (Обратите внимание, что перенаправленные IP-пакеты всегда имеют исходный IP-адрес назначения, а не каждый переход).

Каждый переход идентифицирует себя, отправляя ICMP-пакет "TTL превышен", и ему нужно выбрать соответствующий адрес источника для него. Он также будет иметь несколько адресов на разных интерфейсах, включая различные интерфейсы с выходом в Интернет, а также сети управления, и может использовать различные алгоритмы выбора адресов, например, что-то простое, например "использовать самый низкий адрес численно".

Короче говоря, это может быть адрес, по которому у предыдущего перехода нет маршрута.

Вторая проблема (даже если есть полные маршруты в направлении этого адреса) является то , что , как ping и traceroute определить окончательный хмель на добровольной основе отправленного ответа. На устройстве могут быть просто отключены ответы ping (ICMP echo). Или он может иметь брандмауэр, который отбрасывает ваши зонды ping/traceroute без отправки какого-либо ответа. (Адрес, который вы пытаетесь получить, выглядит как то, что интернет-провайдер использовал бы внутри для сети управления, поэтому весьма вероятно, что его брандмауэр принимает пакеты только от собственного NOC интернет-провайдера и больше нигде.)