RRAS DHCP: ny adresse eller kun konfigurasjonsvalg?

Det er en feil å lese en DHCPACK i en opptak som bevis for at VPN-klienten fikk adressen sin fra DHCP. Som regel beviser den bare at en DHCP-melding eller annen ble besvart. Windows RRAS kan dele ut sesjonsadresser fra sin egen statiske pool mens DHCP fortsatt overleverer valg til den tilkoblede klienten. Hvilken av de to jobbene som pågikk, ser du av forespørselstypen.

To jobber som deler én meldingstype

DHCP utfører to atskilte oppgaver, og de deler meldingstyper. Den ene er å tildele en adresse og en leieavtale. Den andre er å overlevere konfigurasjon til en vert som allerede har en adresse, det RFC 2131 kaller DHCPINFORM. Svaret i det andre tilfellet inneholder valg og ingen leietid i det hele tatt.

En ACK er altså bevis for et svar, ikke for en tildeling. Meldingen foran den bestemmer hvilket spørsmål som ble stilt. Begynn med forespørselslinjen, så forklarer resten av sporet seg som regel selv.

Hvor RRAS henter adressen

RRAS har råderett over VPN-adressen gjennom den konfigurerte IPv4-tildelingsmetoden: enten en DHCP-tjener eller en statisk adressepool. Er poolen statisk, er poolen den som tildeler, og en reservasjon på en egen DHCP-tjener har ingenting den skulle ha sagt i den økten. De to mekanismene kan leve side om side på samme nett uten at noen av dem styrer den andre.

Get-Command -Module RemoteAccess *IPAddress*

Fastslå hvilken tildelingsmetode som gjelder før du feilsøker adressen. Er det en statisk pool, er DHCP-området feil sted å se. Kommandoen ovenfor lister opp cmdlet-ene som finnes i versjonen du kjører, og det holder for å finne innstillingen.

Hva en brukerklasse kan bevise og ikke bevise

En DHCP-brukerklasse er en streng som klienten sender, ikke et autentisert gruppemedlemskap. Selv om en klient sender en og tjeneren matcher en policy mot den, beviser etiketten bare at strengen kom frem. RFC 3004 sier rett ut at valget ikke autentiserer retten til klassen.

Ikke regn med at et VPN-brukernavn, en identifikator for en sikkerhetsgruppe eller Ethernet-adressen til maskinen dukker opp i den forespørselen i brukbar form. Dette er fakta om autentisering og katalog, og DHCP-forespørselen bærer ingen av dem. Er kravet å skille autoriserte personer, må det håndheves i VPN-policyen der identiteten faktisk finnes. Nettopp denne delingen gjør at de to systemene forblir uavhengige.

Sammenlign bevisene, ikke ACK-en

Bygg beviskjeden i stedet for å lese én pakke. Skriv ned adressen økten fikk, meldingstypen og feltene i forespørselen, valgene tjeneren returnerte, og deretter den reelle konfigurasjonen til klienten. Hver lenke svarer på et annet spørsmål, og den manglende lenken er der den virkelige feilen som regel ligger.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Kom adressen fra RRAS-poolen, forklarer en DHCP-reservasjon ingenting. Kom valgene frem men klienten overså dem, gjorde tjeneren jobben sin, og klientkonfigurasjonen er neste stopp. Sammenlign de to utfallene uttrykkelig, og ACK-en er ikke lenger tvetydig. To spor, ett fra hver tildelingsmetode, avgjør saken raskere enn noen dokumentasjon.