RRAS DHCP: adresë e re apo vetëm opsione konfigurimi?
Një ACK në një gjurmë VPN provon një përgjigje, jo një ndarje. RRAS mund ta zotërojë adresën, ndërsa DHCP vetëm dorëzon opsione te klienti i lidhur.
Të lexosh një DHCPACK në një regjistrim si provë që klienti VPN e mori adresën nga DHCP është gabim. Zakonisht provon vetëm se një mesazh DHCP i është përgjigjur. Windows RRAS mund të shpërndajë adresa sesioni nga pishina e vet statike, ndërsa DHCP vazhdon të furnizojë opsione për klientin e lidhur. Lloji i kërkesës ju tregon cila prej dy punëve po ndodhte.
Dy punë që ndajnë një lloj mesazhi
DHCP bën dy gjëra të ndryshme dhe ato ndajnë lloje mesazhesh. Njëra është ndarja e një adrese dhe një qiraje. Tjetra është dorëzimi i konfigurimit te një host që tashmë ka adresë, të cilin RFC 2131 e quan DHCPINFORM. Përgjigjja në rastin e dytë mban opsione dhe asnjë kohë qiraje.
Pra, një ACK është provë e një përgjigjeje, jo provë e një ndarjeje. Mesazhi para tij vendos cila pyetje u bë. Lexoni fillimisht rreshtin e kërkesës dhe pjesa tjetër e gjurmës zakonisht shpjegohet vetë.
Nga e merr RRAS adresën
RRAS e zotëron vendimin për adresën VPN përmes metodës së caktuar të dhënies së IPv4: ose një server DHCP ose një pishinë statike adresash. Kur pishina është statike, pishina është ajo që cakton, dhe një rezervim në një server DHCP të veçantë nuk ka zë në atë sesion. Dy mekanizmat mund të bashkëjetojnë në të njëjtin rrjet pa kontrolluar njëri tjetrin.
Get-Command -Module RemoteAccess *IPAddress*Gjeni metodën e caktimit në fuqi përpara se të merreni me adresën. Nëse është pishinë statike, shtrirja DHCP është vendi i gabuar për të shikuar. Komanda më sipër liston cmdlet-et e disponueshme në versionin që ekzekutoni, dhe kjo mjafton për të gjetur cilësimin.
Çfarë mund dhe çfarë nuk mund të provojë një klasë përdoruesi
Klasa e përdoruesit DHCP është një varg që dërgon klienti, jo një anëtarësim i vërtetuar në grup. Edhe kur një klient dërgon një të tillë dhe serveri zbaton një politikë mbi të, etiketa provon vetëm se vargu mbërriti. RFC 3004 thotë troç se opsioni nuk vërteton të drejtën për klasën.
Mos prisni që një emër përdoruesi VPN, një identifikues i grupit të sigurisë ose adresa Ethernet e laptopit të shfaqen në atë kërkesë në një formë të përdorshme. Këto janë fakte vërtetimi dhe drejtorie, dhe kërkesa DHCP nuk mbart asnjërën. Nëse kërkesa është të dallohen personat e autorizuar, zbatojeni atë në politikën VPN, aty ku identiteti ekziston vërtet. Pikërisht kjo ndarje i mban dy sistemet të pavarur.
Krahasoni provat, jo ACK-në
Ndërtoni zinxhirin e provave në vend që të lexoni një paketë të vetme. Shënoni adresën që mori sesioni, llojin dhe fushat e kërkesës, opsionet që ktheu serveri, dhe më pas konfigurimin faktik të klientit. Çdo hallkë përgjigjet një pyetjeje tjetër, dhe hallka që mungon është zakonisht aty ku qëndron defekti i vërtetë.
Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0Nëse adresa erdhi nga pishina e RRAS, një rezervim DHCP nuk shpjegon asgjë. Nëse opsionet mbërritën por klienti i injoroi, serveri bëri punën e vet dhe ndalesa tjetër është konfigurimi i klientit. Krahasoni shprehimisht këto dy rezultate dhe ACK nuk është më i paqartë. Dy gjurmë, një për secilën metodë caktimi, e zgjidhin mosmarrëveshjen më shpejt se çdo dokumentacion.