Уменьшать ttl при маршрутизации: Что такое TTL – как обойти ограничение на раздачу интернета? [2020]

Что такое TTL – как обойти ограничение на раздачу интернета? [2020]

Содержание

• 1 Расширить значение ttl asus — что это такое?
• 2 Что такое ttl?
• 3 Зачем нужны эти настройки?
• 4 Как изменить ttl в windows 10?
• 5 Как проверить ttl на компьютере?
• 6 Заключение
  • 6.1 Узнайте больше о Huawei

Расширить значение ttl asus — что это такое?

На роутерах Asus, Zyxel и других фирм вы можете встретить две настройки:

1. Расширить значение TTL (Extend The TTL Value) — опция на роутере, работающая на входящий трафик, если от провайдера пришел пакет с TTL равным 1, то он не будет обнулен. В результате все ваши внутренние устройства смогут его получить.
2. Подменить значение LAN TTL — нужна для отправки пакетов с фиксированным TTL, вне зависимости от того сколько узлов в локальной сети, TTL все равно будет одинаковый и провайдер вас не заблокирует.

Что такое ttl?

TTL – это показатель, который имеет каждое устройство, обладающее способностью выходить в интернет. TTL- аббревиатура, дословно обозначающая Time To Live, что переводится, как время жизни. В данном случае речь идет о времени жизни IP-пакета – сформированного набора данных, в форме которого информация передается от центрального сервера пользователю и обратно.

Речь идет о времени, которое пакет может просуществовать без повреждений и потерь информации при передаче от одного узла связи к другому. Изначально предполагалось измерять длительность такой «жизни» в секундах, отсюда и аббревиатура.

Существование данного параметра необходимо для того, чтобы любой, переданный в любом направлении, IP-пакет не мог курсировать по сети бесконечное количество времени.

Принцип действия данной настройки состоит в следующем: каждый последующий маршрутизатор (либо узел сети) уменьшает время жизни пакета на единицу, так как расчет в секундах устарел. Некоторые узлы связи можно настроить таким образом, что при маршрутизации пака уменьшения TTL на единицу именно на данном узле происходить не будет, что продляет фактическое время целостности пака. Но сделать такое можно не со всеми узлами маршрута.

TTL: что это такое в телефоне, компьютере и какое непосредственно влияние оказывает на работу устройства и стабильность соединения? Когда пакет слишком долго перенаправляется от узла к узлу, в итоге его TTL становится равно нулю, и он уничтожается. Пользователь в этот момент получает уведомление «Время ожидания ответа от сервера истекло» или т. п.

То есть, при медленном интернет-соединении, чрезмерно удаленном сервере и т. п. сайт на вашем устройстве может не загружаться как раз потому, что его TTL слишком мало, чтобы его хватило для передачи конкретному очень удаленному пользователю (вам).

Фактически чем больше TTL пакетов, тем выше вероятность, что даже очень физически удаленный от итогового пользователя сервер сможет передать информацию в полном объеме.

Правильно настраивать и изменять TTL можно в большую сторону, при таком изменении сайты станут подгружаться лучше. Возможно также настроить свой роутер таким образом, чтобы прохождение через него не уменьшало на единицу длительность существования пакета. Для выполнения таких изменений и настроек используются специальные утилиты для работы с сетевым оборудованием.

Показатель имеет ряд ограничений, связанных с современными техническими возможностями сети. Максимальное значение TTL составляет 255, тогда как базовое среднее, характерное для большинства современных устройств связи – 64 TTL. Оно является базовым начальным значением, которое используют Linux, Mac, iOS, Android, и которое подлежит, при необходимости, изменению.

А вот у Windows стартовый показатель выше, составляет 128, что обеспечивает более стабильную связь.

Обратите внимание, что понятие TTL применимо только к протоколам IPv4, тогда как в протоколе IPv6, оно уже переименовано в Hop Limit – максимальное число хопов, то есть преодолеваемых отрезков от узла к узлу, тех самых единиц, о которых идет речь выше.

Все узлы сети уменьшают TTL. Исключение составляют только коммутаторы, которые неспособны как-либо на него повлиять, так как работают в канальном режиме.

Зачем нужны эти настройки?

Обе эти опции предназначены для упрощения работы при использовании мобильного интернета, когда есть ограничение на количество подключенных устройств.

Оказывается что мобильный оператор может ограничивать раздачу интернета, то есть когда вы купили модем и подключили его к роутеру чтобы он раздавал интернет например по Wi-Fi (или в модеме присутствует такая функция изначально).. и вот оператору это не нравится.

Он хочет чтобы его интернетом пользовался только один человек (экономически логично). Провайдер может анализировать TTL для определения есть роутер у пользователя или нет, и если есть, то интернет может блокироваться. Но вот вышерассмотренные опции могут помешать ему это сделать.

Но вообще редко когда провайдер страдает такой ерундой, но случаи бывали.

Как изменить ttl в windows 10?

Возможно способ будет работать и для Windows 7.

1. Открываем реестр, для этого можно зажать Win R, указать команду regedit.
2. Переходим по такому пути: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
3. Теперь в этой папке нужно создать параметр DefaultTTL — нажимаем правой кнопкой справа по белому пространству и выбираем Создать > DWORD (32-bit), даем название DefaultTTL. Потом нажимаем два раза по созданному параметру и указываем.. например 64 (там где Система исчисления там выбираем Десятичная). Указать можно и другое значение, смотря какую задачу вы хотите решить.
4. Точно такой же параметр нужно создать и в этом разделе: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesTCPIP6
5. После создания параметра нужно перезагрузить ПК.

Создание параметра в реестре. Он там уже может быть, в таком случае тогда просто измените значение.

Как проверить ttl на компьютере?

На самом деле очень просто:

1. Откройте командную строку. В Windows 10 можно просто зажать Win X (либо просто нажать правой кнопкой по пуску) и выбрать командную строку от администратора. Можно еще зажать Win R и написать cmd, потом нажать ОК.
2. Теперь указываем команду ping 127.0.0.1 — в ответе команды вы увидите значение TTL.

Команда простая и просто проверяет связь с ПК с самим собой, потому что 127.0.0.1 — это локальный адрес самого компа, это не интернет и не локальна сеть.

Заключение

1. Расширить значение TTL Asus — настройка которая не будет обнулять TTL пакета, если он равен 1. Это позволит пакету продолжить путь через роутер и попасть на нужное устройство.
2. Данная опция как и Подменить значение LAN TTL (установка фиксированного TTL) может помочь обойти запрет провайдера на раздачу интернета другим устройствам. Обычно такое бывает у мобильных операторов, когда вы оплачиваете интернет для смартфона и хотите раздать его по Wi-Fi (например просто вставив симку в модем, который умеет раздавать интернет по Wi-Fi).
3. По умолчанию данная опция отключена. Включать нужно при необходимости, хотя с другой стороны в теории включение не должно нарушить работу интернета.

Удачи.

Циклы маршрутизации / Хабр

Привет Хабр. Это транскрипция выступления облачного архитектора Qrator Labs, Александра Зубкова, про циклы маршрутизации. Русская версия данного доклада была впервые представлена на конференции ENOG 18 в июне этого года.

Добрый день! Меня зовут Александр Зубков, я работаю в Qrator Labs и сегодня я хочу поговорить о циклах маршрутизации.

Собственно, цикл маршрутизации это такая ситуация в Интернете, когда пакет, потенциально, бесконечно маршрутизируется по кругу. “Потенциально” потому что у нас есть защита от этого в IP-протоколе в форме TTL-поля, но даже при условии этого, если пакет с большим TTL’ем попадает в цикл — он может находится в нём достаточно долго, потому что максимальный TTL равен 255. И также возможны ситуации когда в пути TTL меняется и это может привести к реальным бесконечным циклам. Чтобы обнаружить цикл маршрутизации мы можем воспользоваться вот таким механизмом и если мы получаем на какой-то пакет ICMP ошибку о том что TTL иссяк, то это скорее всего одна из двух ситуаций: либо это длинный путь для которого нам не хватило TTL, либо это цикл маршрутизации в который попал пакет.

В Linux’е значение TTL по умолчанию равно 64, мы можем считать что этого хватает для Интернета и если у нас для довольно большого TTL вернулась ошибка, то мы можем считать что это почти гарантированно цикл, только если кто-то нас не обманывает специально.

Помимо того что таким образом мы можем обнаружить цикл, мы можем еще захотеть посмотреть на него — для этого можно воспользоваться утилитами вроде traceroute и mtr, знаете наверняка такие утилиты для того чтобы смотреть в Интернете красивые картинки.

Например, на ёлочку.

Или вот, ещё есть Звёздные Войны.

Или стихи про плохую лошадь.

К сожалению все остальные вы уже не посмотрите — это картинки из архивов. Плохая лошадь ещё осталась, но плохо работает и приходится ждать, пока стишок появится.

Естественно, можно наблюдать и цикл маршрутизации. В данном случае пакет сначала шёл нормально по цепочке маршрутизаторов, а потом в какой-то момент зациклился между двумя маршрутизаторами, один из которых не отвечает ошибками, а второй отвечает исправно. Видно, что пакет ходит между ними бесконечно. Кстати, данный конкретный пример это то, что сейчас можно увидеть вместо ёлочки показанной ранее. Так что ёлочка ушла, а хоровод остался.

Как можно получить цикл маршрутизации в Интернете? Один из вариантов — в результате работы протоколов динамической маршрутизации. Конечно, в них есть защита от циклов, но пока они сходятся существуют моменты в которые могут возникать циклы, пока состояние маршрутов в таблицах маршрутизаторов не согласовано. На примере BGP в Интернете, который может сходится несколько минут, мы можем довольно часто наблюдать циклы при изменении каких-то анонсов. Но такие циклы они кратковременные и обычно нас сильно не беспокоят.

Кроме этого, протоколы маршрутизации пишутся людьми, софт не идеальный и мы можем наблюдать такие случаи, когда у нас какие-то BGP-сессии залипают и это приводит к залипшим маршрутам, которые остаются в таблицах и никуда не деваются. То есть, таким образом тоже можно получить несогласованное состояние маршрутов и разные проблемы, в том числе циклы.

Также, проблема защиты от циклов в данных протоколах, она обычно делается для конкретного префикса, но если у нас есть пересекающиеся префиксы с разной маской, в результате агрегации, неполных таблиц маршрутизации и каких-то других вещей, таким образом мы тоже можем получить несогласованные маршруты, которые могут в том числе привести к циклам.

Эта конкретная проблема скорее относится ко второму классу циклов, которые я назвал “ошибки конфигурации”. И я считаю, что это наиболее популярный вариант, когда у нас есть какие-то неиспользуемые адреса или NAT-пулы используются, которые не терминируются нигде.  

Простейший пример: провайдер маршрутизирует какой-то префикс в клиента, клиент использует только часть этих адресов и у него маршруты есть только на них, а на остальные адреса у него маршрутов нет и, соответственно, он по умолчанию эти маршруты маршрутизирует обратно в провайдера и таким образом возникает цикл.

Подобные циклы уже долговременные и до тех пор пока ошибка не будет устранена они будут приводить к проблемам.

Конкретно такую ошибку можно легко исправить на стороне клиента, если мы все адреса которые получаем от провайдера null-route’им. Таким образом этот маршрут у нас будет служить своеобразным fallback’ом. Причем такое делать лучше всегда, даже если вы используете все эти адреса. К примеру, есть оборудование, которое если у вас физический линк падает и это единственный линк относящийся к VLAN’у, то vlan тоже будет в состоянии down. Таким образом маршрут пропадет и вы получите цикл на этот промежуток времени, пока линк не восстановится. Поэтому лучше такой route добавить, с какой-нибудь большой метрикой в качестве fallback’а.

И на стороне провайдера, также, в некоторых случаях, если вы можете к клиенту применить политику антиспуфинга, например это одноногий (стаб-сеть) клиент, то такое лучше сделать в любом случае. И в данном случае это поможет вам разорвать цикл маршрутизации, потому что пакет который вернется от клиента уже будет с source’ом не из его сети, скорее всего.

Какие проблемы могут быть от циклов маршрутизации?

Самая очевидная проблема — это повышенная загрузка канала. Например, если у нас есть цикл длиной 2 и туда прилетает TTL 200, то он сто раз по этому циклу пройдет и мы получим стократное увеличение трафика на этом цикле. И такой цикл может быть целью атаки на отказ в обслуживании. Или если, например, это цикл между вами и вашим провайдером, то он может посчитать этот трафик и вы просто заплатите за него.

Есть менее очевидные проблемы. Например, циклы маршрутизации в совокупности с другими проблемами могут приводить к амплификации, которая посылает ответы на тот адрес с которого пришел пакет и такие циклы могут быть использованы как средство DDoS-атак на других лиц. И есть еще какие-то экзотические вещи, например в одной статье описывается возможность по циклам маршрутизации определять возможности спуфинга в вашей сети.

Я нашел несколько, как мне показалось, интересных статей по проблематике циклов. Первая статья (https://www.usenix.org/legacy/event/imc05/tech/full_papers/xia/xia_html/imc05-paper-128-final.html) как раз описывает возможность загрузки канала малым трафиком при наличии цикла. Второй материал (https://www.usenix.org/system/files/sec21fall-bock.pdf) не совсем про циклы — товарищи пытались использовать миддлбоксы, это обычно коробки, которые осуществляют какую-то фильтрацию или сбрасывают TCP-соединение, то есть отвечают на проходящие мимо пакеты, для организации отраженных атак. И такие коробки в сочетании с циклами в состоянии давать амплификацию, потому что пакет проходит несколько раз мимо такой коробки и она каждый раз что-то посылает в ответ. И в некоторых случаях они наткнулись в том числе на бесконечные циклы, то есть они описывают, что в одном случае они получали ответный трафик в течение шести дней после того как прекратили от себя посылать трафик, они предположили что пакет просто дропнулся и трафик перестал приходить.

И еще есть статья (https://mkorczynski.com/PAM17Lone.pdf) об обнаружении возможности спуфинга сети в случае наличия циклов. Дальше, довольно интересная статья вышедшая недавно (https://blog.benjojo.co.uk/post/bgp-stuck-routes-tcp-zero-window), в которой описывается механизм как BGP-сессия может залипнуть таким образом, что keep alive проверки не обнаружат этого и таким образом данная сессия может долго просуществовать в залипшем состоянии, с залипшими маршрутами. И в последней статье (https://toonk.io/the-risks-and-dangers-of-amplified-routing-loops/index.html) предлагается использовать совокупность обычной амплификации с циклом, то есть направлять трафик с амплификации в цикл, таким образом достигать кумулятивного эффекта и совсем малым трафиком осуществлять загрузку вашего канала.

Собственно, после этой статьи, комментарии к которой я читал и где был некоторый скепсис насчет того насколько реально использовать с этой целью циклы, я решил сделать этот доклад.

В том числе я вспомнил пример из собственной практики, больше четырех лет назад, с моим домашним провайдером. Я обнаружил цикл в их сети и написал им об этом, привел traceroute где явно видно цикл. В ответ мне, естественно, написали “иди отсюда глупый пользователь, ты ничего не понимаешь, это у нас такой NAT-пул и у тебя внешний адрес не должен работать, а если бы это был цикл маршрутизации, то наш мониторинг его бы заметил”. Ну я предположил, что если у них есть такой мониторинг, то он, наверное, сломан, раз он цикл не заметил — они мне ничего не ответили, я следом написал по контактам из RIPE, на что мне ответили достаточно интересную вещь, мол “техподдержка правильно написала, потому что это не цикл по определению (с их точки зрения), адреса из NAT-пула просто нигде не сконфигурированы, поэтому они отправляются по умолчанию. Это можно исправить, но проблема косметическая и не стоит усилий”.

Это 4 года назад было, цикл всё ещё там — я проверил перед докладом, ребят не сильно беспокоит.

Теория — теорией, я решил проверить на практике действительно ли циклы вызывают проблемы, так как это может быть не всем очевидно. Собрал некоторый сетап из двух свитчей и трёх серверов, между свитчами у меня был цикл. Линк между свитчами 40 гигабит, между серверами и свитчами по 10 гигабит. Один из серверов с nginx’ом, со второго сервера я подавал тестовую нагрузку, а с третьего запускал флуд.

Примерно такими командами тестил — утилитой ab, в сто потоков, 5 минут тестил запросы, и флуд hping’ом запускал с разным размером пакета, с разной скоростью и направлял в сервер напрямую, либо в цикл.

Здесь можно видеть полученный график загрузки каналов. Слева линейный график, справа логарифмическая шкала. Голубенькое это трафик флуда, а зелененькое это график загрузки канала между свитчами. С правой стороны, где я уже начал загружать канал в цикле, можно видеть что синенькое — где-то на два порядка меньше трафик и он вызывает полную загрузку канала в цикле, примерно в сто раз.

Можно посмотреть дальше — в табличке. Если я, к примеру, брал 450 мегабит флуда и направлял его в сервер напрямую, то это, естественно, не оказывало никакого значимого эффекта на работу сервера. А в случае с циклом это приводило к полной загрузке канала между свитчами и я получил замедление в 5 раз, чуть больше. В некотором смысле для меня было некоторым удивлением то, что когда я пытался загрузить цикл маленькими пакетами, то я обнаружил что это не оказывает влияния — там 30 гигабит, но маленькими пакетами это полностью загруженный канал. Скорее всего это связано с тем как в свитче реализована очередь между портами, она скорее всего какая-нибудь честная и наверняка выбирает пакеты по очереди. Так как пакеты в цикле и полезный трафик приходят с разных направлений, то проходит все без проблем.

Тем не менее, несмотря на это, в случае с большими пакетами, может быть заполняется буфер или что-то ещё, проблему удается воспроизвести. И в случае если у вас, к примеру, это будут не коммутаторы, а какие-нибудь честные маршрутизаторы или серверы, то там другие узкие места и вполне возможно что проблемы будут гораздо более существенные.

В Qrator Labs у нас есть проект Radar, где мы наблюдаем за разными проблемами в Интернете и коллеги мне предоставили историческую статистику по количеству наблюдаемых циклов в IPv4 сегменте. Я нанёс на график и видно что тренд нисходящий, что наверное хорошо, многообещающе. Надеюсь они не перемещаются постепенно в IPv6.

Кроме того я решил провести своё собственное исследование. Первый раз я просканировал все адреса в Интернете с помощью четырёх ICMP-проб с разными TTL’ами и когда я получал ошибку TTL exceeded, то я считал что наткнулся на цикл. Таких адресов я обнаружил более 28 миллионов — это больше 1% от всех активных адресов в Интернете.

Причём, это скорее всего нижняя оценка, потому что не все маршрутизаторы отвечают ошибками, также часто попадаешь в лимиты и возможны потери пакетов и так далее. Глядя на полученные результаты было видно, что есть соседние адреса с пробелами и когда я пытался посмотреть эти адреса, есть ли там цикл, то он там был — и он не попал в результат.

1% адресов это уже достаточно много, но если посмотреть на то, в каких автономных системах содержатся циклы, то мы получим ещё более страшную цифру в 25 000 автономных систем, содержащих такие адреса. Это больше трети всех автономных систем в интернете на момент исследования. Причем правило Парето сильно нарушается — двадцать самых крупных автономных систем по циклам, это меньше 0,1%, дают как минимум 17% циклов. Причем там можно встретить самые разные автономные системы, государственные учреждения, институты, хостеры, производители мобильных телефонов. И что самое неприятное с моей точки зрения — это наличие циклов в сетях операторов поставщиков услуг доступности, это операторы CDN и защиты от DDoS-атак.

Причем не только маленькие организации, но и крупные и широко известные компании.

На данном графике можно видеть топ-20 автономных систем с циклами. Видно, что существенными лидерами являются какая-то национальная Интернет сеть Индии, в которой почти 600 тысяч маршрутов с циклами, на втором месте Lumen, причем у Lumen на самом деле несколько автономных систем и из них две умудрились попасть в топ-20. Если их сложить, то в сумме получится даже больше 600 тысяч.

Как я уже упоминал, встречается такое явление, как амплификация. Причем, в моем случае я смотрел только на полученные ошибки (TTL exceeded), то есть это не та же самая ситуация, что описана товарищами с мидлбоксами. Даже только с ошибками встречается амплификация. Я посылал по 4 пробы — а в ответ я получил в среднем больше 4 ответов на один адрес, естественно из тех на которые я получил хоть какой-то ответ. В некоторых случаях у меня было больше ста тысяч ответов на одну пробу. Если посмотреть самый активный маршрутизатор, от которого я получал ответы, то он в ответе за более чем 6% полученных мною ответов, массивная доля. И он такой не один, просто самый активный, в результатах выделяется несколько очень активных маршрутизаторов.

Есть также разные варианты, иногда можно получить несколько ответов с одного адреса на одну пробу, можно получить несколько ответов с разных адресов на одну пробу. Иногда бывает ситуация, когда прилетает несколько ответов с пары адресов, после чего это заканчивается ответом ещё и с третьего адреса. И причем это повторяющийся паттерн, встречаются очень странные ситуации.

Я пытался посчитать еще и уникальные циклы, но с этим есть определенная проблема, потому что их нужно сопоставлять, из-за пропущенных ответов, из-за повторяющихся адресов. Какой-то маршрутизатор может повторяться несколько раз в одном цикле, то есть это не на разных витках цикла, а именно в одном цикле один адрес может повторяться несколько раз, в том числе подряд. Также, на одной и той же позиции цикла несколько маршрутизаторов могут отвечать, в том числе рандомно. Поэтому их трудно сопоставить, я попытался это сделать кое-как и даже если отбросить те циклы, которые мало раз повторяются, то все-равно остаются сотни тысяч циклов.

И если мы посмотрим какие маршрутизаторы отвечают, то более полумиллиона маршрутизаторов в этих циклах участвует, из 20 000 автономных систем.

Что касается характеристик циклов, то длина циклов которые я нашел — от одного до 34 хопов. И больше половины этих циклов составляют циклы длиной 2 хопа. По распределённости/распространённости циклов — можно найти циклы величиной до 7 автономных систем, или до 8 стран, естественно с поправкой на геолокацию, но примерно можно оценить. Если смотреть по времени, то самый длинный цикл который я видел занимал до 18 секунд, причем они были из одного хопа. Циклы из двух хопов — до 8 секунд. Такие циклы даже mtr’ом сложно посмотреть, потому что он больше 10 секунд не принимает ответы и не показывает — можно увидеть только первый виток цикла. Мне пришлось пользоваться tcpdump’ом, то есть я реально посылал ICMP-пробы с увеличивающимся TTL и с каждым увеличивающимся TTL я видел, что ответ начинает приходить на 18 секунд дольше. Где там блуждают пакеты все это время я даже не знаю.

Естественно, кроме этого было много трансконтинентальных циклов, с понятными временами вроде полсекунды, 300 миллисекунд.

Здесь я отобразил статистику по странам на карте мира и топ-10 стран. США абсолютный лидер, там содержится больше 6 миллионов циклов, у остальных уже существенно меньше. Из региона ENOG в десятку попала только РФ.

На этом слайде статистика по ENOG-региону, топ-10 стран. Россия естественно первая, дальше Украина с существенным отрывом, то же самое с Казахстаном, остальные уже идут группой.

Я еще посмотрел статистику по автономным системам — по операторам поискал у кого больше всех циклов содержится, после четырех мне надоело листать — там уже существенно меньше, но топ рейтинга выглядит вот так: Ростелеком, Киевстар, Kcell и Транстелеком. Это только ENOG-регион.

Далее, я хотел бы показать вам несколько обнаруженных мною вещей, как мне кажется, самых странных. Вот, например, ситуация о которой я говорил — я получаю ответы от двух роутеров, ошибки, и в конце завершается одной или несколькими ошибками от третьего роутера. Причем суммарно, в данном случае, я получаю порядка 500 ответов, в зависимости, несколько варьируется, в одном случае я получил больше 500. То есть тут тоже есть какая-то амплификация, и непонятно как оно там устроено внутри.

Или, например, в некоторых случаях я получал на один пинг ответ от 37 разных адресов. Может быть это один маршрутизатор, может быть разные. Это максимальная вариативность ответов, которые я получал.

Есть еще вот такие интересные циклы — состоит из 17 хопов, но 15 отсутствуют, просто не отвечают. Только два хопа отвечают.

Самое максимальное сколько я видел — это когда не отвечают 16 хопов в цикле из 33.

Это один из самых больших циклов, из 34 хопов, который я видел. И что интересно конкретно в этом цикле — все эти хопы находятся, судя по названиям, в сети одного оператора.

Еще встречаются всякие интересные вещи. Вот, например, похоже на то что принципы маршрутизации нарушаются в данном цикле — пакет проходит как будто бы туда и обратно по цепочке маршрутизаторов. Но это еще не самое странное.

Самый странный цикл, который мне удалось обнаружить, выглядит вот так. Цикл длины 14, предположительно задействованы 7 маршрутизаторов (7 адресов). И как минимум из трех автономных систем вот по такой странной траектории ходит этот цикл. Я даже не знаю что это, мне кажется случайно такое нельзя сделать, единственная идея которая мне пришла в голову, это что кто-то взял в рабство сетевого администратора и он тайное послание оставил, чтобы его нашли.

Если вас это всё взволновало и вы занервничали, решили проверить нет ли в вашей сети циклов — вы можете просто зарегистрироваться у нас в Радаре и не искать циклы самостоятельно. По своей автономной системе вы получите информацию не только по циклам, но и по амплификаторам, BGP-инцидентам и другим вещам.

Спасибо за внимание!

Видео презентации доступно по ссылке.

ip. Может ли маршрутизатор уменьшить значение TTL более чем на единицу?

спросил 10 лет, 6 месяцев назад

Изменено 10 лет, 1 месяц назад

Просмотрено 3к раз

В Википедии (Время жить) указано:

Значение времени жизни можно рассматривать как верхнюю границу времени, в течение которого дейтаграмма IP может существовать в системе Интернета. Поле TTL устанавливается отправителем дейтаграммы и уменьшается каждым маршрутизатором по пути к месту назначения .

Является ли «законным» для маршрутизатора уменьшение значения TTL IP-пакета более чем на единицу?

• маршрутизатор
• ip

Да, если маршрутизатору требуется более одной секунды для обработки пакета. Время жизни уменьшается на количество секунд, которое требуется для обработки пакета, и должно быть уменьшено по крайней мере на единицу для каждого устройства, через которое проходит пакет.

Страница 30 RFC 791 гласит:

Время жить

Время жизни устанавливается отправителем на максимальное время, в течение которого дейтаграмма может находиться в интернет-системе. Если дейтаграмма находится в интернет-системе дольше, чем время жизни, то дейтаграмма должна быть уничтожена.

Это поле должно быть уменьшено в каждой точке обработки интернет-заголовка, чтобы отразить время, затраченное на обработку дейтаграммы. Даже если локальная информация о фактически затраченном времени недоступна, поле должно быть уменьшено на 1. Время измеряется в секундах (т. е. значение 1 означает одну секунду). Таким образом, максимальное время жизни составляет 255 секунд или 4,25 минуты. Поскольку каждый модуль, обрабатывающий дейтаграмму, должен уменьшать TTL по крайней мере на единицу, даже если он обрабатывает дейтаграмму менее чем за секунду, о TTL следует думать только как о верхней границе времени существования дейтаграммы. Цель состоит в том, чтобы отбросить недоставленные дейтаграммы и ограничить максимальное время жизни дейтаграммы.

Некоторые протоколы надежного соединения более высокого уровня основаны на предположении, что старые повторяющиеся дейтаграммы не будут поступать по истечении определенного времени. TTL — это способ для таких протоколов гарантировать, что их предположение выполняется.

5

Изначально было задумано, что TTL указывается в секундах; если пакет задерживается в маршрутизаторе более чем на секунду, маршрутизатор соответствующим образом корректирует TTL.

Однако этот подход сложен в реализации и никогда не получал широкой поддержки. Современные маршрутизаторы просто уменьшают TTL на единицу, независимо от фактической задержки, так что TTL на самом деле представляет собой количество переходов.[*7] Рекомендуемое значение TTL по умолчанию равно 64, хотя такие значения, как 15 и 32, не являются редкостью.

[*7] Как вы прочтете в Главе 2, эквивалентное поле в заголовке IPv6 было переименовано в Hop Limit для более точного отражения его истинного использования.

Источник: Routing TCP/IP Volume 1 — 2nd Edition — Cisco Press

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie

Маршрутизатор, который может изменять TTL

спросил 12 лет, 7 месяцев назад

Изменено 10 лет, 9 месяцев назад

Просмотрено 20 тысяч раз

Мой интернет-провайдер установил TTL равным 1. Мой текущий маршрутизатор Linksys WRT120N не может изменить это значение, а мои компьютеры не подключены к Интернету.

Я верну свой текущий роутер и возьму другой. У меня есть несколько вариантов:

• D-Link DIR-615
• D-Link DIR-320
• Линксис WRT54G2
• Линксис WRT54GL

Является ли последний маршрутизатор единственным решением (среди этих маршрутизаторов) моей проблемы?

(Мне нужно купить маршрутизатор в этом магазине: http://laptop.bg/#/accessories/routers/ .. сайт на болгарском языке, но, по крайней мере, модели, из которых я могу выбрать, есть на английском языке.)

• маршрутизатор

Я предполагаю, что ваша проблема заключается в том, что все входящие пакеты имеют значение TTL, равное 1, что приводит к их удалению маршрутизатором. Умная идея вашего интернет-провайдера 🙂

В любом случае, если вы используете альтернативную прошивку маршрутизатора, такую ​​​​как DD-WRT, OpenWrt и т. д., вы должны иметь возможность изменить правила брандмауэра ( iptables ), чтобы установить TTL на другое значение (iptables имеет параметр --ttl-set ). В вики DD-WRT есть некоторая информация об этом: http://www.dd-wrt.com/wiki/index.php/Iptables#Modifying_the_TTL

3

Действительно, есть несколько небольших интернет-провайдеров (размером с район), которые напрямую связывают вас со своим оборудованием по кабелю Ethernet, и они устанавливают TTL = 1 в пакетах DHCP.

Авторизация в их сети основана на MAC-адресе вашей сетевой карты.

Они также заявляют, что вам не разрешено использовать домашний маршрутизатор, если вы не купите более высокую подписку (хромой).

В качестве возможного решения:

• У меня есть беспроводной маршрутизатор Asus WL 500gp V2, для которого я планирую установить OpenWRT, так что могу ли я иметь небольшую коробку с Linux, к которой я могу подключиться с помощью ssh, где я могу изменить настройки TTL моего исходящего соединения. пакеты.

Извините, но я точно не знаю, почему вам нужно менять маршрутизатор (я видел ваш предыдущий пост). TTL (время жизни) — это процесс, который применяется к IP-пакету, когда он проходит через маршрутизатор. Неизменно, когда пакет проходит через маршрутизатор, TTL уменьшается на 1. По сути, каждый пакет имеет конечное время жизни, и TTL гарантирует, что если пакет не будет доставлен, он умрет.

По существу, я не уверен, что смена маршрутизатора является решением проблемы.

1

Игнорируя вопрос о TTL, вы звонили своему интернет-провайдеру и говорили им, что не можете подключиться к Интернету? Я сделал предположение, что вы делаете другие вещи, кроме проверки связи, и они тоже не работают.

Также, независимо от того, какое значение TTL вы установите, вы не сможете контролировать первый маршрутизатор ISP и то, что он делает. Здесь я установил ttl пинга на 64.

 C:\Documents and Settings\myPC>ping superuser.
Уменьшать ttl при маршрутизации: Что такое TTL – как обойти ограничение на раздачу интернета? [2020]