Назад | Перейти на главную страницу

Traceroute включает немаршрутизируемый IP (?)

Я один раз запустил следующую трассировку, пытаясь определить сетевую проблему.

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 (действительно хорошая бесплатная программа) может дать вам больше информации о вашей сетевой проблеме.

Манни