RRAS DHCP: een nieuw adres of alleen configuratieopties?

Een DHCPACK in een capture lezen als bewijs dat de VPN-client zijn adres van DHCP heeft gekregen, is een fout. Meestal bewijst het alleen dat er op een of ander DHCP-bericht is geantwoord. Windows RRAS kan sessieadressen uit zijn eigen statische pool uitdelen terwijl DHCP nog steeds opties levert aan de verbonden client. Het type verzoek vertelt u welke van de twee taken bezig was.

Twee taken die één berichttype delen

DHCP doet twee afzonderlijke dingen, en ze delen berichttypen. Het ene is een adres en een lease toewijzen. Het andere is configuratie leveren aan een host die al een adres heeft, wat RFC 2131 DHCPINFORM noemt. Het antwoord in het tweede geval draagt opties en geen leasetijd.

Een ACK is dus bewijs van een antwoord, niet van een toewijzing. Het bericht ervoor bepaalt welke vraag is gesteld. Lees eerst de verzoekregel en de rest van de trace verklaart zich meestal zelf.

Waar RRAS het adres vandaan haalt

RRAS bezit de beslissing over het VPN-adres via zijn geconfigureerde IPv4-toewijzingsmethode: een DHCP-server of een statische adrespool. Als de pool statisch is, is de pool de toewijzer, en een reservering op een aparte DHCP-server heeft in die sessie niets te zeggen. De twee mechanismen kunnen op hetzelfde netwerk naast elkaar bestaan zonder dat een van beide de andere bestuurt.

Get-Command -Module RemoteAccess *IPAddress*

Zoek de geldende toewijzingsmethode voordat u het adres onderzoekt. Is het een statische pool, dan is het DHCP-bereik de verkeerde plek. De opdracht hierboven noemt de cmdlets die in uw versie beschikbaar zijn, en dat is genoeg om de instelling te vinden.

Wat een gebruikersklasse wel en niet kan bewijzen

Een DHCP-gebruikersklasse is een tekenreeks die de client stuurt, geen geauthenticeerd groepslidmaatschap. Zelfs wanneer een client er een stuurt en de server er een beleid op toepast, bewijst het label alleen dat de tekenreeks is aangekomen. RFC 3004 zegt ronduit dat de optie het recht op de klasse niet authenticeert.

Verwacht niet dat een VPN-gebruikersnaam, een identificatie van een beveiligingsgroep of het Ethernet-adres van de laptop in dat verzoek in bruikbare vorm opduikt. Dat zijn feiten over authenticatie en mappen, en het DHCP-verzoek draagt geen van beide. Als de eis is om bevoegde personen te onderscheiden, handhaaf dat in het VPN-beleid waar de identiteit werkelijk bestaat. Die scheiding is de reden dat de twee systemen onafhankelijk blijven.

Vergelijk het bewijs, niet de ACK

Bouw de bewijsketen op in plaats van één pakket te lezen. Noteer het adres dat de sessie kreeg, het berichttype en de velden van het verzoek, de opties die de server teruggaf, en daarna de feitelijke configuratie van de client. Elke schakel beantwoordt een andere vraag, en de ontbrekende schakel is waar de echte fout meestal zit.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Kwam het adres uit de RRAS-pool, dan verklaart een DHCP-reservering niets. Kwamen de opties aan maar negeerde de client ze, dan deed de server zijn werk en is de clientconfiguratie de volgende stop. Vergelijk die twee uitkomsten expliciet en de ACK is niet langer dubbelzinnig. Twee traces, één per toewijzingsmethode, beslechten de discussie sneller dan welke documentatie dan ook.