Я читав аркуш iptables (легке читання перед сном) і натрапив на ціль "TTL", але він попереджає:
Встановлення або збільшення поля TTL може бути дуже небезпечним
і
Ніколи не встановлюйте та не збільшуйте значення для пакетів, які залишають вашу локальну мережу!
Я бачу, як можливо декрементування або встановлення нижнього рівня TTL може призвести до відмови пакетів до досягнення пункту призначення, але який ефект може мати збільшення?
Відповіді:
TTL зменшується, коли він проходить через маршрутизатор. Це гарантує, що якщо пакет буде подорожувати по колах, він з часом загине.
Поле TTL пакету IP v4 - це 8-бітове поле (255 десятків). Тому встановити його на початку - це не велика справа, оскільки насправді він не може бути таким великим у добре сформованому пакеті (Хоча деякі речі можуть приймати неправильно сформовані IP-пакети).
Однак якщо щось збільшує його, а крок збільшення є частиною циклу , пакет може продовжувати йти по колах, не доходячи до нуля. З часом (це може бути дуже коротким або поступовим витоком) пакети можуть накопичуватися в системі, що містить цю петлю, викликаючи її перевантаження.
В основному TTL для пакетів зберігає маршрутизацію здорово. Якщо пакет повинен був мати дуже великий TTL і з якихось причин потрапив у круговий маршрут, це може спричинити тонну трафіку (звану "пакетна буря") і заважати нормальним операціям. Занадто низький TTL може призвести до втрати зв'язку, оскільки ви втратите пакет ще до того, як він дійшов до пункту призначення.
Є один момент, який, здається, відповіді пропустив, але який був би суто академічним (через те, скільки хмелю, здається, потрібно в Інтернеті): якщо пакет зазвичай не зможе досягти свого призначення через закінчення терміну TTL, то збільшуючи його дозволить пакету дістатись до свого пункту призначення, але не вплине на повернення пакетів, і вони закінчуються, перш ніж дістатися до вашої мережі.
ОНОВЛЕННЯ: Відповідно до цієї сторінки у Вікіпедії :
Теоретично, під IPv4 час життя вимірюється в секундах, хоча кожен хост, який передає дейтаграму, повинен зменшити рівень TTL щонайменше на одну одиницю. На практиці поле TTL зменшується по одному на кожен скачок. Щоб відобразити цю практику, поле перейменовано в межу переходу в IPv6.
ОНОВЛЕННЯ 2: Оскільки хтось оновлював мій пост і посилався на Вікіпедію, я вважав, що найкраще посилатися на сам RFC - http://www.ietf.org/rfc/rfc791.txt - Просто шукайте TTL там, і це досить добре пояснити це:
Це поле вказує максимальний час, коли дейтаграмі дозволяється залишатися в системі Інтернет ... кожен модуль, який обробляє дейтаграму, повинен знизити TTL хоча б на один, навіть якщо він обробляє дейтаграму менше ніж за секунду
Я знаю лише одну програму, яка могла б використовувати більше значення TTL, і це traceroute. Як видно з назви, він відстежує маршрут до цільового вузла, змінюючи значення TTL. Стандартний максимальний хміль - 20, але ви можете це збільшити.
Кожен маршрутизатор, який обробляє пакет, зменшує значення TTL, поки пакет не досягне свого призначення, або TTL не досягне нуля, і не помре.
Як говорили інші, збільшення TTL може призвести до отримання пакетів, які ніколи не вмирають, якщо буде негативний цикл. Як правило, якщо значення TTL недостатньо велике, логіка спробувати більшу TTL, ймовірно, повинна оброблятися кінцевими клієнтами.
Якщо ви впевнені, що маршрутизатор не знаходиться в циклі (деревоподібна топологія), теоретично ви могли б безпечно збільшити значення TTL. Сказавши, що, якщо дозволити більше стрибків, ніж це є стандартним, це може зробити затори більш імовірними у зовнішній мережі. Якщо у вас довгий ланцюг маршрутизаторів між внутрішньою та зовнішньою мережею, доки циклу немає, велике значення TTL може допомогти. Сказавши це, хтось може бути досить простим, щоб додати край до мережі та створити цикл, тому починати з більшого значення TTL, де пакет, що виник у першу чергу, набагато безпечніше.