Nawawala ang Group Policy sa VPN? Suriin ang saklaw bago ang tunnel

Isang bagay na dating gumagana sa network ng opisina ay tumitigil sa paggana sa linggong nagsisimulang magtrabaho ang isang user sa pamamagitan ng VPN, at ang tunnel ang sinisisi bago pa may magbukas ng ulat. Ang Group Policy ang nagtatakda kung aling mga setting ang dumarating sa user at computer ng Windows, kumukuha ng materyal mula sa domain at nagpapatupad ng pagproseso sa panig ng kliyente, at nabibigo ang tatlong hakbang na iyon sa tatlong magkaibang paraan. Ang binabago lang ng tunnel ay kung anong landas mayroon ang kliyente. Ang pagsunod sa mga pagsusuri nang sunud-sunod ay pumipigil sa isang problema sa pahintulot ng file na habulin bilang problema sa routing.

Magsimula sa setting, hindi sa tunnel

Isulat ang isang inaasahang GPO at isang konkretong setting sa loob nito, pagkatapos magpasya kung ang setting ay nasa User Configuration o Computer Configuration. Ipinapalagay nito ang isang awtorisadong Windows client na kaanib sa domain sa isang aprubadong VPN, hindi isang hindi pinamamahalaang o cloud-only na device na ginagawang miyembro ng domain. Ang sagot sa saklaw ang nagtatakda kung sino ang makababasa ng resulta at kung kailangan ng elevation, kaya ayusin ito bago magpatupad ng anuman.

Itanong sa administrator ng domain kung aling link, lokasyon ng object, mga filter ng seguridad at mga filter ng WMI ang dapat gumana. Ang pagbabago ng mga kontrol na iyon para pumasa ang isang pagsubok ay ibang proyekto na may ibang may-ari.

Basahin ang ulat gamit ang account na may-ari ng setting

Sa sariling session ng apektadong user, patakbuhin ang whoami /user at pagkatapos ang gpresult /scope user /r. Ang account na nagpatotoo sa VPN ay hindi awtomatikong ang Windows account na binabasa mo ng patakaran, at ang pagsusuring mula sa account ng administrator ay sumasagot sa ibang tanong. I-save ang baseline sa ilalim ng bagong pangalan ng file, tulad ng %TEMP%\vpn-policy-user-before.html. Ang sanggunian ng gpresult ay nagdodokumento ng mga switch ng saklaw at output, at sulit malaman na ang paggawa ng ulat ay hindi nagre-refresh ng anuman.

Ang patakaran ng computer ay may sariling saklaw at konteksto ng pahintulot, kaya suriin ito nang hiwalay gamit ang kinakailangang elevation. Ang pagsasama ng dalawang saklaw sa isang ulat ang paraan kung paano idinedeklarang nawawala ang isang setting ng user kahit hindi ito kailanman nasa saklaw na iyon.

Ang pagtuklas ay hindi pag-access: mga rekord ng SRV muna, pagkatapos SMB

Kapag nakakonekta ang aprubadong VPN, tiyakin na nireresolba ng kliyente ang mga domain controller sa nilalayong landas ng DNS; ang isang pampublikong website na naglo-load ay walang sinasabi tungkol sa pagtuklas ng controller. Para sa halimbawang domain na corp.example, sinasagot ng nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example ang tanong na talagang mayroon ka. Ang ibinalik na rekord ng serbisyo ay patunay lamang ng pagtuklas, dahil ang address ng napiling controller ay kailangan pa ring maabot gamit ang kinakailangang authentication at mga pinapayagang serbisyo ng direktoryo. Ang materyal ng patakaran ay darating pagkatapos mula sa SYSVOL, na isang pagbasa ng SMB laban sa partikular na controller na iyon at hindi isang pagsubok ng ICMP.

Ang mahinang ebidensya ay madaling mapagkamalang patunay. Ang tugon ng ICMP mula sa isang controller, sa tabi ng tinanggihang pagbasa ng template ng patakaran, ay gumagawa ng ulat na mukhang walang laman dahil sa dahilang wala pang nakakonekta.

Panatilihing magkakatugma ang mga pahintulot ng serbisyo ng AD, mga landas ng pagbabalik at pag-sync ng oras ng deployment, sa halip na palitan ang mga ito ng buong pagbubukas ng firewall o pampublikong DNS server. Ang data ng patakaran na nagkakaiba sa pagitan ng mga controller ay isang usapin ng replikasyon para sa may-ari ng direktoryo.

Isang refresh, dalawang ulat, isang paghahambing

Kapag napatunayan na ang landas, hilingin ang kaugnay na refresh gamit ang gpupdate /target:user at basahin ang resulta sa halip na ipagpalagay ito. Inilalapat ng default na refresh ang binagong patakaran habang hinihiling ng /force ang muling paglalapat; wala sa dalawa ang nag-aayos ng DNS, pahintulot ng file o pag-filter. Ang ilang extension ay natatapos lamang sa susunod na pag-sign in o ibang pangyayari sa foreground, kaya ang isang pagtakbo ay hindi hatol. Ang pagdaragdag ng mga switch ng logoff o restart sa session ng malayuang user bilang karaniwang diagnostic ay nagtatapon ng anumang bukas niya.

Gumawa ng pangalawang ulat sa ilalim ng ibang pangalan ng file at ihambing ang oras ng pagproseso, ang inaasahang GPO, ang katayuang inilapat o tinanggihan at ang setting mismo. Ang ulat mula sa naunang matagumpay na session ay walang pinatutunayan tungkol sa refresh na ito. Ang patakarang na-filter ay tumutukoy sa pagiging naaangkop kaysa transportasyon, na nagbabago kung kanino ang susunod na hakbang.

Itali ang kabiguan sa isang aktibidad

Sa Event Viewer, magsimula sa babala o error ng Group Policy sa System log, pagkatapos lumipat sa operational log na GroupPolicy sa ilalim ng Applications and Services Logs. I-filter ang operational log na iyon sa identifier ng aktibidad ng refresh na pinatakbo mo lang, dahil ang bagong refresh ay nakakakuha ng bagong identifier at ang paghahalo nito sa mga pangyayari kahapon ay gumagawa ng kumpiyansa ngunit maling konklusyon. Itala ang oras, konteksto ng user o computer, napiling controller, GPO, error code at ang nabigong dependency.

Ang tala na iyon ang kayang aksyunan ng may-ari ng network o direktoryo. Ang pagkakakonekta sa VPN at pagpapatakbo ng gpupdate nang maraming beses ay hindi ebidensya, at wala sa dalawa ang tumatagal sa isang turnover.

Panatilihing pribado ang mga ulat na HTML, dahil inilalantad nila ang mga panloob na pangalan, pagiging kasapi ng grupo at configuration ng seguridad. Kapag nakumpirma na ang setting, alisin ang mga pansamantalang pahintulot na idinagdag mo sa halip na iwanan ang mga ito.