Ang Always On VPN ay hindi access sa LAN: checklist ng mga resource

Ang Always On ay isang lifecycle ng koneksyon: kumokonekta ang profile sa o bago ang pag-sign in at muling kumokonekta nang walang pinipindot ang gumagamit. Hindi ito nangangahulugang pinapayagan ang bawat pribadong destinasyon, protocol at gumagamit. Ang praktikal na tanong ay kung aling mga resource ang talagang ibinibigay ng na-deploy na profile, at ang sagot ay nangangailangan ng pagsusuri sa bawat resource, hindi pagtingin sa badge na Connected.

Hakbang 1: Isulat ang resource bago ito subukan

Magsimula sa isang maikling tala sa bawat app, na kinuha mula sa tunay na kapaligiran: pangalan, prefix ng destinasyon, serbisyo at port, papel ng tunnel, grupo ng pagkakakilanlan at landas ng resolver.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

Pinipilit ng tala ang apat na hiwalay na tanong. Ang ruta ang nagpapasya kung saan pupunta ang address; ang patakaran sa DNS ang nagpapasya kung paano malalaman ng client ang address; ang filter ng trapiko ang nagpapasya kung magagamit ng trapikong iyon ang koneksyon; ang firewall at mga pahintulot ng app sa destinasyon ang nagpapasya kung tatanggapin ang kahilingan. Wala sa apat na ito ang nagmumula sa konektadong tunnel.

Hakbang 2: Tukuyin kung aling tunnel ang dapat magdala nito

Ang Windows Always On VPN ay may device tunnel at user tunnel, na naka-configure bilang magkahiwalay na profile na may magkahiwalay na certificate at saklaw. Karaniwang dinadala ng device tunnel lamang ang imprastrukturang kailangan bago mag-sign in, tulad ng pamamahala at mga serbisyo ng domain; ang malawak na access ng mga empleyado sa app ay kabilang sa user tunnel.

Ang mga filter ng trapiko ay katangian ng device tunnel, kaya ginagamit ng halimbawa ng Microsoft ang mga ito para sa trapiko ng pamamahala. Ang pagkopya ng halimbawang iyon sa isang pangkalahatang profile ng resource ay nagbibigay ng tunnel na kumokonekta ngunit nagdadala ng maling set. Kumpirmahin ang aktibong koneksyon gamit ang Get-VpnConnection at subukan sa ilalim ng koneksyong iyon.

Hakbang 3: I-verify ang ruta para sa tunay na address

I-resolve ang pangalan nang isang beses, pagkatapos tingnan ang ruta: iniuulat ng Find-NetRoute -RemoteIPAddress 10.20.5.10 ang napiling interface, susunod na hop at source address. Kung ang interface ay ang pisikal na adapter, wala ang prefix sa set ng ruta ng tunnel o hindi ito isinama ng client sa pamamagitan ng split tunnel. Ihambing sa depinisyon ng profile sa halip na magdagdag ng lokal na ruta.

Ang lokal na route add ay maaaring magpatuloy ng test at mawala sa susunod na pag-refresh ng patakaran, kaya ang pagbabago ay kabilang sa pinamamahalaang profile. Suriin ang prefix sa profile ng gumagamit at ng device, at suriin ang setting ng split tunnel: ang buong tunnel ay hindi nangangailangan ng ruta sa bawat prefix, ang split tunnel ay nangangailangan ng isa sa bawat pribadong prefix na dinadala nito.

Hakbang 4: Subukan nang hiwalay ang pag-resolve ng pribadong pangalan

Ang mga pribadong pangalan ay may sariling landas ng patakaran. Maaaring magbigay ang profile ng mga panuntunan ng NRPT at listahan ng paghahanap ng suffix ng DNS, na may bisa habang nakaupo ang tunnel. Basahin gamit ang Get-DnsClientNrptPolicy kung ano ang aktwal na natanggap ng client, pagkatapos subukan ang isang pangalan at isang address sa parehong session. Kung nabigo ang mga pangalan habang gumagana ang mga address, ang resolver ang problema; kung pareho, ang ruta.

Ang isang pangalan ay maaari ring mag-resolve sa address na labas ng mga ruta ng tunnel, na naghahalo ng tagumpay at timeout. Ihambing ang ibinalik na address sa prefix sa iyong tala; kung magkaiba, ang pribadong zone ay sumasagot gamit ang pampubliko o alternatibong address at ang rutang tumugma ay hindi ang dinisenyo.

Hakbang 5: Suriin ang mga filter, pagkakakilanlan at ang sariling gate ng app

Nililimitahan ng mga filter ng trapiko kung aling protocol at port ang maaaring gumamit ng device tunnel, at ang makitid na set ay maaaring humadlang sa resource na dadalhin sana ng ruta. Itinatalaga ng profile ang koneksyon sa isang grupo, ngunit may sariling awtorisasyon ang resource: ang gumagamit na makakakonekta ay hindi awtomatikong tinatanggap ng file server.

Baguhin ang pinamamahalaang profile sa pamamagitan ng may-ari nito, maging Intune, deployment ng ProfileXML o script ng operasyon, pagkatapos subukan muli pagkatapos ng normal na muling pagkonekta at pagkatapos ng reboot: ang karaniwang pagkabigo ay lumang lokal na ruta o profile na inilapat nang isang beses lamang. Itago ang bersyon ng profile sa tabi ng resulta ng test.