Почему traceroute завершился с дополнительным переходом после пункта назначения?
Если ничто не блокирует трафик, 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 достигает 0, когда маршрутизатор уменьшает его, он отвечает сообщением ICMP о превышении времени и не делает этого. Не пересылаю пакет.
- Конечный пункт назначения отвечает сообщением ICMP о недоступности порта (в случае UDP) или сообщением эхо-ответа ICMP (в случае ICMP).
Когда он получает второй тип, он знает, что достиг места назначения, и перестает отправлять зонды с более высокими значениями TTL. Обратите внимание, что он не основывает свое решение на адресе, с которого приходит ответ - если он получает сообщение об истечении времени с целевого адреса, оно будет продолжать увеличиваться.
Итак, ваша трассировка указывает на что маршрутизатор ответил с превышением времени и целевым адресом в качестве источника. Это, вероятно, означает, что это маршрутизатор, выполняющий NAT, а целевой адрес является публичным адресом, соответствующим частному адресу за ним.
Что странно, так это то, что окончательный ответ пришел с другого адреса . Обычно вы ожидаете, что ответ вернется через маршрутизатор, поэтому его частный IP-адрес будет преобразован обратно в общедоступный IP-адрес. В этом случае вы увидите две строки с адресом 10.1.1.10.
Очевидно, в этом случае путь от 10.1.1.9 к исходной машине не должен проходить через маршрутизатор NAT, поэтому его адрес не получить перевод. Асимметричная маршрутизация часто может давать аномальные результаты traceroute . В этом случае все ваши машины находятся в частном адресном пространстве 10.0.0.0/8, поэтому нет ничего удивительного в том, что доступны прямые пути.
Обратите внимание на время. Traceroute отправляет пакеты, которые просят коммутаторы или маршрутизаторы ответить источнику с ответом «Я обрабатываю». Но эти пакеты могут принимать место назначения, ваш компьютер в этом примере, в различном порядке, в зависимости от TTL и конфигураций времени ответа, в зависимости как от конфигурации устройств между ними, таблиц маршрутизации и топологии сети.
Невозможно быть уверенным, не зная конфигурации маршрутизатора, однако вероятной причиной является NAT назначения, также известный как обратный NAT, или переадресация портов, или - в данном случае, скорее, - открытый хост.
Маршрутизатор 10.1.1.10 может быть настроен для пересылки / DNAT всего на хост 10.1.1.9 (= открытый хост), включая запросы с частных IP-адресов. С общедоступного IP-адреса вы увидите двойной последний переход, потому что фактический пункт назначения 10.1.1.9 скрыт маршрутизатором NAT. В этом случае возможно, что DNATed только для запроса, а ответ просто пересылается как есть.
Также возможно, что 10.1.1.10 и 10.1.1.9 имеют DNAT-адрес в другом месте, и последний является адресом ответа по умолчанию. Это могло бы объяснить значительное увеличение RTT.