☰

Почему traceroute заканчивается дополнительным переходом после пункта назначения?

tag-icon • tag-icon traceroute
Почему 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).

Почему это произошло? Я никогда ничего подобного не видел.

Это связано с конфигурацией сервера?

решение1

tracerouteработает путем отправки UDP или ICMP Echo пакетов с последовательно увеличивающимися полями времени жизни (TTL). TTL уменьшается на 1 каждым маршрутизатором, который обрабатывает пакет.

Он ожидает два типа ответов на свои зонды.

  • Если TTL достигает 0, когда маршрутизатор его уменьшает, он отвечает сообщением ICMP Time-Exceeded и не пересылает пакет.
  • Конечный пункт назначения отвечает сообщением ICMP Port-Unreachable (в случае UDP) или сообщением ICMP Echo-Response (в случае ICMP).

Когда он получает второй тип, он знает, что достиг места назначения, и прекращает отправлять зонды с более высокими TTL. Обратите внимание, что онне делаетпринимайте это решение на основе адреса, с которого пришел ответ: если с целевого адреса получено сообщение Time-Exceeded, то время будет увеличиваться.

Итак, ваш след показывает, что маршрутизатор ответил Time-Exceeded и целевым адресом в качестве источника. Это, вероятно, означает, что это маршрутизатор, выполняющий NAT, а целевой адрес — это публичный адрес, соответствующий частному адресу за ним.

Но что странно, так это то, что окончательный ответ пришел отдругойадрес. Обычно вы ожидаете, что ответ вернется через маршрутизатор, поэтому его частный IP будет преобразован обратно в публичный IP. В этом случае вы увидите две строки с 10.1.1.10 в качестве адреса.

По-видимому, в этом случае путь от 10.1.1.9 до исходной машины не должен проходить через маршрутизатор NAT, поэтому его адрес не транслируется. Асимметричная маршрутизация часто может давать аномальные tracerouteрезультаты. В этом случае все ваши машины находятся в частном адресном пространстве 10.0.0.0/8, поэтому неудивительно, что существуют прямые пути.

решение2

Не зная конфигурации маршрутизатора, невозможно быть уверенным, однако, вероятной причиной является 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 DNATed где-то еще, и последний является адресом ответа по умолчанию. Это объяснило бы большое увеличение RTT.

решение3

Обратите внимание на время. Traceroute отправляет пакеты, которые просят коммутаторы или маршрутизаторы ответить источнику ответом "I am processing". Но эти пакеты могут попасть в пункт назначения, в данном примере на вашу машину, в различном порядке, в зависимости от конфигураций TTL и времени отклика, в зависимости от конфигурации устройств между ними, таблиц маршрутизации и топологии сети.

Связанный контент