RRAS DHCP: ny adresse eller berre konfigurasjonsval?

Å lese ein DHCPACK i eit opptak som prov på at VPN-klienten fekk adressa si frå DHCP, er ein feil. Vanlegvis beviser det berre at ei eller anna DHCP-melding vart svara på. Windows RRAS kan dela ut sesjonsadresser frå sin eigen statiske pool medan DHCP framleis leverer val til den tilkopla klienten. Førespurnadstypen fortel deg kva av dei to oppgåvene som gjekk føre seg.

To oppgåver som deler ein meldingstype

DHCP gjer to separate ting, og dei deler meldingstypar. Det eine er å tildele ei adresse og ei leige. Det andre er å levere konfigurasjon til ein vert som allereie har ei adresse, noko RFC 2131 kallar DHCPINFORM. Svaret i det andre tilfellet ber val og inga leigetid.

Så ein ACK er prov for eit svar, ikkje prov for ei tildeling. Meldinga før ho avgjer kva spørsmål som vart stilt. Les førespurnadslinja først, og resten av sporet forklarer seg vanlegvis sjølv.

Kvar RRAS hentar adressa frå

RRAS eig VPN-adresseavgjerda gjennom sin konfigurerte IPv4-tildelingsmetode: anten ein DHCP-tenar eller ein statisk adressepool. Når poolen er statisk, er poolen tildelaren, og ein reservasjon på ein separat DHCP-tenar har ingenting å seie i den sesjonen. Dei to mekanismane kan sameksistere på same nettverk utan at nokon av dei styrer den andre.

Get-Command -Module RemoteAccess *IPAddress*

Finn den gjeldande tildelingsmetoden før du feilsøkjer adressa. Er det ein statisk pool, er DHCP-området feil stad å leite. Kommandoen over listar cmdlet-ane som er tilgjengelege i versjonen du køyrer, og det er nok til å finne innstillinga.

Kva ein brukarklasse kan og ikkje kan bevisa

Ein DHCP-brukarklasse er ein streng klienten sender, ikkje eit autentisert gruppemedlemskap. Sjølv når ein klient sender ein og tenaren matchar ein policy på han, beviser etiketten berre at strengen kom fram. RFC 3004 seier rett ut at valet ikkje autentiserer retten til klassen.

Ikkje vent at eit VPN-brukarnamn, ein identifikator for ei tryggingsgruppe eller Ethernet-adressa til den berbare datamaskina dukkar opp i den førespurnaden i brukbar form. Det er fakta om autentisering og katalog, og DHCP-førespurnaden ber ingen av dei. Viss kravet er å skilje autoriserte personar, handhev det i VPN-policyen der identiteten faktisk finst. Denne skilnaden er grunnen til at dei to systema held fram med å vere uavhengige.

Samanlikn prova, ikkje ACK-en

Bygg provkjeda i staden for å lese éin pakke. Noter adressa sesjonen fekk, meldingstypen og felta i førespurnaden, vala tenaren returnerte, og deretter den faktiske konfigurasjonen til klienten. Kvar lenkje svarar på eit anna spørsmål, og den manglande lenkja er der den eigentlege feilen vanlegvis sit.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Kom adressa frå RRAS-poolen, forklarer ein DHCP-reservasjon ingenting. Kom vala fram men klienten ignorerte dei, gjorde tenaren jobben sin, og klientkonfigurasjonen er neste stopp. Samanlikn desse to utfalla eksplisitt, og ACK-en sluttar å vere tvitydig. To spor, eitt frå kvar tildelingsmetode, avgjer diskusjonen raskare enn noka dokumentasjon.