Заметил в 7-й версии RouterOS на Микротике в настройках DHCP сервера новую кнопку Send Reconfigure. Она находится в списке выданных аренд (Leases). Специально заглянул в старое устройство. Её там не было. Стало интересно, что это такое.
Как оказалось, DHCP сервер может инициировать обновление сетевых настроек. Для этого есть специальное DHCP-сообщение типа FORCERENEW. Вообще не знал и никогда не слышал, что это возможно. И не видел, чтобы кто-то так делал. Я всегда обновлял настройки со стороны клиента. Думал, только он может решать, когда ему это делать. Соответственно, если ты поменял настройки на сервере, то либо ждешь, когда закончится аренда, либо клиентом инициируешь обновление.
На эту тему есть RFC 3203 (DHCP reconfigure extension) аж от 2001 года. То есть это не что-то новое и уникальное. Просто в RouterOS добавили поддержку этой функциональности. Дай, думаю, попробую, как это работает. Выглядит удобно. Поменял IP адрес в аренде и отправил команду на обновление настроек. Но ничего не вышло.
Тут не всё так просто. Для того, чтобы кто попало не рассылал по сети сообщения на обновление настроек, в этот механизм добавлена защита, описанная в RFC 6704 (Forcerenew Nonce Authentication). При получении аренды от сервера, клиент сообщает, что он поддерживает механизм аутентификации. В ответ сервер отправляет ему ключ аутентификации.
В Mikrotik этот ключ можно посмотреть в статусе аренды, на вкладке Active, в поле Reconfigure Key. Если ключа там нет, значит обмена ключами не было, клиент не примет запрос FORCERENEW на смену настроек. Сервер, соответственно, когда отправляет запрос, в заголовок добавляет ключ для аутентификации.
Будет или нет работать команда FORCERENEW зависит опять от клиента. В клиенте того же Mikrotik сделали удобно. Там просто добавили опцию в свойства клиента - Allow Reconfigure Messages. Ставишь галочку и клиент обменивается с сервером ключами.
С другими клиентами сложнее. Стандартный
Стандартный DHCP клиент в Windows тоже не имеет такой поддержки.
В итоге фичу в RouterOS завезли, причём весьма удобную, а на практике применить её негде. Только если в качестве DHCP клиентов у вас выступают те же устройства RouterOS. На практике это не особо и нужно, хотя и может где-то пригодиться.
Вы вообще знали о такой возможности? Не понимаю, почему её не реализовали в популярных клиентах. Удобно же.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mikrotik #network #dhcp
Как оказалось, DHCP сервер может инициировать обновление сетевых настроек. Для этого есть специальное DHCP-сообщение типа FORCERENEW. Вообще не знал и никогда не слышал, что это возможно. И не видел, чтобы кто-то так делал. Я всегда обновлял настройки со стороны клиента. Думал, только он может решать, когда ему это делать. Соответственно, если ты поменял настройки на сервере, то либо ждешь, когда закончится аренда, либо клиентом инициируешь обновление.
На эту тему есть RFC 3203 (DHCP reconfigure extension) аж от 2001 года. То есть это не что-то новое и уникальное. Просто в RouterOS добавили поддержку этой функциональности. Дай, думаю, попробую, как это работает. Выглядит удобно. Поменял IP адрес в аренде и отправил команду на обновление настроек. Но ничего не вышло.
Тут не всё так просто. Для того, чтобы кто попало не рассылал по сети сообщения на обновление настроек, в этот механизм добавлена защита, описанная в RFC 6704 (Forcerenew Nonce Authentication). При получении аренды от сервера, клиент сообщает, что он поддерживает механизм аутентификации. В ответ сервер отправляет ему ключ аутентификации.
В Mikrotik этот ключ можно посмотреть в статусе аренды, на вкладке Active, в поле Reconfigure Key. Если ключа там нет, значит обмена ключами не было, клиент не примет запрос FORCERENEW на смену настроек. Сервер, соответственно, когда отправляет запрос, в заголовок добавляет ключ для аутентификации.
Будет или нет работать команда FORCERENEW зависит опять от клиента. В клиенте того же Mikrotik сделали удобно. Там просто добавили опцию в свойства клиента - Allow Reconfigure Messages. Ставишь галочку и клиент обменивается с сервером ключами.
С другими клиентами сложнее. Стандартный
dhclient в Linux по умолчанию не поддерживает реализацию RFC 3203 и RFC 6704. Нужно брать какой-то другой. Например, цисковский поддерживает, но я не знаю, можно ли его запустить в Linux. Не изучал этот вопрос.Стандартный DHCP клиент в Windows тоже не имеет такой поддержки.
В итоге фичу в RouterOS завезли, причём весьма удобную, а на практике применить её негде. Только если в качестве DHCP клиентов у вас выступают те же устройства RouterOS. На практике это не особо и нужно, хотя и может где-то пригодиться.
Вы вообще знали о такой возможности? Не понимаю, почему её не реализовали в популярных клиентах. Удобно же.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#mikrotik #network #dhcp
👍156👎3
У Mikrotik уже давно вышла версия RouterOS 7. Я не обновил ни одно старое устройство на эту версию. Просто на всякий случай. Пока 6-я ветка поддерживается, и всё работает нормально, не вижу в этом смысла. И как оказалось, не зря.
Домой купил себе новое устройство, а там уже стоит 7-я версия. Выбирать не приходится, поэтому стал пользоваться. И уже несколько раз сталкивался с глюками, которые портят впечатление об устройстве, как о надёжном инструменте, который один раз настроил и забыл. Для меня стало обыденностью перезагрузить устройство, чтобы решить какую-нибудь проблему.
Например, описываемый Kid Control иногда просто глючит. Всё настроено корректно, много дней работает. А потом почему-то в заданный интервал времени разрешающие правила не работают, активны запрещающие. Не помогает отключение и включение настроек. Перезагружаешь Mikrotik - всё работает нормально.
Последней каплей стал недавний глюк, который меня серьёзно напряг, что и побудило написать эту заметку и предупредить тех, кто ещё сидит на 6-й версии. Сидите дальше ☝️.
У меня перестало подключаться основное OpenVPN соединение, которое используется для различных задач. Оно мне нужно постоянно в том числе для работы, а отсутствие создаёт неудобства. В какой-то момент, скорее всего после недавнего обновления, но не сразу после него, соединение перестало устанавливаться без каких-либо изменений настроек со стороны роутера или сервера. У меня есть другие Микротики, которые подключаются туда же и с ними всё в порядке.
Сначала подумал, что провайдер включил какие-то блокировки. Но через этого же провайдера мой ноутбук нормально подключается по OVPN к тому же серверу. Перепроверил раз 10 настройки, сверил с другими роутерами. Всё настроено нормально, как везде и как было раньше тут.
Соединение устанавливается, получает статус connected, но не переходит в running. Со стороны сервера ошибок нет, всё четко. Он пушит настройки и маршруты. Но на роутер не приходят настройки IP адреса и маршруты этого клиента. Случайно заметил, что если включить настройку в OpenVPN интерфейсе Add Default Route, то соединение нормально устанавливается, но мне не нужно автоматом прописывать дефолтный маршрут через OVPN интерфейс. Работало раньше и без этого.
Уже на этом моменте я понял, что тупо что-то глючит. Решение нашёл случайно. В настройках интерфейса есть поле User и Password. Его не обязательно указывать, так как в OpenVPN аутентификация проходит по сертификатам. В данном устройстве пароль не был указан, либо он слетел после недавнего обновления. Тут не могу точно сказать, как было. Я мог от балды его указать, или не делать этого. Но факт в том, что в какой-то момент не меняя настройки я получил неработающее соединение.
После того, как в поле Password написал случайный пароль 123, соединение поднялось и начало работать, как и должно. Налицо явный глюк, который серьёзно напряг, так как догадаться в чём проблема, очень трудно. Никаких подсказок или ошибок нет, конфигурация не менялась. Я просто в какой-то момент для подключенного интерфейса сделал disable, а потом enable, а он не подключился.
Устройство из разряда простого и надёжного перешло в разряд страшно обновить и надо вечером перезагрузить. Дома ещё ладно, я перебился. Есть обходные пути. А если с филиалами связь развалится после кого-нибудь обновления? И не обновляться нельзя, но в то же время и не хочется хапнуть проблем на ровном месте.
Docker контейнеры, если что, тоже глючат. То зависнут, то отвалятся. Я в итоге не пользуюсь. Выводы не делаю, решать вам. Если бы можно было что-то аналогичное купить с такой же функциональность, то можно было бы написать, не используйте Микротики. Но аналогов нет, поэтому добавить нечего.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mikrotik
Домой купил себе новое устройство, а там уже стоит 7-я версия. Выбирать не приходится, поэтому стал пользоваться. И уже несколько раз сталкивался с глюками, которые портят впечатление об устройстве, как о надёжном инструменте, который один раз настроил и забыл. Для меня стало обыденностью перезагрузить устройство, чтобы решить какую-нибудь проблему.
Например, описываемый Kid Control иногда просто глючит. Всё настроено корректно, много дней работает. А потом почему-то в заданный интервал времени разрешающие правила не работают, активны запрещающие. Не помогает отключение и включение настроек. Перезагружаешь Mikrotik - всё работает нормально.
Последней каплей стал недавний глюк, который меня серьёзно напряг, что и побудило написать эту заметку и предупредить тех, кто ещё сидит на 6-й версии. Сидите дальше ☝️.
У меня перестало подключаться основное OpenVPN соединение, которое используется для различных задач. Оно мне нужно постоянно в том числе для работы, а отсутствие создаёт неудобства. В какой-то момент, скорее всего после недавнего обновления, но не сразу после него, соединение перестало устанавливаться без каких-либо изменений настроек со стороны роутера или сервера. У меня есть другие Микротики, которые подключаются туда же и с ними всё в порядке.
Сначала подумал, что провайдер включил какие-то блокировки. Но через этого же провайдера мой ноутбук нормально подключается по OVPN к тому же серверу. Перепроверил раз 10 настройки, сверил с другими роутерами. Всё настроено нормально, как везде и как было раньше тут.
Соединение устанавливается, получает статус connected, но не переходит в running. Со стороны сервера ошибок нет, всё четко. Он пушит настройки и маршруты. Но на роутер не приходят настройки IP адреса и маршруты этого клиента. Случайно заметил, что если включить настройку в OpenVPN интерфейсе Add Default Route, то соединение нормально устанавливается, но мне не нужно автоматом прописывать дефолтный маршрут через OVPN интерфейс. Работало раньше и без этого.
Уже на этом моменте я понял, что тупо что-то глючит. Решение нашёл случайно. В настройках интерфейса есть поле User и Password. Его не обязательно указывать, так как в OpenVPN аутентификация проходит по сертификатам. В данном устройстве пароль не был указан, либо он слетел после недавнего обновления. Тут не могу точно сказать, как было. Я мог от балды его указать, или не делать этого. Но факт в том, что в какой-то момент не меняя настройки я получил неработающее соединение.
После того, как в поле Password написал случайный пароль 123, соединение поднялось и начало работать, как и должно. Налицо явный глюк, который серьёзно напряг, так как догадаться в чём проблема, очень трудно. Никаких подсказок или ошибок нет, конфигурация не менялась. Я просто в какой-то момент для подключенного интерфейса сделал disable, а потом enable, а он не подключился.
Устройство из разряда простого и надёжного перешло в разряд страшно обновить и надо вечером перезагрузить. Дома ещё ладно, я перебился. Есть обходные пути. А если с филиалами связь развалится после кого-нибудь обновления? И не обновляться нельзя, но в то же время и не хочется хапнуть проблем на ровном месте.
Docker контейнеры, если что, тоже глючат. То зависнут, то отвалятся. Я в итоге не пользуюсь. Выводы не делаю, решать вам. Если бы можно было что-то аналогичное купить с такой же функциональность, то можно было бы написать, не используйте Микротики. Но аналогов нет, поэтому добавить нечего.
———
ServerAdmin:
#mikrotik
Please open Telegram to view this post
VIEW IN TELEGRAM
👍100👎23