RRAS DHCP: uus aadress või ainult konfiguratsioonivalikud?

Lugeda DHCPACK-i salvestises tõendiks, et VPN-klient sai oma aadressi DHCP-lt, on viga. Tavaliselt tõestab see vaid seda, et mingile DHCP-sõnumile vastati. Windows RRAS saab sessiooni aadresse jagada oma staatilisest varust, samal ajal kui DHCP varustab ühendatud klienti endiselt valikutega. Päringu tüüp ütleb teile, milline kahest tööst parasjagu käis.

Kaks tööd, mis jagavad sõnumitüüpi

DHCP teeb kahte eri asja ja need jagavad sõnumitüüpe. Üks on aadressi ja rendi eraldamine. Teine on konfiguratsiooni kohaletoimetamine hostile, kellel on juba aadress, mida RFC 2131 nimetab DHCPINFORM-iks. Vastus teisel juhul kannab valikuid ja mitte mingit rendiaega.

Seega on ACK vastuse tõend, mitte eraldamise tõend. Sõnum, mis sellele eelnes, otsustab, milline küsimus esitati. Lugege kõigepealt päringurida ja ülejäänud jälg seletab tavaliselt ise ennast.

Kust RRAS aadressi saab

RRAS omab VPN-aadressi otsust oma seadistatud IPv4-eritamismeetodi kaudu: kas DHCP-serveri või staatilise aadressivaru kaudu. Kui varu on staatiline, on varu eraldaja ja eraldi DHCP-serveris tehtud broneeringul ei ole selles sessioonis sõnaõigust. Kaks mehhanismi võivad samas võrgus kõrvuti eksisteerida, ilma et üks teist juhtiks.

Get-Command -Module RemoteAccess *IPAddress*

Enne aadressi tõrkeotsingut tehke kindlaks kehtiv eritamismeetod. Kui tegu on staatilise varuga, on DHCP-ulatus vale koht, kust otsida. Ülaltoodud käsk loetleb käsud, mis teie versioonis saadaval on, ja sellest piisab seade leidmiseks.

Mida kasutajaklass tõestada saab ja mida mitte

DHCP kasutajaklass on string, mille klient saadab, mitte autenditud grupiliikme staatus. Isegi kui klient selle saadab ja server rakendab selle põhjal poliitikat, tõestab silt vaid seda, et string kohale jõudis. RFC 3004 ütleb otse, et see valik ei autenti õigust klassile.

Ärge oodake, et VPN-i kasutajanimi, turvagrupi identifikaator või sülearvuti Etherneti aadress ilmuksid selles päringus kasutataval kujul. Need on autentimise ja kataloogi faktid ning DHCP-päring ei kanna kumbagi. Kui nõue on eristada volitatud inimesi, rakendage seda VPN-i poliitikas, kus identiteet tegelikult olemas on. Just see eraldatus hoiab kaks süsteemi sõltumatuna.

Võrrelge tõendeid, mitte ACK-i

Ehitage tõendite ahel, selle asemel et lugeda ühte paketti. Kirjutage üles aadress, mille sessioon sai, päringu sõnumitüüp ja väljad, valikud, mille server tagastas, ja seejärel kliendi tegelik konfiguratsioon. Iga lüli vastab erinevale küsimusele ja puuduv lüli on koht, kus tegelik rike tavaliselt asub.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Kui aadress tuli RRAS-i varust, ei selita DHCP broneering midagi. Kui valikud saabusid, aga klient eiras neid, tegi server oma töö ja järgmine peatus on kliendi konfiguratsioon. Võrrelge neid kahte tulemust selgesõnaliselt ja ACK lakkab olemast mitmetähenduslik. Kaks jälge, üks kummastki eritamismeetodist, lahendavad vaidluse kiiremini kui ükski dokumentatsioon.