RRAS DHCP: ny adresse eller bare konfigurasjonsalternativer?

Å lese en DHCPACK i en opptak som bevis på at VPN-klienten fikk adressen sin fra DHCP, er en feil. Vanligvis beviser det bare at en eller annen DHCP-melding ble besvart. Windows RRAS kan dele ut sesjonsadresser fra sin egen statiske pool mens DHCP fortsatt leverer alternativer til den tilkoblede klienten. Forespørselstypen forteller deg hvilken av de to oppgavene som pågikk.

To oppgaver som deler en meldingstype

DHCP gjør to separate ting, og de deler meldingstyper. Det ene er å tildele en adresse og en leie. Det andre er å levere konfigurasjon til en vert som allerede har en adresse, noe RFC 2131 kaller DHCPINFORM. Svaret i det andre tilfellet bærer alternativer og ingen leietid.

Så en ACK er bevis for et svar, ikke bevis for en tildeling. Meldingen før den avgjør hvilket spørsmål som ble stilt. Les forespørselslinjen først, og resten av sporet forklarer seg vanligvis selv.

Hvor RRAS henter adressen fra

RRAS eier VPN-adressebeslutningen gjennom sin konfigurerte IPv4-tildelingsmetode: enten en DHCP-server eller en statisk adressepool. Når poolen er statisk, er poolen tildeleren, og en reservasjon på en separat DHCP-server har ingenting å si i den sesjonen. De to mekanismene kan sameksistere på samme nettverk uten at noen av dem styrer den andre.

Get-Command -Module RemoteAccess *IPAddress*

Finn den gjeldende tildelingsmetoden før du feilsøker adressen. Hvis det er en statisk pool, er DHCP-området feil sted å lete. Kommandoen ovenfor viser cmdlet-ene som er tilgjengelige i versjonen du kjører, og det er nok til å finne innstillingen.

Hva en brukerklasse kan og ikke kan bevise

En DHCP-brukerklasse er en streng klienten sender, ikke et autentisert gruppemedlemskap. Selv når en klient sender en og serveren matcher en policy på den, beviser etiketten bare at strengen kom frem. RFC 3004 sier rett ut at alternativet ikke autentiserer retten til klassen.

Ikke forvent at et VPN-brukernavn, en identifikator for en sikkerhetsgruppe eller laptopens Ethernet-adresse dukker opp i den forespørselen i brukbar form. Det er fakta om autentisering og katalog, og DHCP-forespørselen bærer ingen av dem. Hvis kravet er å skille autoriserte personer, håndhev det i VPN-policyen der identiteten faktisk finnes. Denne separasjonen er grunnen til at de to systemene forblir uavhengige.

Sammenlign bevisene, ikke ACK-en

Bygg beviskjeden i stedet for å lese én pakke. Noter adressen sesjonen fikk, meldingstypen og feltene i forespørselen, alternativene serveren returnerte, og deretter klientens faktiske konfigurasjon. Hvert ledd svarer på et annet spørsmål, og det manglende leddet er der den egentlige feilen vanligvis sitter.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Hvis adressen kom fra RRAS-poolen, forklarer en DHCP-reservasjon ingenting. Hvis alternativene kom, men klienten ignorerte dem, gjorde serveren jobben sin, og klientkonfigurasjonen er neste stopp. Sammenlign de to utfallene eksplisitt, og ACK-en slutter å være tvetydig. To spor, ett fra hver tildelingsmetode, avgjør diskusjonen raskere enn noen dokumentasjon.