Я один раз запустил следующую трассировку, пытаясь определить сетевую проблему.
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.
Первые три сайта - это локальные маршрутизаторы / шлюзы; игнорировать их.
Я не уверен, однако, как шаг 10 может дать мне 10.50.1.1 в качестве цели? Разве это не немаршрутизируемый IP-адрес, который нигде не должен быть найден на общедоступном маршрутизаторе?
Адреса RFC1918 (10/8, 172.16 / 12 и 192.168 / 16) не должны появляться в глобальных таблицах маршрутизации, поскольку они предназначены для использования в рамках «одного предприятия». Тем не менее, в некоторой степени имеет смысл использовать адреса RFC1918 для ваших двухточечных ссылок в вашем ядре, даже если трафик, проходящий по этим ссылкам, предназначен для диапазонов IP-адресов с глобальной маршрутизацией, поскольку это сохраняет немного ограниченный ресурс. .
Причина, по которой он отображается в traceroute, заключается в том, что срок действия TTL IP-кадра истек на интерфейсе с этим IP-адресом. Обратной стороной этого является то, что становится сложнее проверить связь с интерфейсом и устранить неполадки, связанные с проблемой, но нет гарантии, что вы все равно сможете это сделать.
Итак, я бы сказал, что это может быть немного необычно, но, конечно, не является чем-то необычным.
Мне это кажется странным. Совершенно нормально видеть частные IP-адреса в середине маршрута, потому что одна организация может использовать частный IP-адрес в своей сети. Но согласно whois, 212.143.14.154 и 195.66.225.105 принадлежат двум разным организациям. Но, возможно, у этих двух организаций есть точка, чтобы указать друг на друга, и в этом случае они могут использовать для этого частный IP.
Термин «немаршрутизируемые» не совсем точен, потому что они могут быть маршрутизированы. Однако термин должен использоваться только одним «предприятием». RFC1918 использует. Вот почему я нахожу это немного странным.
Я видел это на некоторых роутерах Juniper. Им были назначены правильные общедоступные IP-адреса, но маршрутизатор отправлял ответы icmp с частным IP-адресом, который был привязан к интерфейсу управления (недоступен из общедоступного Интернета).
Возможно, он проходит через чью-то внутреннюю сеть, через MPLS или что-то подобное, где они используют внутренние IP-адреса.
Я согласен с Цианом. Иногда эти переходы WAN имеют частный IP-адрес обратной петли. По какой-то причине это возвращается в tracert. Программа под названием Wireshark (действительно хорошая бесплатная программа) может дать вам больше информации о вашей сетевой проблеме.
Манни