RRAS-DHCP: nuwe adres of net konfigurasie-opsies?

Om 'n DHCPACK in 'n opname te lees as bewys dat die VPN-kliënt sy adres van DHCP gekry het, is 'n fout. Gewoonlik bewys dit net dat een of ander DHCP-boodskap beantwoord is. Windows RRAS kan sessie-adresse uit sy eie statiese poel uitdeel terwyl DHCP steeds opsies aan die gekoppelde kliënt voorsien. Die tipe versoek vertel jou watter van die twee take aan die gang was.

Twee take wat dieselfde boodskaptipe deel

DHCP doen twee afsonderlike dinge, en hulle deel boodskaptipes. Een is om 'n adres en 'n huurtermyn toe te ken. Die ander is om konfigurasie te lewer aan 'n gasheer wat reeds 'n adres het, wat RFC 2131 DHCPINFORM noem. Die antwoord in die tweede geval dra opsies en geen huurtyd nie.

Dus is 'n ACK bewys van 'n antwoord, nie bewys van 'n toekenning nie. Die boodskap wat dit voorafgegaan het, bepaal watter vraag gevra is. Lees eers die versoeklyn, en die res van die spoorsnit verduidelik gewoonlik homself.

Waar RRAS die adres kry

RRAS besit die VPN-adresbesluit deur sy gekonfigureerde IPv4-toekenningsmetode: óf 'n DHCP-bediener óf 'n statiese adrespoel. Wanneer die poel staties is, is die poel die toekenner, en 'n reservering op 'n aparte DHCP-bediener het geen sê in daardie sessie nie. Die twee meganismes kan op dieselfde netwerk saamleef sonder dat een die ander beheer.

Get-Command -Module RemoteAccess *IPAddress*

Vind die toekenningsmetode wat geld voordat jy die adres ontfout. As dit 'n statiese poel is, is die DHCP-omvang die verkeerde plek om te kyk. Die opdrag hierbo lys die cmdlets wat op jou weergawe beskikbaar is, en dit is genoeg om die instelling te vind.

Wat 'n gebruikersklas kan bewys en nie kan bewys nie

'n DHCP-gebruikersklas is 'n string wat die kliënt stuur, nie 'n geauthentiseerde groeplidmaatskap nie. Selfs wanneer 'n kliënt een stuur en die bediener 'n beleid daarop pas, bewys die etiket net dat die string aangekom het. RFC 3004 sê duidelik dat die opsie nie die reg op die klas authentiseer nie.

Moenie verwag dat 'n VPN-gebruikersnaam, 'n sekuriteitsgroep-identifiseerder of die skootrekenaar se Ethernet-adres in daardie versoek in 'n bruikbare vorm sal verskyn nie. Dit is feite oor verifikasie en gids, en die DHCP-versoek dra nie een van die twee nie. As die vereiste is om gemagtigde mense te onderskei, handhaaf dit in die VPN-beleid waar die identiteit werklik bestaan. Daardie skeiding is die rede waarom die twee stelsels onafhanklik bly.

Vergelyk die bewyse, nie die ACK nie

Bou die bewysketting in plaas daarvan om een pakkie te lees. Teken die adres aan wat die sessie ontvang het, die boodskaptipe en velde van die versoek, die opsies wat die bediener teruggegee het, en die kliënt se effektiewe konfigurasie daarna. Elke skakel beantwoord 'n ander vraag, en 'n ontbrekende skakel is waar die werklike fout gewoonlik sit.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

As die adres uit die RRAS-poel gekom het, verduidelik 'n DHCP-reservering niks. As die opsies aangekom het maar die kliënt het dit geïgnoreer, het die bediener sy werk gedoen en is die kliëntkonfigurasie die volgende stop. Vergelyk daardie twee uitkomste eksplisiet, en die ACK is nie meer dubbelsinnig nie. Twee spoorsnye, een uit elke toekenningsmetode, besleg die argument vinniger as enige dokumentasie.