RRAS DHCP: ny adress eller bara konfigurationsalternativ?

Att läsa en DHCPACK i en inspelning som bevis för att VPN-klienten fick sin adress från DHCP är ett misstag. Oftast bevisar den bara att något DHCP-meddelande besvarades. Windows RRAS kan dela ut sessionsadresser från sin egen statiska pool medan DHCP fortfarande levererar alternativ till den anslutna klienten. Typen av begäran talar om vilket av de två jobben som pågick.

Två jobb som delar en meddelandetyp

DHCP gör två separata saker, och de delar meddelandetyper. Det ena är att tilldela en adress och ett lån. Det andra är att leverera konfiguration till en värd som redan har en adress, vilket RFC 2131 kallar DHCPINFORM. Svaret i det andra fallet bär alternativ och ingen lånetid.

Så en ACK är bevis för ett svar, inte bevis för en tilldelning. Meddelandet före den avgör vilken fråga som ställdes. Läs begäransraden först, och resten av spåret förklarar sig oftast självt.

Varifrån RRAS hämtar adressen

RRAS äger beslutad VPN-adress genom sin konfigurerade IPv4-tilldelningsmetod: antingen en DHCP-server eller en statisk adresspool. När poolen är statisk är poolen tilldelaren, och en reservation på en separat DHCP-server har inget att säga i den sessionen. De två mekanismerna kan samexistera på samma nätverk utan att någon av dem styr den andra.

Get-Command -Module RemoteAccess *IPAddress*

Ta reda på vilken tilldelningsmetod som gäller innan du felsöker adressen. Är det en statisk pool är DHCP-området fel ställe att titta på. Kommandot ovan listar de cmdletar som finns i versionen du kör, och det räcker för att hitta inställningen.

Vad en användarklass kan och inte kan bevisa

En DHCP-användarklass är en sträng som klienten skickar, inte ett autentiserat gruppmedlemskap. Även när en klient skickar en och servern matchar en princip mot den bevisar etiketten bara att strängen kom fram. RFC 3004 säger rakt ut att alternativet inte autentiserar rätten till klassen.

Förvänta dig inte att ett VPN-användarnamn, en identifierare för en säkerhetsgrupp eller laptopens Ethernet-adress dyker upp i den begäran i användbar form. Det är fakta om autentisering och katalog, och DHCP-begäran bär ingendera. Om kravet är att skilja behöriga personer åt, genomdriv det i VPN-principen där identiteten faktiskt finns. Just den uppdelningen håller de två systemen oberoende.

Jämför bevisen, inte ACK:en

Bygg beviskedjan i stället för att läsa ett enda paket. Anteckna adressen som sessionen fick, meddelandetypen och fälten i begäran, alternativen som servern returnerade och därefter klientens faktiska konfiguration. Varje länk svarar på en annan fråga, och den saknade länken är där det verkliga felet oftast sitter.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Om adressen kom från RRAS-poolen förklarar en DHCP-reservation ingenting. Om alternativen kom men klienten ignorerade dem gjorde servern sitt jobb, och klientkonfigurationen är nästa stopp. Jämför de två utfallen uttryckligen och ACK:en slutar vara tvetydig. Två spår, ett från varje tilldelningsmetod, avgör diskussionen snabbare än någon dokumentation.