Если ничто не блокирует трафик, traceroute обычно заканчивается IP-адресом назначения в качестве последнего перехода. (10.1.1.10 в данном случае)
Нормальный traceroute было бы так.
user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
1 10.2.8.2 (10.2.8.2) 0.572 ms 0.692 ms 0.837 ms
2 10.1.9.50 (10.1.9.50) 202.638 ms 10.1.9.78 (10.1.9.78) 202.547 ms 10.1.9.50 (10.1.9.50) 202.139 ms
3 10.1.4.9 (10.1.4.9) 202.508 ms 202.483 ms 10.1.4.13 (10.1.4.13) 204.149 ms
4 10.1.1.10 (10.1.1.10) 202.133 ms 202.100 ms 202.692 ms
user@linux:~$
Недавно я столкнулся с проблемой, связанной с дополнительным переходом (10.1.1.9) в traceroute вывод (см. переход 5).
Исходный IP-адрес: 10.2.8.8
user@linux:~$ ifconfig | head -2
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.2.8.8 netmask 255.255.255.0 broadcast 10.2.8.255
user@linux:~$
IP-адрес назначения: 10.1.1.10
Дополнительный хоп: 10.1.1.9 ???
user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
1 10.2.8.2 (10.2.8.2) 0.572 ms 0.692 ms 0.837 ms
2 10.1.9.50 (10.1.9.50) 202.638 ms 10.1.9.78 (10.1.9.78) 202.547 ms 10.1.9.50 (10.1.9.50) 202.139 ms
3 10.1.4.9 (10.1.4.9) 202.508 ms 202.483 ms 10.1.4.13 (10.1.4.13) 204.149 ms
4 10.1.1.10 (10.1.1.10) 202.133 ms 202.100 ms 202.692 ms
5 10.1.1.9 (10.1.1.9) 6201.720 ms !H * *
user@linux:~$
Кроме того, если вы посмотрите на переходы 2 и 3, есть дополнительные IP-адреса (10.1.9.78 и 10.1.9.50)
Почему это случилось? Я никогда раньше не видел ничего подобного.
Было ли это из-за конфигурации сервера?
traceroute работает, отправляя эхо-пакеты UDP или ICMP с последовательно увеличивающимися полями времени жизни (TTL). TTL уменьшается на 1 каждым маршрутизатором, обрабатывающим пакет.
Он ожидает двух типов ответов на свои зонды.
Когда он получает второй тип, он знает, что достиг пункта назначения, и прекращает отправку зондов с более высоким TTL. Обратите внимание, что это не Основывайте это решение на адресе, с которого приходит ответ - если он получает сообщение Time-Exceeded с целевого адреса, он будет продолжать увеличиваться.
Таким образом, ваша трассировка указывает, что маршрутизатор ответил с превышением времени и целевым адресом в качестве источника. Это, вероятно, означает, что это маршрутизатор, выполняющий NAT, а целевой адрес является публичным адресом, соответствующим частному адресу за ним.
Что странно, так это то, что окончательный ответ пришел от разные адрес. Обычно вы ожидаете, что ответ вернется через маршрутизатор, поэтому его частный IP-адрес будет преобразован обратно в общедоступный IP-адрес. В этом случае вы увидите две строки с адресом 10.1.1.10.
Очевидно, в этом случае путь от 10.1.1.9 к исходной машине не должен проходить через маршрутизатор NAT, поэтому его адрес не переводится. Асимметричная маршрутизация часто может приводить к аномальным traceroute полученные результаты. В этом случае все ваши машины находятся в частном адресном пространстве 10.0.0.0/8, поэтому неудивительно, что доступны прямые пути.
Не зная конфигурации маршрутизатора, невозможно быть уверенным, однако вероятной причиной является NAT назначения, также известный как обратный NAT или переадресация портов, или - в данном случае, скорее, - открытый хост.
Маршрутизатор 10.1.1.10 может быть настроен для пересылки / DNAT все к хосту 10.1.1.9 (= открытый хост), включая запросы с частных IP-адресов. С общедоступного IP-адреса вы увидите двойной последний переход, потому что фактический пункт назначения 10.1.1.9 скрыт маршрутизатором NAT. В этом случае возможно, что DNAT обрабатывается только для запроса, а ответ просто пересылается как есть.
Также возможно, что 10.1.1.10 и 10.1.1.9 имеют DNAT в другом месте, и последний является адресом ответа по умолчанию. Это объясняет значительное увеличение RTT.
Обратите внимание на времена. Traceroute отправляет пакеты, которые просят коммутаторы или маршрутизаторы ответить источнику с ответом «Я обрабатываю». Но эти пакеты могут принимать свое место назначения, ваш компьютер в этом примере, в различном порядке, в зависимости от TTL и конфигураций времени ответа, в зависимости от конфигурации устройств между ними, таблиц маршрутизации и топологии сети.