RRAS DHCP: новый адрес или только параметры конфигурации?

ACK в трассе VPN доказывает ответ, а не выделение адреса. Адресом может владеть RRAS, а DHCP лишь доставляет параметры подключённому клиенту.

Читать DHCPACK в записи как доказательство того, что VPN-клиент получил адрес от DHCP, — ошибка. Обычно это доказывает лишь то, что на какое-то сообщение DHCP был дан ответ. Windows RRAS может раздавать адреса сеанса из собственного статического пула, пока DHCP по-прежнему передаёт параметры подключённому клиенту. Тип запроса подсказывает, какая из двух работ шла.

Две работы с общим типом сообщения

DHCP делает две разные вещи, и обе используют типы сообщений. Одна — выделение адреса и аренды. Другая — доставка конфигурации узлу, у которого уже есть адрес; RFC 2131 называет это DHCPINFORM. Ответ во втором случае несёт параметры и не несёт времени аренды.

Значит, ACK — доказательство ответа, а не доказательство выделения. Сообщение перед ним определяет, какой вопрос был задан. Сначала прочитайте строку запроса, и остальная часть трассы обычно объясняет себя сама.

Откуда RRAS берёт адрес

RRAS владеет решением об адресе VPN через настроенный метод назначения IPv4: либо сервер DHCP, либо статический пул адресов. Когда пул статический, распределяет именно пул, и резервирование на отдельном сервере DHCP в этом сеансе ничего не решает. Оба механизма могут сосуществовать в одной сети, не управляя друг другом.

Get-Command -Module RemoteAccess *IPAddress*

Выясните действующий метод назначения, прежде чем искать причину в адресе. Если это статический пул, область DHCP — не то место, где стоит искать. Команда выше перечисляет командлеты, доступные в вашей версии, и этого достаточно, чтобы найти настройку.

Что класс пользователя может доказать, а что нет

Класс пользователя DHCP — это строка, которую отправляет клиент, а не подтверждённое членство в группе. Даже если клиент отправляет её, а сервер применяет к ней политику, метка доказывает лишь то, что строка дошла. RFC 3004 прямо говорит, что этот параметр не подтверждает право на класс.

Не ждите, что имя пользователя VPN, идентификатор группы безопасности или Ethernet-адрес ноутбука появятся в этом запросе в пригодном виде. Это факты аутентификации и каталога, и запрос DHCP не несёт ни того, ни другого. Если требуется различать уполномоченных людей, делайте это в политике VPN, где идентичность действительно существует. Именно это разделение сохраняет две системы независимыми.

Сравнивайте доказательства, а не ACK

Стройте цепочку доказательств вместо чтения одного пакета. Запишите адрес, полученный сеансом, тип и поля запроса, параметры, возвращённые сервером, и затем фактическую конфигурацию клиента. Каждое звено отвечает на свой вопрос, и недостающее звено — обычно то место, где сидит настоящая неисправность.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Если адрес пришёл из пула RRAS, резервирование DHCP ничего не объясняет. Если параметры пришли, но клиент их проигнорировал, сервер сделал свою работу, и следующая остановка — конфигурация клиента. Сравните эти два исхода явно, и ACK перестанет быть двусмысленным. Две трассы, по одной на каждый метод назначения, закрывают спор быстрее любой документации.

Похожие статьи