Top-office11.ru

IT и мир ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Время аренды в роутере что это

Изменение времени аренды IP-адреса

IP-адрес назначается компьютеру от DHCP-сервера интернет-центра не на постоянное пользование, а на определенный срок. Это называется арендой (lease time) IP-адреса. По истечении срока аренды IP-адрес вновь считается свободным, и клиент должен запросить новый (он, впрочем, может оказаться тем же самым).

В KeeneticOS, начиная с версии 2.10, по умолчанию для домашней и гостевой сети время аренды IP-адреса DHCP Lease установлено 25200 сек (7 часов). Именно столько выделено времени для аренды IP-адреса. На более ранних версиях микропрограммы это значение составляло 300 секунд (5 минут).

Когда пройдет 50% времени от срока аренды, клиент выполнит попытку возобновить аренду или обновить (renew) информацию об IP-адресе.

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

Далее приведем пример самостоятельной установки срока аренды IP-адреса и его обновления, назначаемого автоматически DHCP-сервером интернет-центра серии Keenetic.

Например, установим время аренды IP-адреса для основной домашней сети, равное 60 секундам (мы специально в нашем примере установили такое маленькое время, чтобы показать, как работает механизм аренды IP-адреса). Как правило, рекомендуемый срок аренды IP-адреса составляет 48 часов (172800 секунд) для обновления IP-адреса раз в сутки.

После применения указанных параметров клиенты будут получать IP-адрес сроком на 1 минуту, после чего будут посылать на DHCP-сервер запрос о получении нового IP-адреса каждые 30 секунд. Чтобы обновить таймер срока аренды IP-адреса отключите и затем включите сетевой адаптер (или просто отключите Ethernet-кабель от компьютера на несколько секунд и затем заново его подключите).

Данный механизм хорошо виден по дампу сетевых пакетов, собранных на стороне DHCP-клиента. Из нашего дампа видно, что через 30 секунд происходит запрос на обновление IP-адреса.

Также время аренды IP-адреса можно установить с помощью специальной команды через интерфейс командной строки (CLI) интернет-центра:

где xxx – время в секундах. Максимальное значение аренды IP-адреса в KeeneticOS составляет 259200 секунд (72 часа, 3 суток).

Для сохранения настройки в энергонезависимой памяти интернет-центра необходимо выполнить команду

Пользователи, считающие этот материал полезным: 35 из 43

Как связаны длительность аренды DHCP и процесс сбора мусора в DNS

В качестве предисловия. При общении с коллегами, отвечая на их вопросы о совместной настройке DNS и DHCP, часто отсылаю их к замечательной статье Шона Айви на Technet. К сожалению, аналогичного материала на русском языке я не находил. В очередной раз, устно переведя её знакомому, я решил оформить письменный перевод, чтобы иметь возможность отсылать к нему.

Привет всем, меня зовут Шон Айви и я US PFE (Premier Field Engineer). Моя специализация — операционная система Windows и службы Active Directory. Проще говоря, я специализируюсь на Active Directory и связанных с ней сетевых службах. Недавно, у трёх разных клиентов, я помогал SCCM-администраторам, у которых была проблема с установкой SCCM агента. В логе ccm.log значилась ошибка Failed to get token for current process (5). Мы обнаружили, что проблема была не в SCCM, а во взаимодействии DNS и DHCP. Как оказалось, другие службы тоже испытывали связанные с этим проблемы, просто либо демонстрировали иные симптомы, либо не демонстрировали их совсем. Давайте поговорим о том почему так получалось и как это можно предотвратить!

Рассмотрим следующий сценарий:

  • В DHCP настроена область IP адресов, со сроком аренды 8 дней
  • В области DHCP осталось мало свободных IP адресов
  • Клиент А не обновлял аренду своего адреса 8 дней и она истекла
  • Клиент Б запрашивает новый IP адрес
  • DHCP сервер отдаёт Клиенту Б адрес, которым раньше пользовался Клиент А

Пока всё хорошо. Это довольно типовой сценарий работы DHCP сервера и всё происходит именно так, как мы ожидаем. Давайте теперь добавим сюда DNS сервер.

  • Интегрированная с Active Directory зона DNS с настроенной очисткой зоны
  • Настройки очитски по умолчанию: “Интервал блокирования = 7 дней” и “Интервал обновления = 7 дней”
  • Настройки сервера также по умолчанию: “Период очистки = 7 дней”
  • Клиент А обновил DNS запись 8 дней назад (в тот самый день, когда получил свой адрес)
  • Клиент А является владельцем своей DNS записи и она не может быть удалена DHCP сервером (при настройках по умолчанию)
  • Клиент Б пытается зарегистрировать DNS запись с новым адресом, который он получил от DHCP сервера
  • Это тот же самый IP адрес, который использовал Клиент А!
  • DNS сервер не сможет вычистить старую запись Клиента А еще 6 дней!

(Если, вдруг, вы не знаете, что такое “очистка зоны”, “интервал блокирования/обновления”, то рекомендую вам почитать блог моего коллеги. Он шикарен! Примечание: раз вы читаете перевод оригинальной статьи, то, возможно, вам проще будет ознакомиться с русскоязычным материалом)
Вот теперь всё уже не так хорошо. Такое случается гораздо чаще, чем вы можете подумать. Теперь у Клиентов А и Б DNS записи ссылаются на одинаковый IP адрес.

Читать еще:  Как поменять общедоступную сеть на частную


Рисунок 1

Итак, у нас в DNS есть два разных имени, ссылающихся на одинаковый IP адрес. И, скорее всего, всё именно так и останется еще минимум 6 дней, пока не истекут описанные выше интервалы. Какие проблемы это может вызвать? Давайте посмотрим.

Проблема

Я уже упомянул, что симптомом этой ситуации была проблема с установкой SCCM клиента, но, на самом деле, мы можем использовать для демонстрации более простой пример — доступ к общей папке. Принцип один и тот же.

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


Рисунок 2

А вот это уже интересно. Во первых, клиент А даже не включен… но мы получаем ответ от его имени. И это ошибка аутентификации! Некоторые из вас уже догадались, что это происходит, когда вы посылаете сеансовый ключ Kerberos предназначенный для одного компьютера другому, но давайте по порядку.

Мы видим, что наш компьютер (Infra-App1) посылает в DNS запрос на имя client-a.corp.contoso.com. В ответ он получает IP адрес 10.0.0.100.


Рисунок 3

Насколько знает DNS, так оно и есть. Клиент А действительно имеет адрес 10.0.0.100, но точно такой же адрес имеет Клиент Б.

Отлично, теперь мы получаем сеансовый ключ Kerberos. Вот только DNS запрос был на имя Клиента А, так что ответ от службы Kerberos также будет на имя клиента А.


Рисунок 4

Рисунок 5

Мы видим запрос на Рисунке 4 и ответ контроллера домена на Рисунке 5.

Теперь, получив ключ, мы можем попытаться подключиться, к тому, что мы считаем Клиентом А.


Рисунок 6

Здесь мы видим сеансовый ключ Kerberos.

И, наконец, мы видим сообщение об ошибке от Клиента А. Почему? Потому, что клиент А это не Клиент А, а Клиент Б.


Рисунок 7

Всё это только подтверждает то, что вы, вероятно, и так знали. Для того чтобы Kerberos отработал нормально, вы должны обратиться с правильным сеансовым ключом к правильному адресату (Если вы хотите узнать больше о Kerberos, почитайте блог Роба Грина «Kerberos для занятых админов» Примечание: аналогичного материала на русском я не нашёл, но с общими сведениями можно ознакомиться вот здесь).

Конечно, всё отлично сработает, если вместо FQDN имени мы обратимся по IP адресу. Почему? Потому, что в этому случае вместо Kerberos будет использована аутентификация NTLM. Используя IP адрес, мы не делаем никаких предположений о том, к какому клиенту мы подключаемся. Мы просто подключаемся по определённому IP адресу. Некоторые из вас могут подумать, что и для FQDN должно сработать. В конце концов, получив ошибку при использовании Kerberos, мы должны переключиться на NTLM, верно? Не совсем. Я не буду углубляться в детали, но мы переключимся на NTLM, только если мы не смогли договориться об использовании Kerberos. Вы можете прочитать об этом подробнее здесь. В любом случае, Kerberos не возвращал нам ошибки, он штатно ответил нам сеансовым ключом.

Как предотвратить

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

Примечание: я рекомендую уменьшить интервал очистки для каждого из этих способов до 1-3 дней. Интервал в 7 дней, используемый по умолчанию, позволяет проблемным записям оставаться в DNS чересчур долго.

    Увеличить длительность аренды DHCP, чтобы она соответствовала сумме интервалов обновления и блокирования. В нашем примере, мы увеличим его до 14 дней.

Преимущества:

  1. К тому времени, как DHCP сможет выдать адрес новому клиенту, DNS запись старого уже может быть удалена
  2. Простота реализации

Недостатки:

  1. Если у вас уже осталось мало свободных IP адресов в DHCP, то они могут просто закончится
  2. Момент очистки зоны не обязательно совпадёт с моментом истечение интервалов обновления и блокирования (а значит и времени аренды DHCP) и мы на небольшой промежуток времени можем получить ситуацию описанную выше. Чтобы уменьшить число таких проблем мы можем уменьшить интервал очистки до 1 дня.

  • Уменьшить интервалы обновления и блокирования, чтобы их сумма совпадала с длительностью аренды DHCP. В нашем примере, мы сократим оба интервала до 4 дней.

    Преимущества:

    1. Существующая DNS запись будет очищена раньше. По сути, результат будет аналогичен предыдущему варианту
    2. Простота реализации

    Недостатки:

    1. Несколько увеличиться нагрузка на Active Directory репликацию (если, конечно, это Active Directory интегрированная зона). Это вызвано тем, что клиенты будут чаще обновлять свои DNS записи (в нашем случае, каждые 4 дня вместо 7)
    2. Момент очистки зоны не обязательно совпадёт с моментом истечение интервалов обновления и блокирования (а значит и времени аренды DHCP) и мы на небольшой промежуток времени можем получить ситуацию описанную выше. Чтобы уменьшить число таких проблем мы можем уменьшить интервал очистки до 1 дня.
    Читать еще:  Спакес крупнейшая мобильная сеть

  • Настроить DHCP сервер, чтобы он регистрировал DNS записи от имени клиентов (почитать как это настроить можно здесьПримечание: а на русском, здесь)

    Преимущества:

    1. DHCP сервер будет удалять записи в DNS сразу по истечении аренды IP адреса
    2. При правильной настройке у вас никогда не появится таких проблемных записей

    Недостатки:

    1. Более сложная настройка требует вовлечения более квалифицированного персонала
    2. Настройка дополнительно усложняется тем, что потребуется сервисная учётная запись, от имени которой будут работать DHCP сервера или все DHCP сервера нужно будет добавить в группу DNSUpdateProxy (менее безопасный вариант)

  • Попробуйте поэкспериментировать с интервалами обновления и блокирования и длительностью аренды DHCP. Вы можете обнаружить, что изменение интервалов по умолчанию благотворно сказывается на работе ваших сетевых служб. Короткий срок аренды DHCP часто используются для беспроводных сетей. В то же время, не забывайте о дополнительной нагрузке, которую вы возлагаете на сервер, особенно если вы настраиваете частую (раз в несколько часов) очистку для очень большой DNS зоны.

    Поиск DNS записей с одинаковыми IP адресами

    Почти всё! Теперь мы понимаем, почему происходит такая ситуация, когда возникает проблема и как её предотвратить. Но как нам легко и быстро найти такие записи, если беда уже случилась? Вы можете легко найти такие парные записи в DNS используя несложный PowerShell скрипт (это, конечно же, не единственный способ).

    Ниже приведён образец вывода этого скрипта:


    Рисунок 8

    Скрипт очень простой. Рассматривайте его только как пример. Он вернёт дублированные IP адреса зарегистрированные для компьютерных учётных записей в Active Directory. Помните, что он запросит все компьютерные объекты из Active Directory домена и проверит в DNS IP адрес каждого из них. Если у вас много компьютеров, то используйте ключ -searchbase вместе с командой get-adcomputer, чтобы ограничить количество опрашиваемых каждый раз объектов. Если ваш компьютер не включен в Active Directory домен, то вы не сможете найти его командой get-adcomputer. Мой скрипт специально заточен на то, чтобы получить дублированные записи DNS для сценария, который я описал выше.

    Заключение

    Есть очень много статей о настройке интеграции DHCP и DNS. Цель этой — обобщить сведения о том, как эти две службы работает вместе, чтобы вам было проще это понять. Подведём итог:

    • Длительность аренды адреса в DHCP и интервалы обновления и блокирования по умолчанию = устаревшие DNS записи

  • Симптомы

    • SCCM: “Failed to get token for current process (5)”
    • Общие папки: “Logon Failure: The target account name is incorrect”
    • Любые другие службы использующие Kerberos также могут выдавать различные ошибки

  • Проблема

    • Корректная работа Kerberos требует, чтобы сеансовый ключ был выдан именно для того компьютера, с которым мы пытаемся установить соединение. Устаревшие DNS записи могут приводить к ситуациям, когда мы будем обращаться к одному компьютеру с ключом для другого

  • Решение

    • Изменение интервалов обновления и блокирования и/или длительности аренды DHCP
    • Настройка DHCP, чтобы сервер регистрировал DNS записи от имени клиентов
    • Поиск и удаление дублированных записей

  • Надеюсь, что статья была вам полезна! Правильная настройка интеграции DNS и DHCP избавит вас от такого рода проблем в вашей сети!

    Проблема с интернетом.

    Приветствую. В общем с недавнего времени интернет стал отключаться на 3-5 сек, после чего все становится нормально ровно на 10 минут. Время отключения полностью совпадает со временем в графе «Аренда истекает». В билайн звонил уже дважды, их советы действуют примерно день, а потом по новой. Знающие люди помогайте плз.

    Дубликаты не найдены

    Маленький совет. Звонишь в КЦ, ждёшь ответа оператора.

    Задаёшь вопрос «Девушка/молодой человек, что мне нужно что бы расторгнуть договор с вами?»

    Тебя переключают на другой отдел где специально обученный сотрудник будет всеми силами стараться что бы ты не свалил 🙂

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

    Мне помогло, да и техпод до сих пор относится гораздо внимательнее))

    2 чая этому господину

    Не во всех регионах такое прокатит. У билайна основной доход не с ШПД, чтобы он сильно держался за физиков. Тут все зависит от менеджера — на сколько сильно он хочет премию.

    А что провайдер сказал?

    Мне видится тут что DHCP-сервер выдает IP адрес тебе на 10 минут, после этого выдает этот адрес другому и тут инет и падает.

    Выглядит как проблема на стороне провайдера.

    дхцп так не умеет, если только его специально этому не научить.

    Читать еще:  Роутер работает с перебоями что делать

    Грубо говоря, если он кому то выдал адрес, и этот комп остается в сети, то при повторном обращении, когда часть времени истечет, комп получит тот же адрес.

    Объясни? Не могу сообразить так на вскидку, как можно измудриться так.

    Если б он был настроен таким образом, что б не продлевал аренду текущего адреса, то разрывы(и смена адреса) были бы каждые 5 минут при лизтайме в 10 минут.

    У билайна вроде всё через l2tp или я ошибаюсь ?

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

    Возможно у провайдера дефицит внешних IP адресов и эту проблему они решают коротким сроком аренды и отсутствием запросов на продолжение аренды IP.

    Немного странная проблема у человека.

    10 минут — нормальный лизтайм для сети с кучей динамичных клиентов. При нормальной сети, по сути, лизтайм не влияет ни на что, кроме служебного трафика, так как каждые 5 минут клиент будет пинать дхцп сервер.

    Может у них железка мозг парит какая нито.

    У меня срок аренды 2 минуты, но работает всё стабильно, от линейной аварии до следующей линейной аварии через год. Без потери пакетов и перебоев. пров nbn.

    по идее, dhcp продлевает аренду до того, как она закончится, поэтому и нет у тебя потерь.

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

    хотя АБСОЛЮТНО ничего не качаю, и не хожу по интернету особо.

    Бывший работник «сис-админ» перед увольнением, сделал на сервере авторизации пользователей вашего провайдера, настройку «аренду ip-адресов»

    всего на 10 минут, вместо 1дня, как у всех.

    в итоге все пользователи имеют через 10мин, обрыв интернета.

    что делать? либо достучаться до «их начальства и объяснить ситуацию»

    либо сменить провайдера.

    ЕСЛИ, 10минут аренды ip-адреса, сделано НАМЕРЕННО

    и(!) из-за банальной нехватки ip-адресов в «сегменте» сети провайдера.

    то такая дикость будет «очень долго».

    вариантов тут мало: если есть услуга статический ip-адрес, то подключаешь себе и проблема решена

    вариант второй: сменить провайдера.

    Попробуй отключить DHCP и прописать IP адрес руками, к примеру тот же 128.68.217.125

    Как вариант может и прокатит .

    Тогда начнутся разрывы.

    Не прокатит, так как сначало выдается «технический ip-шник», чтобы можно было поднять L2TP , тогда уже навешивается 128.68.208.0/20. Раньше у них было так, если ничего не поменялось.

    не понимаю зачем, но коммент для минусов.

    Коммент для минусов оставляется в том случае, если автор прости поднять пост в горячее, дабы там его увидело большее количество людей. Чтобы не прослыть кармодрочером и показать исключительно благие намерения — оставляют коммент для минусов. Таким образом и карма автора остается на месте и пост поднимается выше. Это не твой случай.

    Судя по IP, кабель у тебя подключен напрямую к компу. В таком случае срок аренды выдаваемого адрес регулируется непосредственно сервером (в твоем случае, Билайном).

    Звони в тех. поддержку и следуй их инструкциям. Если не хватает знаний и опыта, вызывай их мастера, пускай разбираются.

    Да звонил, они что то там у себя делают и все налаживается, а потом опять.

    Попробуй dns прописать вручную. Например 8.8.8.8

    удали полностью сетевое подключение , либо сам создай либо пускай мастер настроек сетевого подключения сделает всё на автомате, удали приложения билайна почисти реестр, перезагрузи комп, проверь антивир на шмон подключения ! Будет тебе счастье , заодно посмотри настройки брэндмаура )))

    так то все ок было после корбины, а спустя несколько лет началось((

    Срок истечения аренды

    1 дней 5 час. 40 мин. 44 сек.

    Разрывов не было . Иногда аптайм выходил больше месяца.

    [admin@MikroTik] > system resource print

    version: 6.34.2 (stable)

    build-time: Feb/18/2016 06:31:18

    cpu: MIPS 74Kc V4.12

    Здравствуйте! Напишите, пожалуйста, Ваш номер, описание ситуации, точный адрес места, где Вы пользуетесь интернетом, а также время последнего звонка оттуда нам на почту pomogite@beeline.ru. Проверим работу сети.

    Спасибо, уже все ок)

    Вот тебе совет от человека работающего в этой сфере. Да, у билайна L2tp, как ,выше, пытались уточнить, прописать руками этот ip-шник у тебя не получится по этой же причине. Было бы ipoe — тогда никаких проблем. Вероятней всего кто-то накосячил на dhcp (спецом/не спецом — хз), выставив lease time, равное время твоей аренде. Чтобы достучаться до тех.поддержки — ставишь на комп wireshark, включаешь его, вставляешь кабель и сохраняешь весь дамп, до того момента пока не появился инет — открылась первая страница. Дальше разбираешь этот дамп при помощи гугла, если так не поймешь его, нужные строчки выделяешь и на почту в саппорт — они видят, кто дебил, все исправляют.

    Ссылка на основную публикацию
    Adblock
    detector