RRAS DHCP: bagong address o mga opsyon sa configuration lang?

Ang pagbasa ng DHCPACK sa isang capture bilang patunay na nakuha ng VPN client ang address nito mula sa DHCP ay isang pagkakamali. Karaniwang pinatutunayan lamang nito na may nasagot na isang DHCP message. Maaaring magbigay ang Windows RRAS ng mga session address mula sa sarili nitong static pool habang ang DHCP ay nagbibigay pa rin ng mga opsyon sa konektadong client. Sinasabi ng uri ng request kung alin sa dalawang gawain ang nangyayari.

Dalawang gawain na nagbabahagi ng isang uri ng message

Dalawang magkaibang bagay ang ginagawa ng DHCP, at pareho silang nagbabahagi ng mga uri ng message. Ang isa ay ang paglalaan ng address at lease. Ang isa pa ay ang paghahatid ng configuration sa isang host na may address na, na tinatawag ng RFC 2131 na DHCPINFORM. Ang sagot sa ikalawang kaso ay may mga opsyon at walang anumang oras ng lease.

Kaya ang ACK ay patunay ng sagot, hindi patunay ng allocation. Ang message na nauna rito ang nagtatakda kung aling tanong ang itinanong. Basahin muna ang request line at karaniwang nagpapaliwanag na sa sarili nito ang natitirang trace.

Saan kinukuha ng RRAS ang address

Pagmamay-ari ng RRAS ang desisyon sa address ng VPN sa pamamagitan ng naka-configure nitong paraan ng paglalaan ng IPv4: alinman sa DHCP server o static na pool ng address. Kapag static ang pool, ang pool ang naglalaan, at walang saysay ang isang reservation sa hiwalay na DHCP server sa session na iyon. Maaaring magkasabay ang dalawang mekanismo sa isang network nang walang isang kumokontrol sa isa.

Get-Command -Module RemoteAccess *IPAddress*

Alamin ang umiiral na paraan ng paglalaan bago suriin ang address. Kung static na pool ito, maling lugar ang DHCP scope. Inililista ng command sa itaas ang mga cmdlet na available sa bersyon na pinapatakbo mo, at sapat na iyon para hanapin ang setting.

Ano ang kayang patunayan ng user class at ano ang hindi

Ang DHCP user class ay isang string na ipinapadala ng client, hindi isang authenticated na pagiging miyembro ng grupo. Kahit magpadala ang client ng isa at tumugma ang server ng patakaran dito, pinatutunayan lang ng label na dumating ang string. Malinaw na sinasabi ng RFC 3004 na hindi napatunayan ng opsyon na ito ang karapatan sa class.

Huwag asahan na lilitaw ang username ng VPN, identifier ng security group, o Ethernet address ng laptop sa request na iyon sa magagamit na anyo. Mga katotohanan ng authentication at directory ang mga iyon, at wala sa dalawa ang dala ng DHCP request. Kung ang pangangailangan ay makilala ang mga awtorisadong tao, ipatupad ito sa patakaran ng VPN kung saan talagang umiiral ang pagkakakilanlan. Ang paghihiwalay na iyon ang dahilan kung bakit nananatiling independent ang dalawang sistema.

Ihambing ang ebidensya, hindi ang ACK

Buuin ang kadena ng ebidensya sa halip na magbasa ng isang packet. Itala ang address na natanggap ng session, ang uri at mga field ng request, ang mga opsyon na ibinalik ng server, at pagkatapos ang aktwal na configuration ng client. Bawat kawing ay sumasagot sa ibang tanong, at ang nawawalang kawing ang karaniwang kinaroroonan ng tunay na depekto.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Kung galing sa pool ng RRAS ang address, walang naipapaliwanag ang isang DHCP reservation. Kung dumating ang mga opsyon ngunit binalewala ng client, nagawa ng server ang trabaho nito at ang configuration ng client ang susunod na hintuan. Ihambing nang tahasan ang dalawang kinalabasang iyon at hindi na magiging malabo ang ACK. Dalawang trace, isa mula sa bawat paraan ng paglalaan, ang nagtatapos sa debate nang mas mabilis kaysa sa anumang dokumentasyon.