Как реализовать постоянную смену ip адресов клиентов?

[pubuser]

Подскажите плз по сабжу, не нашел темы решил написать. Как можно заставить клиентов подключенных к микротику, всегда получать новый ip адрес? Например, включаем DHCP сервер на микротике, создаем пул 10.10.10.1 - 10.10.10.255, клиент получает адрес и держит его скажем 20 минут, как настроено время аренды, по истечении 20 минут этот же адрес снова остается у железки и так до бесконечности, а хотелось бы чтобы по истечении срока аренды всегда присваивался следующий адрес из выделенного пула и так по кругу перебирал все адреса. реализуемо это в принципе или нет? Может быть кто то решал подобную проблему с помощью скриптов?

[plin2s]

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

[nurikzaripov]

В локалке менять конечно дикость. Может автор все таки имел ввиду реальные адреса выдаваемые в интернет?

[pubuser]

Проблема проста. Имеются древние voip шлюзы mp202 которые давно обросли бородой и пора им на пенсию. Настроены шлюзы в локалке за микротиком, откуда поднят доступ по впн в другую локалку с sip сервером. Замечен в них глюк - если прервать соединение между локалками, и в момент его отсутствия шлюз попытается переавторизоваться на sip сервере - больше он с тех пор не может достучаться до него, registration error пишет в статусе, когда соединение впн давно уже восстановлено и работает. Сервер из самого шлюза доступен при этом. Смена серого ip адреса шлюза сразу каким то образом решает проблему - шлюз авторизуется на sip сервере. Вот и хотелось что то придумать чтобы руками не менять в таких случаях адрес этого шлюза, чтобы он сам по истечении срока аренды адреса стучался уже с нового ip.

[vqd]

Да все просто, известная проблема )))

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

[plin2s]

Что-то мне подсказывает, что лучше начать с подкручивания настроек шлюза. Напирмер выкрутить всяческие таймауты и ретраи. Например, судя по первому найденному мануалу, есть такой параметр как "maximum number of authentication retries".
Очевидно, что после смены сетевых настроек он пробует заново пройти авторизацию и это у него получается.
Думаю можно начать с установки маленького lease time. 1-2 минуты не так уж и часто, если говорить всего о паре устройств.

[vqd]

Да достаточно микроту запретить при падении тоннеля сливать соединения в main

[pubuser]

Да достаточно микроту запретить при падении тоннеля сливать соединения в main

нельзя ли по подробнее как это реализовать?

Что-то мне подсказывает, что лучше начать с подкручивания настроек шлюза. Напирмер выкрутить всяческие таймауты и ретраи. Например, судя по первому найденному мануалу, есть такой параметр как "maximum number of authentication retries".
Очевидно, что после смены сетевых настроек он пробует заново пройти авторизацию и это у него получается.
Думаю можно начать с установки маленького lease time. 1-2 минуты не так уж и часто, если говорить всего о паре устройств.

Куда интересно еще увеличивать таймауты, по дефолту стоит и так Register Expires на шлюзе в 3600 сек. По иронии судьбы этот срок истекает как раз когда по какой либо причине впн туннель не поднят) А насчет кручения других настроек - там их раз два и обчелся. Единственную нашел вот этот Register Expires а больше никаких таймеров связанных с повторной регистрацией нету. По поводу lease time - ничего не меняется если идет разговор через шлюз, перезапрос ip не вызывает попыток переконекта или обрывов. Хоть 30 сек поставить lease - толку нету, ip остается прежний. Конечно можно бы выкинуть нафиг эти шлюзы и успокоиться но приходится юзать то что есть.

[vqd]

ip - routes - rules

[pubuser]

ip - routes - rules

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