RRAS DHCP: nova adreso aŭ nur agordaj opcioj?

Legi DHCPACK en kaptaĵo kiel pruvon, ke la VPN-kliento ricevis sian adreson de DHCP, estas eraro. Kutime ĝi pruvas nur, ke iu DHCP-mesaĝo estis respondita. Windows RRAS povas disdoni sesiajn adresojn el sia propra statika aro, dum DHCP ankoraŭ liveras opciojn al la konektita kliento. La petospeco diras al vi, kiu el la du taskoj okazis.

Du taskoj, kiuj dividas mesaĝospecon

DHCP faras du apartajn aferojn, kaj ili dividas mesaĝospecojn. Unu estas atribui adreson kaj luon. La alia estas liveri agordon al gasto, kiu jam havas adreson, kion RFC 2131 nomas DHCPINFORM. La respondo en la dua kazo portas opciojn kaj neniun luodaŭron.

Do ACK estas pruvo de respondo, ne pruvo de atribuo. La mesaĝo antaŭ ĝi decidas, kiu demando estis farita. Legu unue la petan linion kaj la resto de la spuro kutime klarigas sin mem.

De kie RRAS ricevas la adreson

RRAS posedas la decidon pri la VPN-adreso per sia agordita metodo de IPv4-atribuo: aŭ DHCP-servilo aŭ statika adresaro. Kiam la aro estas statika, la aro estas la atribuanto, kaj rezervo ĉe aparta DHCP-servilo havas nenion por diri en tiu sesio. La du mekanismoj povas kunekzisti en la sama reto sen ke unu regu la alian.

Get-Command -Module RemoteAccess *IPAddress*

Trovu la validan atribuan metodon antaŭ ol serĉi la kaŭzon en la adreso. Se temas pri statika aro, la DHCP-amplekso estas la malĝusta loko por rigardi. La supra komando listigas la cmdletojn disponeblajn en la versio, kiun vi uzas, kaj tio sufiĉas por trovi la agordon.

Kion uzantoklaso povas pruvi kaj kion ne

DHCP-uzantoklaso estas ĉeno, kiun la kliento sendas, ne aŭtentikigita grupanoeco. Eĉ kiam kliento sendas unu kaj la servilo aplikas regularon laŭ ĝi, la etikedo pruvas nur, ke la ĉeno alvenis. RFC 3004 diras senvoje, ke la opcio ne aŭtentikigas rajton al la klaso.

Ne atendu, ke VPN-uzantnomo, identigilo de sekureca grupo aŭ la Ethernet-adreso de la tekokomputilo aperos en tiu peto en uzebla formo. Tiuj estas faktoj pri aŭtentikigo kaj adresaro, kaj la DHCP-peto portas nek unu nek la alian. Se la postulo estas distingi rajtigitajn homojn, plenumu ĝin en la VPN-regularo, kie la identeco vere ekzistas. Ĝuste tiu disigo tenas la du sistemojn sendependaj.

Komparu la pruvojn, ne la ACK

Konstruu la pruvĉenon anstataŭ legi unu paketon. Notu la adreson, kiun la sesio ricevis, la mesaĝospecon kaj kampojn de la peto, la opciojn, kiujn la servilo redonis, kaj poste la efektivan agordon de la kliento. Ĉiu ĉenero respondas al malsama demando, kaj la mankanta ĉenero estas tie, kie la vera misfunkcio kutime sidas.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Se la adreso venis el la RRAS-aro, DHCP-rezervo klarigas nenion. Se la opcioj alvenis sed la kliento ignoris ilin, la servilo faris sian laboron kaj la klienta agordo estas la sekva halto. Komparu tiujn du rezultojn eksplice, kaj la ACK ĉesas esti dubsenca. Du spuroj, po unu el ĉiu atribua metodo, solvas la disputon pli rapide ol iu ajn dokumentaro.