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 престава да бъде двусмислен. Две трасета, по едно за всеки метод на задаване, решават спора по-бързо от всяка документация.

Подобни статии