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 перестане бути двозначним. Дві траси, по одній на кожен метод призначення, закривають суперечку швидше за будь-яку документацію.

Схожі статті