Пакеты эхо-ответа ICMP с намного более низким TTL (-190), чем пакеты с превышением времени ICMP
Когда я пингую последние три прыжка пути traceroute к facebook.com из моего местоположения, все пакеты эхо-ответа ICMP, которые я получаю, все имеют TTL соответственно 58, 57 и 56. Хмель, о котором идет речь, - это 6-й, 7-й и 8-й прыжки с моей машины.
С другой стороны, значения TTL для сообщений ICMP с превышением времени для пакетов, срок действия которых истекает в этих трех переходах, имеют все разумные значения: 246, 248, 249.
Теперь обратный путь может не совпадать с прямым путем, и он может не совпадать с сообщениями ICMP разных типов.
Но откуда такая разница? 200-хмельный цикл по пути? Или пакеты эхо-ответа ICMP, генерируемые с низким TTL (намного ниже, чем 255: это вообще случается?)?
1 ответ
Как предлагает пользователь kwaio, значение TTL по умолчанию (или общее), используемое при генерации пакетов эхо-запроса ICMP и эхо-ответа, равно 64,
В моем случае первые маршрутизаторы по моему выбранному пути ответили сообщением эхо-ответа с TTL=255 (у источника), а последние с TTL=64.
Вместо этого представляется, что сообщения с превышением времени ICMP были созданы во всех случаях с TTL 255.
После некоторых поисков я обнаружил, что разные производители и разные ОС используют разные начальные TTL для разных протоколов: binbert.com/blog/2009/12/default-time-to-live-ttl-values
Интересным следствием этого является то, что вы можете идентифицировать манипулятор данного маршрутизатора, предоставив ему срок действия пакета и отправив ему эхо-запрос. Более подробная информация здесь: Отпечатки пальцев на основе TTL и MPLS и полная статья: "Отпечатки пальцев на сети: подписи маршрутизаторов на основе TTL".