DHCP FORCERENEW в RouterOS позволяет серверу запросить у клиента обновление параметров аренды. В статье разобраны сообщения Reconfigure, команды RouterOS и причины не принимать такие запросы без оценки модели угроз.

Функция появилась в RouterOS 7.19.1. Перед применением проверьте поддержку на клиенте и сервере, а также требования RFC 3203 и RFC 6704 к защите сообщения.

*) dhcpv4-client/server - added support for DHCPv4 reconfigure messages;

Помню, в момент самого релиза формулировка была ещё более загадочной: что-то вроде
*) dhcpv4 - added supported reconfigure
— ни тебе подробностей, ни разъяснений, только ссылка на номер RFC в документации. Всё как в лучших традициях: хочешь разобраться — копай сам.

Попытался я на скорую руку вникнуть, как же работает этот новый функционал, но, признаюсь честно, быстро разобраться не удалось. Однако ребятам пообещал: разберусь и обязательно расскажу. Слово держать надо.

Так что пусть эта статья станет своеобразным закрытием моего технического долга перед всеми, кто проходил у меня обучение на курсе MTCTCE. Надеюсь, теперь мы вместе разберёмся, что же на самом деле скрывается за этим загадочным «reconfigure» в DHCP.

---

Принцип работы

Вся суть этого функционала изложена в лаконичном, но ёмком RFC 3203. Если говорить простыми словами, то теперь DHCP-сервер может инициировать обновление параметров у клиента, не дожидаясь, пока тот сам решит это сделать.

Как это работает

1. Сервер отправляет сообщение FORCERENEW
   Представьте: администратор меняет настройки сети или хочет, чтобы определённый клиент получил новый IP-адрес. Вместо привычного ожидания окончания аренды или ручного вмешательства, сервер отправляет специальное DHCP-сообщение типа FORCERENEW на нужный хост.
2. Клиент получает FORCERENEW и инициирует обновление
   Получив это сообщение, клиент тут же начинает процедуру продления аренды IP-адреса — как если бы он сам решил обновить параметры.
3. Дальнейшие действия по стандарту DHCP
   Если на сервере для этого клиента изменился IP-адрес или другие параметры, сервер может ответить NAK (отказом), и тогда клиент начинает процесс получения адреса заново — с самого начала, как при первом подключении.

Опция DHCP номер 53: новый тип сообщения FORCERENEW

В протоколе DHCP для идентификации типа сообщения используется специальная опция с номером 53 — DHCP Message Type. Именно эта опция сообщает клиенту или серверу, какое действие требуется выполнить: DISCOVER, OFFER, REQUEST, ACK и так далее.

С появлением поддержки RFC 3203 в список стандартных типов сообщений добавился новый — тип 9, который обозначает FORCERENEW.

Это и есть тот самый сигнал клиенту: «Пора обновить параметры!»

Настройки RouterOS для поддержки DHCP FORCERENEW

В MikroTik RouterOS реализована поддержка механизма FORCERENEW, но для его полноценной работы необходимо правильно настроить как сервер, так и клиента. Всего есть три ключевых места, где можно управлять этим функционалом.

1. DHCP-Client: разрешение на приём FORCERENEW

Чтобы устройство на RouterOS могло принимать и корректно реагировать на сообщения FORCERENEW, необходимо явно разрешить эту возможность в настройках DHCP-клиента. Без этого параметра клиент просто проигнорирует подобные запросы.

Пример настройки:

[admin@client.dhcp.vasilevkirill.ru] > /ip/dhcp-client/add allow-reconfigure=yes

• allow-reconfigure=yes — разрешает клиенту принимать и обрабатывать сообщения FORCERENEW.

2. DHCP-Server: поддержка отправки FORCERENEW

На стороне сервера также требуется включить поддержку отправки сообщений FORCERENEW. Это делается при создании или редактировании DHCP-сервера.

Пример настройки:

[admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/add use-reconfigure=yes

• use-reconfigure=yes — разрешает серверу отправлять сообщения FORCERENEW клиентам, которые это поддерживают.

3. Отправка FORCERENEW конкретному клиенту

RouterOS позволяет отправить сообщение FORCERENEW не всем клиентам сразу, а выборочно — конкретному устройству по его lease. Это удобно, если нужно обновить параметры только у одного клиента.

Пример команды:

[admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/send-reconfigure numbers=<lease_number>

• <lease_number> — номер или идентификатор аренды (lease), который можно узнать через /ip/dhcp-server/lease/print.

Пример использования:

[admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/print
# Найдите нужный lease и используйте его номер:
[admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/send-reconfigure numbers=3

Аутентификация по RFC 6704

На первый взгляд всё кажется простым: сервер отправляет FORCERENEW, клиент обновляет параметры — красота! Но тут кроется серьёзная уязвимость: любой, кто находится в одной сети с клиентом, может отправить поддельное сообщение FORCERENEW. Это открывает огромную дыру в безопасности, ведь злоумышленник может массово сбивать клиентов с толку, вызывая хаос в сети.

Почему это опасно: уязвимость RFC 3203

Важно! В оригинальном RFC 3203, который впервые (но это не точно) описал механизм FORCERENEW, аутентификация сообщений не реализована. То есть, любой участник сети может сгенерировать и отправить FORCERENEW, и если клиент поддерживает этот механизм, он послушно выполнит команду, не проверяя её подлинность. Это — критическая брешь в безопасности.

Как решается проблема: RFC 6704 и аутентификация

На помощь приходит RFC 6704, который обновляет и дополняет описанный в RFC 3203 механизм. Суть решения — одноразовая аутентификация сообщений FORCERENEW. Это позволяет убедиться, что команда на обновление пришла именно от доверенного сервера, а не от злоумышленника.

Исторический контекст

• RFC 3118 — описывает общий механизм аутентификации для всех сообщений DHCP (DHCP Authentication), но практически не используется из-за сложности внедрения.
• RFC 3203 — вводит FORCERENEW, но не реализует аутентификацию для этого типа сообщений.
• RFC 6704 — уточняет и рекомендует использовать одноразовую аутентификацию именно для FORCERENEW, чтобы закрыть уязвимость.

Как работает аутентификация FORCERENEW

1. Клиент сообщает о поддержке аутентификации
   • В DHCP-запросе клиент указывает в опции 145, что поддерживает аутентификацию с использованием алгоритма HMAC-MD5 (значение 1).
   • 
2. Сервер подтверждает поддержку аутентификации
   • В ответе DHCPOFFER сервер также указывает поддержку аутентификации.
   • 
3. Передача ключа аутентификации
   • Когда сервер подтверждает аренду (DHCPACK), он добавляет в сообщение опцию 90 — именно она содержит ключ для аутентификации (HMAC-MD5).
   • 
4. Где увидеть ключ в RouterOS
   • На клиенте ключ отображается в статусе DHCP-клиента:[admin@client.dhcp.vasilevkirill.ru] > /ip/dhcp-client/print detail ... reconfigure-key="15697dbb1b55b34f63032287c93192da" ...
   • На сервере ключ виден в деталях аренды (lease):[admin@server.dhcp.vasilevkirill.ru] > /ip/dhcp-server/lease/print detail ... reconfigure-key="15697dbb1b55b34f63032287c93192da" ...
5. Процесс обновления с аутентификацией
   • Когда сервер отправляет FORCERENEW, он использует этот ключ для подписи сообщения.
   • Клиент проверяет подпись и, если всё корректно, с радостью принимает обновление параметров.
   • 
   • 

Как проверить результат

• Сохраните экспорт конфигурации DHCP-клиента и сервера.
• Отправьте FORCERENEW тестовому клиенту и проверьте журнал и обновление аренды.
• Убедитесь, что неподтверждённое сообщение не меняет параметры клиента в вашей схеме.

Источники и связанные материалы

• RFC 6704
• Все статьи
• Аудит MikroTik
• Настройка MikroTik

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