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 опсег је погрешно место за тражење. Наредба изнад наводи cmdlet наредбе доступне у верзији коју покрећете, и то је довољно да пронађете поставку.

Шта корисничка класа може, а шта не може да докаже

DHCP корисничка класа је низ који клијент шаље, а не аутентификовано чланство у групи. Чак и када клијент пошаље један и сервер примени правило на основу њега, ознака доказује само да је низ стигао. RFC 3004 јасно каже да та опција не потврђује право на класу.

Не очекујте да ће се VPN корисничко име, идентификатор безбедносне групе или Ethernet адреса лаптопа појавити у том захтеву у употребљивом облику. То су чињенице аутентификације и именика, а DHCP захтев не носи ни једно ни друго. Ако је услов разликовање овлашћених људи, спроведите га у VPN правилу где идентитет заиста постоји. Управо то раздвајање држи два система независним.

Упоредите доказе, а не ACK

Изградите ланац доказа уместо да читате један пакет. Забележите адресу коју је сесија добила, тип и поља захтева, опције које је сервер вратио и потом стварну конфигурацију клијента. Свака карика одговара на друго питање, а карика која недостаје је место где обично лежи прави квар.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Ако је адреса дошла из RRAS пула, DHCP резервација не објашњава ништа. Ако су опције стигле, али их је клијент занемарио, сервер је урадио свој посао и следећа станица је конфигурација клијента. Упоредите та два исхода изричито и ACK престаје да буде двосмислен. Два трага, по један за сваки метод доделе, решавају расправу брже од било које документације.

Повезани чланци