Превышен срок жизни ttl при передаче пакета hamachi
Что делать, если появляется ошибка?
И первым делом, если в Hamachi «превышен интервал ожидания для запроса», рекомендуем перезапустить программу и перезагрузить компьютер. Для этого воспользуйтесь кнопкой (включить/выключить), расположенной на главной странице приложения. Если это не помогло, то предлагаем изменить настройки сетевого адаптера Hamachi:
- Открываем вкладку «Сетевое подключение». Для этого нужно перейти в «Центр управления сетями и общим доступом», а после выбрать «Изменение параметров адаптера».
- Кликаем ПКМ по пункту с Хамачи.
- В появившемся меню отмечаем вариант «Свойства».
- Ставим галочку возле строки «IP версии 4», а после еще раз переходим в свойства.
- Кликаем «Дополнительно» и удаляем созданный автоматически шлюз (25.0.0.1).
- В графу «Метрика интерфейса» вводим цифру 10 и сохраняем изменения.
- Открываем Hamachi и переходим в раздел «Параметры». Возле пунктов «Сжатие» и «Шифрования» выставляем значения «Любой».
И после выполнения представленных действий перезапускаем приложение и проверяем наличие ошибки. Если по-прежнему в Хамачи превышено время ожидания, то причина проблемы с интервалом для запроса кроется в стандартном брандмауэре Windows. Скорее всего, он попросту блокирует соединение, что и приводит к возникновению ошибки. Решение в этом случае одно – добавить программу в перечень исключений:
- Открываем «Панель управления» и заходим во вкладку «Безопасность Windows».
- Нажимаем по пункту «Брандмауэр и защита сети», а затем кликаем «Разрешить работу с приложениями…».
- Нажимаем по строке «Изменить параметры», после чего отмечаем «Разрешить другое приложение».
- Указываем путь к Hamachi, воспользовавшись проводником Windows.
- Сохраняем изменения, тем самым добавив программу в перечень исключений встроенного брандмауэра. После этого сбой «превышен интервал ожидания для запроса» возникать не должен.
Вероятно, многие из нас обращали внимание на параметр TTL в запущенной команде ping. Расшифровывается TTL как Time to live.
Время жизни пакета это предельное число итераций, которое пакет данных может совершить до своего исчезновения. Выражаясь не так официально, TTL — это число «прыжков» от устройства к устройству, которое может совершить пакет.
Строго говоря, TTL это не только про пакеты данных. Время жизни имеют и другие вещи, например, DNS-записи на серверах. Поэтому не связывайте понятие TTL только с пакетами данных.
Возвращаясь к теме статьи, объясним предназначение времени жизни пакета. Дело в том, что данные в сети имеют свойство зацикливаться, что создаёт своего рода «мусорный» трафик. Поскольку количество «прыжков» между узлами у пакетов ограничено, они не смогут «бродить» по сети вечно.
Время жизни пакета задаётся в соответствующем поле в заголовке 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, читайте в статье по этой ссылке.
openvpn
Подскажите где может быть ошибка
192.168.21.2 это рабочая комп за натом в офисе и до него надо достучаться клиенту через удаленный рабочий стол.
openvpn поднят.
Пинг с сервака 10.20.30.1 до клиента 10.20.30.6
проходит.
Обратно то же.
Но достучаться до 192.168.21.2 по тунелю немогу.
Делаю пинг у клиента
C:\Documents and Settings\Серж>ping 192.168.21.2
Обмен пакетами с 192.168.21.2 по 32 байт:
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Статистика Ping для 192.168.21.2:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
C:\Documents and Settings\Серж>
C:\Documents and Settings\Серж>tracert -d 192.168.21.2
Трассировка маршрута к 192.168.21.2 с максимальным числом прыжков 30
1 8 ms 8 ms 13 ms 10.20.30.6
2 134 ms 17 ms 17 ms 10.20.30.6
3 25 ms 24 ms 24 ms 10.20.30.6
4 36 ms 37 ms 35 ms 10.20.30.6
5 43 ms 45 ms 40 ms 10.20.30.6
6 50 ms 48 ms 50 ms 10.20.30.6
7 63 ms 59 ms 63 ms 10.20.30.6
8 636 ms 73 ms 76 ms 10.20.30.6
9 88 ms 76 ms 680 ms 10.20.30.6
10 109 ms 93 ms 199 ms 10.20.30.6
C:\Documents and Settings\Серж>route print 192.168.21.2
===========================================================================
Список интерфейсов
0x1 . MS TCP Loopback interface
0x2 . 00 1c 23 a1 33 8c . ASUS NX1101 Gigabit Ethernet Adapter - ?шэшяюЁЄ
яырэшЁют?шър яръхЄют
0x3 . 00 13 20 8c ae 4f . Intel(R) PRO/100 VE Network Connection - ?шэшяюЁ
Є яырэшЁют?шър яръхЄют
0x4 . 00 ff 2e 25 6a c3 . TAP-Win32 Adapter V8 - ?шэшяюЁЄ яырэшЁют?шър яръ
хЄют
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
192.168.21.2 255.255.255.255 10.20.30.5 10.20.30.6 1
Основной шлюз: 10.44.30.1
10.44.30.1 Это шлюз провайдера клиента. (сидящего дома)
"Гента вообще форкLFS в свою очередь мутант Скалвари
которая BSD с ядром Линя BSD - мутировал-AT&T UNIX
а там был UNICS - MULTICS, счёты, глиняные таблички, палочки,
большой взрыв, сингулярность, пиз. ц. Вывод: RedHat использует пиз..ц. "
Есть керио на одном физическом порту LAN настроен ip 192.168.1.252/24, а так же дополнительный адрес 10.11.0.1/16. DHCP выдаёт ip адреса из сети 192.168.1.0/24.
Есть компьютер, который получил адрес по DHCP.
С компьютера отлично пингуется шлюз 192.168.1.252 и другой комп 10.11.0.2. Потерь нет, задержка 1мс.
А вот если выполнять команду tracert начинаются чудеса.
так же при выполнении пинга
Вот меня мучает вопрос: что-тут вообще может происходить?
Оценить 1 комментарий
А как вы хотите с TTL=1 дойти до хоста за шлюзом? Шлюз декрементит TTL до 0 и дальше пакет не пойдёт т.к. время его жизни истекло. TTL определяет максимальное количество хостов МЕЖДУ source и destination хостами.
По поводу потерь пакетов в трассировке смотрите политики/логи на шлюзе, возможно просто кабель плохо обжат, или коннектор не до конца воткнут, а может аппаратная/программная проблема оборудования (как компьютера, так и шлюза).
ну так это логично.
-i 1 знаете за что отвечает? время жизни пакета TTL (Time to live)
так же почитайте тут
Я этот параметр не просто так вводил, а для локализации проблемы.
При истечении времени жизни, узел должен ответить "Превышен срок жизни (TTL) при передаче пакета.", , а он в 39% случаев не отвечает.
Читайте пожалуйста внимательнее вопрос.
Проблема, наверное, не в ТТЛ.
Возможно ваш керио чем-то сильно занят, из-за чего не успевает обрабатывать пакеты.
А может он таким образом борется с DOS атаками по ICMP. Посмотрите настройки керио в этом направлении.
Еще для тестирования попробуйте так:
ping 192.168.0.252 -t
Думаю, что провалы в пинге начнут и тут проявляться.
Если в остальном производительность устраивает, то можно забить.
"Еще для тестирования попробуйте так:
ping 192.168.0.252 -t"
неа. в вопросе описал, что в этом случае ни потер, ни задержек нет
Если бы керио был бы занят и дропал пакеты, то эти признаки были бы и в других ситуациях.
"А может он таким образом борется с DOS атаками по ICMP. Посмотрите настройки керио в этом направлении." самое разумное объяснение, но в логах атак про это ни слова. да и странный какой-то способ блокировки. через раз
LAG_LAGbI4: В вопросе вы написали, имея ввиду обычный пинг, я же добавил в команде ключ -t - бесконечный пинг до прерывания. Имел ввиду, что, скорее всего, через какое-то количество пингов или время начнут появляться потери.
Если это борьба с DOS атаками, то обычно должны быть опции для настройки поведения и для теста можно отключить это. Потом вернуть на место.
На счет странного способа - по моему способ нормальный. Вы бы как боролись с DOS атаками? Думаю тут не через раз, а например что-нибудь типа "блокировка аналогичных пакетов на какой-нибудь не большой промежуток времени", если начинают заваливать пакетами, то промежуток времени увеличивается.
Задав соответствующий вопрос в Twitter, мы выяснили, что некоторые системные администраторы даже не могут расшифровать аббревиатуру TTL (хотя такие, к счастью, в меньшинстве).
Отгадайте загадку! Что означает аббревиатура TTL, когда речь идет о системе DNS?
18:43 26 окт. 2016 г.
4 % Граница терминальной передачи
85 % Время жизни
8 % Телеметрическая транспортная линия
3 % Список доверенных технологий
26 голосов • Окончательный результат
Ретвит 1 Отметка «Нравится» 1
Чтобы внести ясность, мы рассмотрим следующие темы.
1. Общие сведения о системе DNS и параметре TTL
2. Устранение проблем с TTL в записях DNS
3. Рекомендации по управлению изменениями в записях DNS
4. Инструменты DNS
5. Дальнейшие действия
1. ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ DNS
Что такое запись DNS?
Запись сервера доменных имен (Domain Name Server, DNS) содержит два важных параметра:
адресацию (установку соответствия) запросов для той или иной записи;
время актуальности записи при кэшировании — именно это значение получило зловещее название «время жизни» (TTL).
Зачем кэшируются записи DNS?
Многие организации настраивают записи DNS один раз и после этого годами не изменяют их. Поскольку записи DNS часто запрашиваются, но редко обновляются, их кэширование помогает значительно повысить производительность сети, увеличивая при этом сложность оценки и устранения проблем с DNS.
Что такое TTL?
Время жизни (TTL) представляет собой продолжительность кэширования записи *каждым звеном* цепочки установки соответствий DNS. Это значение измеряется в секундах (важность этого будет объяснена ниже).
К сожалению, общепринятый термин «время жизни» нельзя назвать исчерпывающим. Возможно, более логичным было бы название «время на поиск» или «продолжительность хранения записи DNS в кэше».
Каково стандартное значение TTL для записей DNS?
Значение TTL всегда выражается в секундах. Большинство служб настройки конфигурации DNS содержат готовый список значений для записей.
300 секунд = 5 минут = «Очень короткое»
3600 секунд = 1 час = «Короткое»
86 400 секунд = 24 часа = «Длинное»
604 800 секунд = 7 дней = «Абсолютный максимум»
Как осуществляется поиск DNS?
Когда вы вводите в браузере какой-либо URL-адрес, создается целая серия поисков.
На каждом этапе этого процесса (часто этапов бывает больше, чем перечислено) задаются следующие вопросы.
1. Кэширована ли нужная запись?
2. Если да, действительно ли ее значение TTL?
Если на какой-либо из этих вопросов получен ответ «Нет», запрос перемещается на следующее звено цепочки.
Почему в основе системы DNS лежат сетевые подключения, а не устройства?
Устранение проблем с DNS представляет собой непростую задачу не только из-за ряда сложностей, связанных с использованием TTL и системы кэширования, но и потому, что подключение многих современных устройств осуществляется через различные сети и цепочки серверов DNS.
Рассмотрим ситуацию на примере обычного ноутбука. Я, как правило, работаю на ноутбуке дома. Несмотря на то что я уже несколько недель никуда его не брал, за это время на устройстве устанавливались следующие подключения:
• к основной домашней сети Wi-Fi/кабельной сети;
• к мобильному телефону при недоступности кабельной сети;
• оба варианта выше, но с подключением через VPN.
При каждой смене сети активируется новая цепочка DNS. Если это происходит в момент внесения изменений, серверы и узлы кэширования в цепочке DNS могут предоставлять неверные данные.
Сразу же начнется паника: «Веб-сервер не работает!», «Это конец света!», «Где мои брюки?». Но, приступив к устранению проблемы, вы обнаружите, что ее причиной стало незакрытое подключение через VPN.
2. УСТРАНЕНИЕ ПРОБЛЕМ С TTL В ЗАПИСЯХ DNS
Сколько времени требуется на обновление записи DNS?
Для расчета максимального (худший случай) временного интервала, необходимого на обновление значения записи DNS в ссылках для всех клиентов, умножьте число звеньев цепочки (без учета полномочного сервера) на значение TTL.
Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).
Но если бы все было так просто.
Каковы затраты на поиск DNS?
Когда речь заходит о «затратах» на поиск DNS, обычно имеются в виду не денежные, а временные затраты. В зависимости от численности интернет-гремлинов в глобальной сети на выполнение запроса DNS обычно уходит 100–200 миллисекунд.
Это очень небольшое время, но представьте себе веб-страницу. Соответствие между именем и IP-адресом в системе DNS необходимо настроить для всех изображений, файлов CSS и файлов активов JavaScript, доступных по ссылкам на странице. Без кэширования время загрузки заметно увеличится.
Упрощенная схема расчета затрат на поиск DNS
Я назвал эту схему упрощенной, поскольку маловероятно, что все активы на вашем веб-сайте находятся в разных доменах. Кроме того, в браузеры встраивается множество различных средств кэширования, которые обеспечивают более быструю загрузку содержимого, чем показано в моей схеме.
(30 файлов изображений x 50 мс на загрузку каждого файла) + (100 мс на выполнение одного поиска DNS с последующим кэшированием) = 1600 мс
(30 файлов изображений x 50 мс на загрузку каждого файла) + (30 x 100 мс на каждый поиск DNS) = 3000 мс
Почему мои записи DNS не обновляются?
Существуют и другие факторы, увеличивающие время распространения изменений. Некоторые из них перечислены ниже.
• Веб-браузеры самостоятельно кэшируют записи DNS и хранят их в течение некоторого времени без учета TTL, что якобы повышает скорость их работы. Например, современные версии Internet Explorer по умолчанию кэшируют записи DNS на 30 минут (до версии IE 4 это время составляло 24 часа) и игнорируют более низкие значения TTL.
• Поставщики мобильного Интернета могут пытаться уменьшить общий объем передаваемого трафика путем увеличения времени TTL, что снижает частоту запросов.
• Сложные внутренние сети с большим числом сервером DNS, чем предполагалось, обновляются дольше по очевидным причинам.
Именно поэтому во многих службах можно встретить следующее заявление: «Полное распространение изменений в записях DNS может занять несколько дней, поэтому планируйте свои действия соответствующим образом».
Можно ли как-нибудь принудить клиент удаленно обновить запись DNS?
Этот вопрос обычно задается в следующем контексте: «После обновления записей DNS клиент не может получить доступ к некоторым сайтам. Как выполнить обновление принудительно?»
К сожалению, единственный ответ на этот вопрос: «Никак». В системе DNS нет команды, позволяющей принудительно выполнить раннее обновление данных для клиентов более низкого уровня.
Можно использовать команды для удаления записей DNS из локального кэша, но обычно они работают не так эффективно, как хотелось бы, из-за наличия как восходящих (кэширование записей DNS на стороне поставщика Интернета), так и нисходящих (кэширование записей DNS в браузере) каналов.
Лучше всего изменить значения TTL в своих записях заблаговременно.
3. РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ В ЗАПИСЯХ DNS
Какие значения TTL лучше: маленькие или большие?
Разработчики уже давно ведут священную войну по поводу того, как нужно оформлять отступы в коде: с помощью знаков табуляции или пробелов. Я выяснил, что сетевые администраторы испытывают примерно те же чувства, когда дело касается длительности TTL.
Обычно это мнение подкрепляется их собственным опытом по отражению предыдущих сетевых атак и устранению проблем с конфигурацией сети.
Атака DDOS, способная на 12 часов остановить работу корневых серверов DNS или аналогичных серверов поставщика Интернета, меньше скажется на сайтах с очень высоким значением TTL. В таких случаях клиенты будут работать даже при выключении или перегрузке сервера DNS.
Однако, если при переключении узлов Интернета или электронной почты вы случайно сделаете ошибку, 12 часов без какой-либо возможности устранить ее — это последнее, что вам будет нужно. Именно поэтому некоторые администраторы считают, что время жизни не должно превышать 1 минуты.
Лично я стараюсь указывать для записей DNS малое значение TTL (меньше 1 часа/3600 секунд).
Как узнать, когда клиент запросит обновленную запись DNS?
Определить, когда все клиенты обновят данные, очень сложно.
Время жизни — это *не* срок годности. Не стоит сравнивать значение TTL в записи DNS с рекомендуемой датой употребления, указанной, например, на несвежем хлебе: это не определенное время, при наступлении которого запись станет недействительной и потребует замены.
Запись DNS — это, скорее, штатное расписание, изменения в котором медленно распространяются по всей сети. Когда у клиентов, расположенных в расписании «ниже», истекает срок действия кэша, они запрашивают запись у сервера DNS более высокого уровня.
Как лучше всего изменять записи DNS?
Создание «плана» или «стратегии» для выполнения относительно простых задач, к которым относится изменение одной записи в домене, может казаться перегибом, но, учитывая колоссальное влияние сбоев DNS на доступность ваших данных, определенную осторожность проявить все же стоит. Как говорится в старой пословице: «Предотвратить легче, чем лечить».
Есть простой способ свести ошибки к минимуму: никогда не обновляйте запись DNS и значение TTL для этой записи одновременно. В идеале у вас должен быть реализован следующий процесс.
1. За несколько дней до переключения укажите для параметра TTL записи DNS низкое значение, например 300 секунд.
2. Установите для записи дату переключения.
3. Через несколько дней после переключения задайте более высокое значение TTL.
Как лучше всего добавлять новые записи DNS?
Добавить новую запись проще, чем изменить существующую.
1. Добавьте запись с низким значением TTL.
2. Проверьте, все ли работает, и увеличьте значение TTL.
Какое значение TTL наиболее распространено?
Мнения относительно *правильного* значения TTL настолько расходятся, что мы предприняли попытку определить его на основе статистики. Список из 500 самых важных веб-сайтов по версии Moz показался нам отличным срезом Интернета. Кроме того, на этом ресурсе был доступен готовый файл CSV с перечнем сайтов, вошедших в итоговый список.
Я написал небольшой сценарий для выполнения итерации по списку и поиска текущего значения TTL для основной записи в каждом домене. Как и в любом проекте по анализу данных, эти данные будут сильно варьироваться в зависимости от постановки вопроса. Пример не всеобъемлющий, в нем представлены текущие (кэшированные) результаты и т. д. и т. п. Невзирая на все эти оговорки, полученные результаты все же имеют определенную ценность.
Анализ значений TTL для 500 важнейших интернет-доменов по версии Moz
Минимальное значение TTL: 1
Максимальное значение TTL: 129 540
Домены с установленным соответствием: 485
Среднее арифметическое значение TTL: 6468
Медианное значение TTL: 300
При необходимости обосновать свое решение об установке низкого (в пределах 1 часа, 3600 секунд) значения TTL вы можете предоставить медианное значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирическое доказательство правильности своего выбора.
4. ИНСТРУМЕНТЫ ПЛАТФОРМЫ DNS
Как проверить значение TTL для записи DNS в Windows?
Значение TTL указывается в нижней части выходных данных. Фраза Non-authoritative answer (Не заслуживающий доверия ответ) указывает на значение TTL, полученное от клиента (2 минуты 11 секунд до проверки локальным клиентом следующего уровня в цепочке DNS).
Как проверить значение TTL для записи DNS в Unix/Linux/Mac?
Значение TTL обведено красным цветом.
Как проверить запись DNS через Интернет?
Значение TTL обведено красным цветом.
Как убедиться в распространении TTL для записи DNS?
Если вам необходимо выяснить, обновлены ли на конкретном сервере DNS параметры записи DNS, то в любом инструменте DNS (dig, nslookup и т. д.) вместо локальной настройки по умолчанию можно выбрать сервер DNS, на котором будет выполнен запрос.
ДАЛЬНЕЙШИЕ ДЕЙСТВИЯ ПО НАСТРОЙКЕ TTL ДЛЯ ЗАПИСЕЙ DNS
Настройка TTL для записей DNS может оказаться непростой задачей, но при выборе небольших значений (меньше одного часа) вы сможете сохранить работоспособность сети и лучше подготовить ее к внедрению изменений.
Если вам понравилась эта статья, я рекомендую также ознакомиться с нашим курсом, посвященным основам веб-безопасности. Это поможет вам лучше защитить сайт или приложение, для которого вы только что настроили запись DNS. Курс бесплатный и очень информативный.
Hamachi «превышен интервал ожидания для запроса» – что делать? Такой вопрос возникает у пользователей, которые пытаются подключиться к локальной сети или создать свой собственный сервер. Как правило, подобная ошибка связана с неправильными настройками сетевого подключения. Также возможно, что соединение блокирует встроенный в Windows антивирус, поэтому программу необходимо добавить в список исключений. О том, как устранить возникший сбой и не столкнуться с ним вновь, подробно рассказываем дальше.
openvpn
Подскажите где может быть ошибка
192.168.21.2 это рабочая комп за натом в офисе и до него надо достучаться клиенту через удаленный рабочий стол.
openvpn поднят.
Пинг с сервака 10.20.30.1 до клиента 10.20.30.6
проходит.
Обратно то же.
Но достучаться до 192.168.21.2 по тунелю немогу.
Делаю пинг у клиента
C:\Documents and Settings\Серж>ping 192.168.21.2
Обмен пакетами с 192.168.21.2 по 32 байт:
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Ответ от 10.20.30.6: Превышен срок жизни (TTL) при передаче пакета.
Статистика Ping для 192.168.21.2:
Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек
C:\Documents and Settings\Серж>
C:\Documents and Settings\Серж>tracert -d 192.168.21.2
Трассировка маршрута к 192.168.21.2 с максимальным числом прыжков 30
1 8 ms 8 ms 13 ms 10.20.30.6
2 134 ms 17 ms 17 ms 10.20.30.6
3 25 ms 24 ms 24 ms 10.20.30.6
4 36 ms 37 ms 35 ms 10.20.30.6
5 43 ms 45 ms 40 ms 10.20.30.6
6 50 ms 48 ms 50 ms 10.20.30.6
7 63 ms 59 ms 63 ms 10.20.30.6
8 636 ms 73 ms 76 ms 10.20.30.6
9 88 ms 76 ms 680 ms 10.20.30.6
10 109 ms 93 ms 199 ms 10.20.30.6
C:\Documents and Settings\Серж>route print 192.168.21.2
===========================================================================
Список интерфейсов
0x1 . MS TCP Loopback interface
0x2 . 00 1c 23 a1 33 8c . ASUS NX1101 Gigabit Ethernet Adapter - ?шэшяюЁЄ
яырэшЁют?шър яръхЄют
0x3 . 00 13 20 8c ae 4f . Intel(R) PRO/100 VE Network Connection - ?шэшяюЁ
Є яырэшЁют?шър яръхЄют
0x4 . 00 ff 2e 25 6a c3 . TAP-Win32 Adapter V8 - ?шэшяюЁЄ яырэшЁют?шър яръ
хЄют
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
192.168.21.2 255.255.255.255 10.20.30.5 10.20.30.6 1
Основной шлюз: 10.44.30.1
10.44.30.1 Это шлюз провайдера клиента. (сидящего дома)
"Гента вообще форкLFS в свою очередь мутант Скалвари
которая BSD с ядром Линя BSD - мутировал-AT&T UNIX
а там был UNICS - MULTICS, счёты, глиняные таблички, палочки,
большой взрыв, сингулярность, пиз. ц. Вывод: RedHat использует пиз..ц. "
Есть керио на одном физическом порту LAN настроен ip 192.168.1.252/24, а так же дополнительный адрес 10.11.0.1/16. DHCP выдаёт ip адреса из сети 192.168.1.0/24.
Есть компьютер, который получил адрес по DHCP.
С компьютера отлично пингуется шлюз 192.168.1.252 и другой комп 10.11.0.2. Потерь нет, задержка 1мс.
А вот если выполнять команду tracert начинаются чудеса.
так же при выполнении пинга
Вот меня мучает вопрос: что-тут вообще может происходить?
Оценить 1 комментарий
А как вы хотите с TTL=1 дойти до хоста за шлюзом? Шлюз декрементит TTL до 0 и дальше пакет не пойдёт т.к. время его жизни истекло. TTL определяет максимальное количество хостов МЕЖДУ source и destination хостами.
По поводу потерь пакетов в трассировке смотрите политики/логи на шлюзе, возможно просто кабель плохо обжат, или коннектор не до конца воткнут, а может аппаратная/программная проблема оборудования (как компьютера, так и шлюза).
ну так это логично.
-i 1 знаете за что отвечает? время жизни пакета TTL (Time to live)
так же почитайте тут
Я этот параметр не просто так вводил, а для локализации проблемы.
При истечении времени жизни, узел должен ответить "Превышен срок жизни (TTL) при передаче пакета.", , а он в 39% случаев не отвечает.
Читайте пожалуйста внимательнее вопрос.
Проблема, наверное, не в ТТЛ.
Возможно ваш керио чем-то сильно занят, из-за чего не успевает обрабатывать пакеты.
А может он таким образом борется с DOS атаками по ICMP. Посмотрите настройки керио в этом направлении.
Еще для тестирования попробуйте так:
ping 192.168.0.252 -t
Думаю, что провалы в пинге начнут и тут проявляться.
Если в остальном производительность устраивает, то можно забить.
"Еще для тестирования попробуйте так:
ping 192.168.0.252 -t"
неа. в вопросе описал, что в этом случае ни потер, ни задержек нет
Если бы керио был бы занят и дропал пакеты, то эти признаки были бы и в других ситуациях.
"А может он таким образом борется с DOS атаками по ICMP. Посмотрите настройки керио в этом направлении." самое разумное объяснение, но в логах атак про это ни слова. да и странный какой-то способ блокировки. через раз
LAG_LAGbI4: В вопросе вы написали, имея ввиду обычный пинг, я же добавил в команде ключ -t - бесконечный пинг до прерывания. Имел ввиду, что, скорее всего, через какое-то количество пингов или время начнут появляться потери.
Если это борьба с DOS атаками, то обычно должны быть опции для настройки поведения и для теста можно отключить это. Потом вернуть на место.
На счет странного способа - по моему способ нормальный. Вы бы как боролись с DOS атаками? Думаю тут не через раз, а например что-нибудь типа "блокировка аналогичных пакетов на какой-нибудь не большой промежуток времени", если начинают заваливать пакетами, то промежуток времени увеличивается.
Задав соответствующий вопрос в Twitter, мы выяснили, что некоторые системные администраторы даже не могут расшифровать аббревиатуру TTL (хотя такие, к счастью, в меньшинстве).
Отгадайте загадку! Что означает аббревиатура TTL, когда речь идет о системе DNS?
18:43 26 окт. 2016 г.
4 % Граница терминальной передачи
85 % Время жизни
8 % Телеметрическая транспортная линия
3 % Список доверенных технологий
26 голосов • Окончательный результат
Ретвит 1 Отметка «Нравится» 1
Чтобы внести ясность, мы рассмотрим следующие темы.
1. Общие сведения о системе DNS и параметре TTL
2. Устранение проблем с TTL в записях DNS
3. Рекомендации по управлению изменениями в записях DNS
4. Инструменты DNS
5. Дальнейшие действия
1. ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ DNS
Что такое запись DNS?
Запись сервера доменных имен (Domain Name Server, DNS) содержит два важных параметра:
адресацию (установку соответствия) запросов для той или иной записи;
время актуальности записи при кэшировании — именно это значение получило зловещее название «время жизни» (TTL).
Зачем кэшируются записи DNS?
Многие организации настраивают записи DNS один раз и после этого годами не изменяют их. Поскольку записи DNS часто запрашиваются, но редко обновляются, их кэширование помогает значительно повысить производительность сети, увеличивая при этом сложность оценки и устранения проблем с DNS.
Что такое TTL?
Время жизни (TTL) представляет собой продолжительность кэширования записи *каждым звеном* цепочки установки соответствий DNS. Это значение измеряется в секундах (важность этого будет объяснена ниже).
К сожалению, общепринятый термин «время жизни» нельзя назвать исчерпывающим. Возможно, более логичным было бы название «время на поиск» или «продолжительность хранения записи DNS в кэше».
Каково стандартное значение TTL для записей DNS?
Значение TTL всегда выражается в секундах. Большинство служб настройки конфигурации DNS содержат готовый список значений для записей.
300 секунд = 5 минут = «Очень короткое»
3600 секунд = 1 час = «Короткое»
86 400 секунд = 24 часа = «Длинное»
604 800 секунд = 7 дней = «Абсолютный максимум»
Как осуществляется поиск DNS?
Когда вы вводите в браузере какой-либо URL-адрес, создается целая серия поисков.
На каждом этапе этого процесса (часто этапов бывает больше, чем перечислено) задаются следующие вопросы.
1. Кэширована ли нужная запись?
2. Если да, действительно ли ее значение TTL?
Если на какой-либо из этих вопросов получен ответ «Нет», запрос перемещается на следующее звено цепочки.
Почему в основе системы DNS лежат сетевые подключения, а не устройства?
Устранение проблем с DNS представляет собой непростую задачу не только из-за ряда сложностей, связанных с использованием TTL и системы кэширования, но и потому, что подключение многих современных устройств осуществляется через различные сети и цепочки серверов DNS.
Рассмотрим ситуацию на примере обычного ноутбука. Я, как правило, работаю на ноутбуке дома. Несмотря на то что я уже несколько недель никуда его не брал, за это время на устройстве устанавливались следующие подключения:
• к основной домашней сети Wi-Fi/кабельной сети;
• к мобильному телефону при недоступности кабельной сети;
• оба варианта выше, но с подключением через VPN.
При каждой смене сети активируется новая цепочка DNS. Если это происходит в момент внесения изменений, серверы и узлы кэширования в цепочке DNS могут предоставлять неверные данные.
Сразу же начнется паника: «Веб-сервер не работает!», «Это конец света!», «Где мои брюки?». Но, приступив к устранению проблемы, вы обнаружите, что ее причиной стало незакрытое подключение через VPN.
2. УСТРАНЕНИЕ ПРОБЛЕМ С TTL В ЗАПИСЯХ DNS
Сколько времени требуется на обновление записи DNS?
Для расчета максимального (худший случай) временного интервала, необходимого на обновление значения записи DNS в ссылках для всех клиентов, умножьте число звеньев цепочки (без учета полномочного сервера) на значение TTL.
Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).
Но если бы все было так просто.
Каковы затраты на поиск DNS?
Когда речь заходит о «затратах» на поиск DNS, обычно имеются в виду не денежные, а временные затраты. В зависимости от численности интернет-гремлинов в глобальной сети на выполнение запроса DNS обычно уходит 100–200 миллисекунд.
Это очень небольшое время, но представьте себе веб-страницу. Соответствие между именем и IP-адресом в системе DNS необходимо настроить для всех изображений, файлов CSS и файлов активов JavaScript, доступных по ссылкам на странице. Без кэширования время загрузки заметно увеличится.
Упрощенная схема расчета затрат на поиск DNS
Я назвал эту схему упрощенной, поскольку маловероятно, что все активы на вашем веб-сайте находятся в разных доменах. Кроме того, в браузеры встраивается множество различных средств кэширования, которые обеспечивают более быструю загрузку содержимого, чем показано в моей схеме.
(30 файлов изображений x 50 мс на загрузку каждого файла) + (100 мс на выполнение одного поиска DNS с последующим кэшированием) = 1600 мс
(30 файлов изображений x 50 мс на загрузку каждого файла) + (30 x 100 мс на каждый поиск DNS) = 3000 мс
Почему мои записи DNS не обновляются?
Существуют и другие факторы, увеличивающие время распространения изменений. Некоторые из них перечислены ниже.
• Веб-браузеры самостоятельно кэшируют записи DNS и хранят их в течение некоторого времени без учета TTL, что якобы повышает скорость их работы. Например, современные версии Internet Explorer по умолчанию кэшируют записи DNS на 30 минут (до версии IE 4 это время составляло 24 часа) и игнорируют более низкие значения TTL.
• Поставщики мобильного Интернета могут пытаться уменьшить общий объем передаваемого трафика путем увеличения времени TTL, что снижает частоту запросов.
• Сложные внутренние сети с большим числом сервером DNS, чем предполагалось, обновляются дольше по очевидным причинам.
Именно поэтому во многих службах можно встретить следующее заявление: «Полное распространение изменений в записях DNS может занять несколько дней, поэтому планируйте свои действия соответствующим образом».
Можно ли как-нибудь принудить клиент удаленно обновить запись DNS?
Этот вопрос обычно задается в следующем контексте: «После обновления записей DNS клиент не может получить доступ к некоторым сайтам. Как выполнить обновление принудительно?»
К сожалению, единственный ответ на этот вопрос: «Никак». В системе DNS нет команды, позволяющей принудительно выполнить раннее обновление данных для клиентов более низкого уровня.
Можно использовать команды для удаления записей DNS из локального кэша, но обычно они работают не так эффективно, как хотелось бы, из-за наличия как восходящих (кэширование записей DNS на стороне поставщика Интернета), так и нисходящих (кэширование записей DNS в браузере) каналов.
Лучше всего изменить значения TTL в своих записях заблаговременно.
3. РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ В ЗАПИСЯХ DNS
Какие значения TTL лучше: маленькие или большие?
Разработчики уже давно ведут священную войну по поводу того, как нужно оформлять отступы в коде: с помощью знаков табуляции или пробелов. Я выяснил, что сетевые администраторы испытывают примерно те же чувства, когда дело касается длительности TTL.
Обычно это мнение подкрепляется их собственным опытом по отражению предыдущих сетевых атак и устранению проблем с конфигурацией сети.
Атака DDOS, способная на 12 часов остановить работу корневых серверов DNS или аналогичных серверов поставщика Интернета, меньше скажется на сайтах с очень высоким значением TTL. В таких случаях клиенты будут работать даже при выключении или перегрузке сервера DNS.
Однако, если при переключении узлов Интернета или электронной почты вы случайно сделаете ошибку, 12 часов без какой-либо возможности устранить ее — это последнее, что вам будет нужно. Именно поэтому некоторые администраторы считают, что время жизни не должно превышать 1 минуты.
Лично я стараюсь указывать для записей DNS малое значение TTL (меньше 1 часа/3600 секунд).
Как узнать, когда клиент запросит обновленную запись DNS?
Определить, когда все клиенты обновят данные, очень сложно.
Время жизни — это *не* срок годности. Не стоит сравнивать значение TTL в записи DNS с рекомендуемой датой употребления, указанной, например, на несвежем хлебе: это не определенное время, при наступлении которого запись станет недействительной и потребует замены.
Запись DNS — это, скорее, штатное расписание, изменения в котором медленно распространяются по всей сети. Когда у клиентов, расположенных в расписании «ниже», истекает срок действия кэша, они запрашивают запись у сервера DNS более высокого уровня.
Как лучше всего изменять записи DNS?
Создание «плана» или «стратегии» для выполнения относительно простых задач, к которым относится изменение одной записи в домене, может казаться перегибом, но, учитывая колоссальное влияние сбоев DNS на доступность ваших данных, определенную осторожность проявить все же стоит. Как говорится в старой пословице: «Предотвратить легче, чем лечить».
Есть простой способ свести ошибки к минимуму: никогда не обновляйте запись DNS и значение TTL для этой записи одновременно. В идеале у вас должен быть реализован следующий процесс.
1. За несколько дней до переключения укажите для параметра TTL записи DNS низкое значение, например 300 секунд.
2. Установите для записи дату переключения.
3. Через несколько дней после переключения задайте более высокое значение TTL.
Как лучше всего добавлять новые записи DNS?
Добавить новую запись проще, чем изменить существующую.
1. Добавьте запись с низким значением TTL.
2. Проверьте, все ли работает, и увеличьте значение TTL.
Какое значение TTL наиболее распространено?
Мнения относительно *правильного* значения TTL настолько расходятся, что мы предприняли попытку определить его на основе статистики. Список из 500 самых важных веб-сайтов по версии Moz показался нам отличным срезом Интернета. Кроме того, на этом ресурсе был доступен готовый файл CSV с перечнем сайтов, вошедших в итоговый список.
Я написал небольшой сценарий для выполнения итерации по списку и поиска текущего значения TTL для основной записи в каждом домене. Как и в любом проекте по анализу данных, эти данные будут сильно варьироваться в зависимости от постановки вопроса. Пример не всеобъемлющий, в нем представлены текущие (кэшированные) результаты и т. д. и т. п. Невзирая на все эти оговорки, полученные результаты все же имеют определенную ценность.
Анализ значений TTL для 500 важнейших интернет-доменов по версии Moz
Минимальное значение TTL: 1
Максимальное значение TTL: 129 540
Домены с установленным соответствием: 485
Среднее арифметическое значение TTL: 6468
Медианное значение TTL: 300
При необходимости обосновать свое решение об установке низкого (в пределах 1 часа, 3600 секунд) значения TTL вы можете предоставить медианное значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирическое доказательство правильности своего выбора.
4. ИНСТРУМЕНТЫ ПЛАТФОРМЫ DNS
Как проверить значение TTL для записи DNS в Windows?
Значение TTL указывается в нижней части выходных данных. Фраза Non-authoritative answer (Не заслуживающий доверия ответ) указывает на значение TTL, полученное от клиента (2 минуты 11 секунд до проверки локальным клиентом следующего уровня в цепочке DNS).
Как проверить значение TTL для записи DNS в Unix/Linux/Mac?
Значение TTL обведено красным цветом.
Как проверить запись DNS через Интернет?
Значение TTL обведено красным цветом.
Как убедиться в распространении TTL для записи DNS?
Если вам необходимо выяснить, обновлены ли на конкретном сервере DNS параметры записи DNS, то в любом инструменте DNS (dig, nslookup и т. д.) вместо локальной настройки по умолчанию можно выбрать сервер DNS, на котором будет выполнен запрос.
ДАЛЬНЕЙШИЕ ДЕЙСТВИЯ ПО НАСТРОЙКЕ TTL ДЛЯ ЗАПИСЕЙ DNS
Настройка TTL для записей DNS может оказаться непростой задачей, но при выборе небольших значений (меньше одного часа) вы сможете сохранить работоспособность сети и лучше подготовить ее к внедрению изменений.
Если вам понравилась эта статья, я рекомендую также ознакомиться с нашим курсом, посвященным основам веб-безопасности. Это поможет вам лучше защитить сайт или приложение, для которого вы только что настроили запись DNS. Курс бесплатный и очень информативный.
Hamachi «превышен интервал ожидания для запроса» – что делать? Такой вопрос возникает у пользователей, которые пытаются подключиться к локальной сети или создать свой собственный сервер. Как правило, подобная ошибка связана с неправильными настройками сетевого подключения. Также возможно, что соединение блокирует встроенный в Windows антивирус, поэтому программу необходимо добавить в список исключений. О том, как устранить возникший сбой и не столкнуться с ним вновь, подробно рассказываем дальше.
Читайте также: