Что может означать если время ttl закончилось до получения ответа
Решение проблем с соединениями в сетях Windows
На сегодняшний день и аппаратное, и программное обеспечения надежнее, чем когда-либо, но даже сейчас иногда возникают неполадки. В этой серии статей я хочу обсудить некоторые техники решения проблем, которые вы можете использовать при возникновении проблем при соединении одного узла в сети Windows с другими. Для тех, у кого мало опыта работы с протоколом TCP/IP, я начну с основ, а затем перейду к более передовым техникам.
Проверка возможности соединения
Например, предположим, что проблема в связи рабочей станции с конкретным сервером. Сам по себе этот факт не дает достаточно информации для принятия решения. Однако если вы углубитесь в проблему и выясните, что связь рабочей станции прервана со всеми серверами сети, то станет понятно, что надо проверить работоспособность кабелей, порт коммутатора, а, возможно, что проблема в конфигурации сети.
В другом случае, если бы рабочая станция соединялась бы только с некоторыми серверами сети, но не со всеми, это также дало бы вам сведения о том, где именно следует искать источник проблемы. В такой ситуации необходимо было бы выяснить, что общего у тех серверов, связь с которыми прервана. Может быть, они все находятся в одной подсети? Если это так, то, скорее всего, у вас проблема с маршрутизатором.
Если у нескольких рабочих станций проблема со связью с конкретным сервером, то ее причина, скорее всего, не в рабочих станциях (разве что они были только что переконфигурированы). В первую очередь нужно проверить сам сервер на корректность функционирования.
Все дело в том, чтобы с помощью нескольких основных тестов быстро получить полезные сведения о рассматриваемой проблеме. Тесты, которые я собираюсь вам сейчас показать, редко смогут точно указать на причину возникшей проблемы, но они всегда помогут ограничить область поиска этой причины.
Опрос(PING)
Опрос – возможно, самое простое диагностическое средство для TCP/IP из всех, но информация, получаемая с его помощью, иногда бывает просто неоценимой. Суть его проста: опрос говорит о том, может ли ваша рабочая станция взаимодействовать с другой машиной.
Я рекомендую начать с того, чтобы открыть окно командной строки, ввести команду ping с IP адресом машины, при взаимодействии с которой возникают проблемы. После этого указанная машина должна дать четыре отклика (Рисунок A).
Рисунок A: указанная машина должна дать четыре отклика
Отклики по существу говорят вам о том, сколько времени требуется удаленной машине, чтобы ответить 32 байтами данных. Например, из Рисунка A мы видим, что каждый из четырех откликов был получен менее чем через 4 миллисекунды.
Обычно результатом выполнения команды ping является одно из четырех возможных событий.
Во-первых, указанная машина может сгенерировать все четыре отклика. Это означает, что с указанным узлом возможно полноценное взаимодействие на уровне TCP/IP.
Второй вариант – для всех четырех запросов превышен интервал ожидания (Рисунок B). Если вы посмотрите на Рисунок A, вы увидите, что каждая строка, уведомляющая об отклике, заканчивается на «TTL=128». TTL обозначает Time To Live – Время жизни. Это значит, что каждый из четырех запросов и откликов должен завершаться за 128 миллисекунд. TTL также уменьшается на единицу для каждого очередного прыжка на обратном пути. Прыжок происходит, когда пакет переходит из одной сети в другую. В дальнейших статьях я много буду про них рассказывать.
Рисунок B: Если для всех запросов превышено время ожидания, это может означать, что взаимодействие не будет осуществляться
Так или иначе, если время ожидания для всех четырех запросов превышается, это значит, что время TTL закончилось до получения ответа. Это может означать один вариант из трех возможных:
И, наконец, четвертое – когда вы получаете ошибку вроде той, что показана на Рисунке C.
Рисунок C: этот тип ошибки указывает на то, что TCP/IP неверно настроен
Ошибка PING: Transmit Failed (передача не удалась) указывает на то, что TCP/IP неверно настроен на той машине, на которой вы пытаетесь выполнить команду ping. Эта ошибка специфична для Vista. В более старых версиях Windows при неверной настройке TCP/IP ошибка также происходит, но сообщение в таком случае выглядит так: «Destination Host Unreachable» (Заданный узел недоступен)
Что если опрос прошел успешно?
Вообще-то, успешный опрос – вещь совсем нередкая, даже в том случае, когда есть проблемы в соединении двух машин. Такая ситуация означает, что сетевая инфраструктура в полном порядке, и что машины в состоянии взаимодействовать на уровне TCP/IP. Чаще всего это хорошо, так как означает, что проблема не слишком серьезна.
Если обычные соединения между двумя машинами не удаются, но они опрашивают друг друга успешно (необходимо выполнить команду ping на обеих машинах), вы можете попробовать что-нибудь другое. Вместо опроса сетевого узла по IP адресу можно попробовать использовать полное доменное имя узла (Рисунок D).
Рисунок D: попытка опроса узла по полному доменному имени
Если опрос по IP адресу проходит, а по доменному имени – нет, значит, проблема, скорее всего, с DNS. На рабочей станции может быть настроен неправильный DNS, или сервер DNS может не содержать корректной записи для машины, с которой вы пытаетесь наладить связь.
Если вы посмотрите на Рисунок D, вы увидите, что IP адрес узла назначения указан справа от его полного доменного имени. Это доказывает, что машине удалось преобразовать полное доменное имя. Также нужно убедиться в том, что полученный IP адрес верен. Если вы видите IP адрес, отличный от ожидаемого, значит, у вас, видимо, неверна запись об узле в DNS.
Что такое TTL и на что влияет «Время жизни пакета» на смартфоне и у маршрутизатора?
ВНИМАНИЕ! По последним данных от надежного источника стало известно, что не только TTL является причиной блокировки мобильного интернета. Если же вам нужна информация по ТТЛ для роутеров, и на что данный протокол влияет, то смотрите последнюю главу.
Всем доброго времени суток! Скорее всего ты зашел сюда для того, чтобы обойти блокировку мобильного оператора. Ведь с помощью именно TTL данные компании ловят за руку абонентов, который включили на своем телефоне режим точки доступа. Что такое TTL? Time To Live – это время жизни пакета во вселенной IP адресации.
Когда пользователь включает режим модема или точки доступа, то телефон начинает раздавать Wi-Fi вместе с интернетом. При подключении компьютера, ноутбука, телевизора, приставки или другого телефона (планшета) провайдер именно за счет TTL и понимает, что идет раздача интернета на другое устройство.
На данный момент этим грешат такие операторы как МТС, Билайн, YOTA, Теле2 и другие. Насколько я помню, только у Мегафона ограничения пока нет, но я могу ошибаться – поправьте меня в комментариях, если я не прав. Далее я расскажу, как узнать значение TTL, как его поменять и как обойти блокировку. Начнем с теории – советую её прочесть, чтобы вам в дальнейшем было все понятно.
Более подробно про TTL
Разберем на простом примере. У вас есть телефон, который при подключении к мобильному интернету оператора постоянно отправляет запросы. В каждом таком запросе есть значение TTL, которое по умолчанию равно 64 – на Android и iOS. У Windows Phone, насколько помню, это значение равно 130.
После того как на телефоне включен режим роутера и идет раздача Wi-Fi с интернетом, к нему подключаются другие устройства. На Windows TTL по умолчанию равно 128. На других телефонах 64.
А теперь мы подошли к самой сути TTL. Как вы помните, TTL это время жизни пакета, а называется оно так, потому что при проходе через один узел или устройство, данное значение уменьшается на 1. В итоге компьютер, подключенный к вашему телефону будет отправлять запрос в интернет с TTL, который будет равен 127 (то есть минус 1). От подключённых телефонов ТТЛ будет равен уже 63.
В итоге на сервер оператора от вашего телефона приходят три пакета с разными ТТЛ. Оператор понимает, что дело не чисто, и блокирует устройство. Но блокировку можно также легко обойти.
Обход блокировок
Обходится блокировка достаточно просто – нужно на подключенных устройствах выставить TTL, который будет ровен на 1 больше чем у раздающего телефона. Например, вы раздаете интернет на ноутбук, тогда нужно установить у этого устройства ТТЛ со значение на 1 больше чем у раздающего устройства (то есть 65). В итоге пакет от компьютера, попадая на телефон будет принимать значение 64. Оператор будет видеть, что все пакеты одинаковые, и никого блокировать не будет.
ПРИМЕЧАНИЕ! Можно, конечно, не уменьшать ТТЛ на принимающем устройстве, а уменьшить его на раздающем, но для этого понадобятся ROOT права и программа TTL Master. Поэтому проще всего изменить значение на второстепенных аппаратах – об этом поподробнее чуть ниже.
Но есть ещё одна загвоздка, про которую нигде почему-то не написано. Дело в том, что операторы начали также по-другому вычислять раздачу. У провайдера есть список серверов, к которым можно обратиться только с компьютера.
Например, если на подключенном компьютере начнется обновление Windows, то оператор это сразу поймет. Потому что с телефона никто в здравом уме не будет обращаться к серверам обновления от Microsoft. Список таких серверов постоянно пополняется. Но и эта проблема достаточно легко решается. По этому поводу у нас на портале есть подробные инструкции для всех операторов:
Там расписаны все шаги с картинками и пояснениями. Также вы сможете определить и проверить свой ТТЛ, но на деле они имеют одинаковые значения для всех типов устройств, о которых я написал в самом начале.
TTL в роутере
Также этот параметр встречается и в роутере, а также в любых сетях, которые работают с IP адресами. На уровне маршрутизации пакетов ТТЛ постоянно используется как внутри сети пользователя, так и в сети провайдера.
Например, у Keenetic есть параметр «Не уменьшать TTL» – который нужен для того, чтобы пакеты данных от маршрутизатора провайдера при проходе через ваш роутер не уменьшался. Дело в том, что некоторые провайдеры специально выставляют ТТЛ=1. Сделано это для того, чтобы к основным шлюзам всякие нехорошие люди не подключили сторонние маршрутизаторы.
Проблема в том, что если убрать эту галочку, то при проходе пакета ТТЛ уменьшится до 0. А ТТЛ со значение 0 отбрасываются и уничтожаются всеми сетевыми устройствами, который работают на уровне IP адресации. То есть ваш компьютер или любое другое устройство просто не будет принимать эти пакеты.
Ещё раз объясню – это нужно для того, чтобы пользователь не подключал к своему роутеру других абонентов через другие шлюзы. Это если вы захотите стать провайдером для кого-то ещё. Понятное дело, провайдер начнет вас блокировать.
Теоретически да, но делать это НЕЛЬЗЯ по установленному пункту в договоре от поставщика услуг. Не знаю точно, что может грозить за это, но огромный штраф и судебное дело – вполне реально.
С другой стороны, данный параметр иногда нужно изменять при настройке локальной сети компании или предприятия. В таком случае будет использоваться несколько маршрутизаторов. В этом случае поможет TELNET для изменения параметра (x – это значение от 1 до 255) для входящих пакетов:
ПРИМЕЧАНИЕ! 255 – это максимальное возможное значение TTL.
interface ISP ip adjust-ttl inc x
interface ISP ip adjust-ttl dec x
interface ISP ip adjust-ttl set x
Для исходящих данных к провайдеру, нужно заменить «ISP» на «Home». Например:
interface Home ip adjust-ttl inc 1
СОВЕТ! Не забываем сохранить изменения командой:
system configuration save
На роутере ASUS есть два других параметра, которые решают аналогичные проблемы:
Подобные значения есть у всех роутеров. Для более продвинутых пользователей их можно изменять в роутер через командную строку (TELNET). В общем, все обходится, и ничего заблокировать нельзя, да пребудет свобода в беспроводном и проводном пространстве – первая заповедь великого Wi-Fi-Гида, да растет его борода!
Что такое время жизни пакета (TTL)
Вероятно, многие из нас обращали внимание на параметр TTL в запущенной команде ping. Расшифровывается TTL как Time to live.
Время жизни пакета это предельное число итераций, которое пакет данных может совершить до своего исчезновения. Выражаясь не так официально, TTL — это число «прыжков» от устройства к устройству, которое может совершить пакет.
Строго говоря, TTL это не только про пакеты данных. Время жизни имеют и другие вещи, например, DNS-записи на серверах. Поэтому не связывайте понятие TTL только с пакетами данных.
Возвращаясь к теме статьи, объясним предназначение времени жизни пакета. Дело в том, что данные в сети имеют свойство зацикливаться, что создаёт своего рода «мусорный» трафик. Поскольку количество «прыжков» между узлами у пакетов ограничено, они не смогут «бродить» по сети вечно.
На самом деле, изначально предполагалось, что TTL пакетов будет измеряться в секундах. Так что это должно было быть время в буквальном смысле слова. Однако позже от этой концепции отказались в пользу простого числа «прыжков» или хопов (hop). На каждом промежуточном узле это число уменьшается на единицу (по умолчанию, хотя настройки можно выставить иначе). Если число «прыжков» у пакета истекло, а адресата он так и не достиг, этот пакет уничтожается, а адресату направляется сообщение о необходимости повторной отправки данных (Time Exceeded). Учтите, что коммутаторы оставшееся число «прыжков» не изменяют, так как действуют на канальном уровне (более низком) модели OSI, а не сетевом.
Время жизни пакета задаётся в соответствующем поле в заголовке IPv4-пакета. В стандарте IPv6 используется уже другое поле Hop Limit. Максимально возможное значение TTL равно 255. В большинстве популярных операционных систем (macOS, Linux, Android, iOS и т.д.) TTL=64. В Windows по умолчанию TTL=128.
TTL и интернет-провайдеры
Достаточно интересно используют TTL пакетов интернет провайдеры для обнаружения несанкционированного подключения устройств. Способ массово стал использоваться со временем распространения мобильного интернета и устройств, которые могут этот интернет не только потреблять, но и раздавать другим (смартфоны, планшеты).
Как это выглядит на практике? Если Вы пользуетесь мобильным интернетом со смартфона, то тот отправляет TTL=64, но, если раздать с него Wi-Fi, то TTL подключенных устройств будет изменяться на единицу. Нагляднее это можно проследить на схеме ниже.
Изменение TTL при раздаче Wi-Fi со смартфона.
Таким образом, оператор видит, что TTL «прыгает» с 64 до 63, а то и до 127 (если это ноутбук с Windows), и делает вывод, что в сеть выходит не одно устройство, а больше. В зависимости от условий предоставления связи, это может привести к блокировке.
Мы не будем в этой статье рассматривать способы обхода блокировок. Скажем лишь, что значение TTL по умолчанию можно изменить. Возьмём для примера Windows. Если вы запустите ping localhost, то увидите, что, как и говорилось ранее, TTL=128.
Для изменения установленного по умолчанию значения TTL нам нужно открыть редактор реестра, пройти в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters и отредактировать (или создать, если его нет) параметр DefaultTTL. Если у вас 64-битная версия ОС, то тип параметра будет QWORD (64 бита), если 32-битная версия ОС, то тип DWORD (32 бита). Система исчисления — десятичная, а значение можете задать от 1 до 255. Например, 65. Тогда пакеты данных, пройдя через раздающий Wi-Fi смартфон, будут выдавать TTL=64.
Изменение значения TTL в Windows.
После этого перезагрузите компьютер. Снова запустив ping localhost, можно увидеть, что значение TTL изменилось.
Отдельно стоит упомянуть протокол IPv6. Если вы его используете, то нужная вам в реестре ветка: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TCPIP6\Parameters.
О том, как провернуть подобную настройку в Ubuntu, читайте в статье по этой ссылке.
Хватит использовать смехотворно малый TTL для DNS
Низкая задержка DNS — ключевой фактор для быстрой работы в интернете. Чтобы её минимизировать, важно тщательно подобрать DNS-серверы и анонимные рилеи. Но первым делом следует избавиться от бесполезных запросов.
Именно поэтому DNS изначально создавался как сильно кэшируемый протокол. Администраторы зон устанавливают время жизни (TTL) для отдельных записей, а резолверы используют эту информацию при хранении записей в памяти, чтобы избежать ненужного трафика.
Эффективно ли кэширование? Пару лет назад моё небольшое исследование показало, что оно не идеально. Взглянем на нынешнее положение дел.
Для сбора информации я пропатчил Encrypted DNS Server для сохранения значения TTL для ответа. Оно определяется как минимальное TTL его записей, для каждого входящего запроса. Это даёт хороший обзор распределения TTL реального трафика, а также учитывает популярность отдельных запросов. Пропатченная версия сервера работала несколько часов.
Результирующий набор данных состоит из 1 583 579 записей (name, qtype, TTL, timestamp). Вот общее распределение TTL (ось X — это TTL в секундах):
Если не считать незначительного бугра на 86 400 (в основном, для записей SOA), довольно очевидно, что TTL находятся в низком диапазоне. Посмотрим ближе:
Хорошо, TTL более 1 часа статистически не значимы. Тогда сосредоточимся на диапазоне 0−3600:
Большинство TTL от 0 до 15 минут:
Подавляющее большинство от 0 до 5 минут:
Это не очень хорошо.
Накопительное распределение делает проблему ещё более очевидной:
В половине DNS-ответов TTL составляет 1 минуту или меньше, а у трёх четвертей — 5 минут или меньше.
Но подождите, на самом деле всё ещё хуже. Ведь это TTL от авторитативных серверов. Однако клиентские резолверы (например, маршрутизаторы, локальные кэши) получают TTL от вышестоящих резолверов, и он уменьшается каждую секунду.
Таким образом, клиент фактически может использовать каждую запись, в среднем, в течение половины исходного TTL, после чего отправит новый запрос.
Может, эти очень низкие TTL касаются только необычных запросов, а не популярных веб-сайтов и API? Давайте посмотрим:
Ось X — это TTL, ось Y — популярность запросов.
К сожалению, самые популярные запросы также и хуже всего кэшируются.
Вердикт: всё действительно плохо. Уже и раньше было плохо, а стало ещё хуже. Кэширование DNS стало практически бесполезным. Поскольку всё меньше людей используют DNS-резолвер своего провайдера (по уважительным причинам), увеличение задержки становится более заметной.
Кэширование DNS стало полезным только для контента, который никто не посещает.
Также обратите внимание, что программное обеспечение может по-разному интерпретировать низкие TTL.
Почему так?
Почему для записей DNS устанавливается такой малый TTL?
Кроме того, минутный TTL означает, что если авторитетные DNS-серверы будут заблокированы более чем на 1 минуту, никто больше не сможет получить доступ к зависимым службам. И избыточность не поможет, если причиной является ошибка конфигурации или взлом. С другой стороны, с разумными TTL много клиентов продолжат использовать предыдущую конфигурацию и никогда ничего не заметят.
В низких TTL в значительной степени виноваты cервисы CDN и балансировщики нагрузки, особенно когда они объединяют CNAME с малыми TTL и записи с такими же малыми (но независимыми) TTL:
Всякий раз, когда истекает CNAME или любая из записей A, приходится отправлять новый запрос. У обоих 30-секундный TTL, но он не совпадает. Фактический средний TTL будет 15 секунд.
Но подождите! Всё еще хуже. Некоторые резолверы очень плохо себя ведут в такой ситуации с двумя связанными низкими TTL:
Резолвер Level3, наверное, работает на BIND. Если вы продолжите отправлять этот запрос, всегда будет возвращаться TTL, равный 1. По существу, raw.githubusercontent.com никогда не кэшируется.
Вот ещё один пример такой ситуации с очень популярным доменом:
Не менее трёх записей CNAME. Ай. У одной приличный TTL, но это совершенно бесполезно. В других CNAME первоначальный TTL составляет 60 секунд, но для доменов akamai.net максимальный TTL составляет 20 секунд, и ни один из них не в фазе.
Как насчёт доменов, которые постоянно опрашивают устройства Apple?
Та же проблема, что у Firefox, и TTL большую часть времени застрянет на 1 секунде при использовании резолвера Level3.
У записи safebrowsing.googleapis.com значение TTL 60 секунд, как и у доменов Facebook. И, опять же, с точки зрения клиента, эти значения уменьшаются вдвое.
Как насчёт установки минимального TTL?
Используя имя, тип запроса, TTL и изначально сохранённую временную метку, я написал скрипт для имитации 1,5 миллиона запросов, проходящих через кэширующий резолвер, чтобы оценить объём лишних запросов, отправленных из-за просроченной записи кэша.
47,4% запросов были сделаны после истечения срока действия существующей записи. Это неоправданно высоко.
Каково будет влияние на кэширование, если установлен минимальный TTL?
Ось X — это минимальные значения TTL. Записи с исходными TTL выше этого значения не затронуты.
Ось Y — процент запросов от клиента, у которого уже есть кэшированная запись, но её срок действия истёк и он делает новый запрос.
Доля «лишних» запросов снижается с 47% до 36% простой установкой минимального TTL в 5 минут. При установке минимального TTL в 15 минут количество этих запросов снижается до 29%. Минимальный TTL в 1 час снижает их до 17%. Существенная разница!
Как насчёт того, чтобы ничего не менять на стороне сервера, а вместо этого установить минимальные TTL в клиентских DNS-кэшах (маршрутизаторы, локальные резолверы)?
Количество требуемых запросов снижается с 47% до 34% при установке минимального TTL в 5 минут, до 25% с минимумом в 15 минут и до 13% с минимумом в 1 час. Возможно, оптимальное значение 40 минут.
Влияние этого минимального изменения огромно.
Каковы последствия?
Конечно, сервис можно перевести на нового облачного провайдера, новый сервер, новую сеть, требуя от клиентов использовать последние записи DNS. И достаточно малый TTL помогает плавно и незаметно осуществить такой переход. Но с переходом на новую инфраструктуру никто не ожидает, что клиенты перейдут на новые записи DNS в течение 1 минуты, 5 минут или 15 минут. Установка минимального срока жизни в 40 минут вместо 5 минут не помешает пользователям получить доступ к сервису.
Однако это позволит значительно сократить задержку и повысить конфиденциальность и надёжность, избегая ненужных запросов.
Конечно, RFC говорят, что нужно строго соблюдать TTL. Но реальность такова, что система DNS стала слишком неэффективной.
Если вы работаете с авторитативными DNS-серверами, пожалуйста, проверьте свои TTL. Вам действительно нужны такие смехотворно низкие значения?
Конечно, есть веские причины установки малых TTL для DNS-записей. Но не для 75% трафика DNS, который практически не меняется.
И если по каким-то причинам вам действительно нужно использовать низкие TTL для DNS, заодно убедитесь, что на вашем сайте не включено кэширование. По тем же причинам.
Если у вас работает локальный DNS-кэш, такой как dnscrypt-proxy, который позволяет устанавливать минимальные TTL, используйте эту функцию. Это нормально. Ничего плохого не случится. Установите минимальный TTL примерно между 40 минутами (2400 секунд) и 1 часом. Вполне разумный диапазон.