RRAS DHCP: helbide berria edo konfigurazio-aukerak soilik?

Kaptura batean DHCPACK bat VPN bezeroak helbidea DHCPtik jaso zuelako froga gisa irakurtzea akatsa da. Normalean DHCP mezu bati erantzun zaiola frogatzen du soilik. Windows RRASek sesio-helbideak bere pool estatiko propiotik eman ditzake, DHCPk konektatutako bezeroari aukerak ematen jarraitzen duen bitartean. Eskaeraren motak esaten dizu bi lanetatik zein ari zen gertatzen.

Mezu-mota bat partekatzen duten bi lan

DHCPk bi gauza bereizi egiten ditu, eta mezuen motak partekatzen dituzte. Bata helbide bat eta errentamendu bat esleitzea da. Bestea jada helbide bat duen ostalariari konfigurazioa ematea da, eta RFC 2131ek DHCPINFORM deitzen dio horri. Bigarren kasuan erantzunak aukerak daramatza eta ez du errentamendu denborarik.

Beraz, ACK bat erantzun baten froga da, ez esleipen baten froga. Aurretik joan zen mezuak erabakitzen du zein galdera egin zen. Irakurri lehenengo eskaera-lerroa eta arrastoaren gainerakoak bere burua argitzen du normalean.

Nondik lortzen du RRASek helbidea

RRASek VPN helbidearen erabakia du bere IPv4 esleipen metodo konfiguratuaren bidez: DHCP zerbitzari bat edo helbide-pool estatiko bat. Poola estatiko denean, poola da esleitzailea, eta beste DHCP zerbitzari bateko erreserba batek ez du esatekorik sesio horretan. Bi mekanismoek sare berean elkarrekin bizi daitezke, batek bestea kontrolatu gabe.

Get-Command -Module RemoteAccess *IPAddress*

Aurkitu indarrean dagoen esleipen metodoa helbidea araztu aurretik. Pool estatikoa bada, DHCP esparrua leku okerra da begiratzeko. Goiko komandoak exekutatzen duzun bertsioan dauden cmdletak zerrendatzen ditu, eta hori nahikoa da ezarpena aurkitzeko.

Zer froga dezakeen erabiltzaile-klase batek eta zer ez

DHCP erabiltzaile-klasea bezeroak bidaltzen duen katea da, ez talde-kidetasun autentifikatua. Bezero batek bat bidali eta zerbitzariak haren gaineko politika bat aplikatzen duenean ere, etiketak katea iritsi zela frogatzen du soilik. RFC 3004k argi dio aukerak ez duela klasearekiko eskubidea autentifikatzen.

Ez espero VPN erabiltzaile-izen bat, segurtasun-talde identifikatzaile bat edo ordenagailu eramangarriaren Ethernet helbidea eskaera horretan erabilgarria den forman agertzea. Autentifikazio eta direktoriozko datuak dira horiek, eta DHCP eskaerak ez du bat ere ez bestea eramaten. Baldintza baimendutako pertsonak bereiztea bada, aplikatu VPN politikan, non identitatea benetan existitzen den. Bereizketa hori da bi sistemak independente mantentzearen arrazoia.

Konparatu frogak, ez ACKa

Eraiki froga-katea pakete bakarra irakurri ordez. Idatzi sesioak jaso zuen helbidea, eskaeraren mezu-mota eta eremuak, zerbitzariak itzulitako aukerak, eta geroago bezeroaren benetako konfigurazioa. Kate-maila bakoitzak galdera desberdin bati erantzuten dio, eta falta den katea-maila izaten da benetako akatsa egon ohi den lekua.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Helbidea RRAS pool-etik etorri bada, DHCP erreserba batek ez du ezer argitzen. Aukerak iritsi baina bezeroak alde batera utzi baditu, zerbitzariak bere lana egin du eta bezeroaren konfigurazioa da hurrengo geltokia. Konparatu bi emaitza horiek esplizituki eta ACKa ez da anbiguoa izateari uzten dio. Bi arrasto, esleipen metodo bakoitzeko bat, edozein dokumentaziok baino azkarrago konpontzen du eztabaida.