Always On VPN nije pristup LAN mreži: kontrolna lista resursa

Always On je životni ciklus veze: profil se povezuje pri ili prije prijave i ponovo se povezuje bez ikakvog pritiska korisnika. To ne znači da su svako privatno odredište, protokol i korisnik dozvoljeni. Praktično pitanje je koje resurse raspoređeni profil zaista isporučuje, a odgovor traži provjeru po resursu, a ne pogled na značku Connected.

Korak 1: Zapišite resurs prije testiranja

Počnite s kratkim zapisom po aplikaciji, preuzetim iz stvarnog okruženja: naziv, prefiks odredišta, servis i port, uloga tunela, grupa identiteta i putanja rezolvera.

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

Zapis nameće četiri odvojena pitanja. Ruta odlučuje kuda ide adresa; DNS politika odlučuje kako klijent saznaje adresu; filter saobraćaja odlučuje smije li taj saobraćaj koristiti vezu; firewall odredišta i dozvole aplikacije odlučuju hoće li zahtjev biti prihvaćen. Nijedno od toga ne slijedi iz povezanog tunela.

Korak 2: Odredite koji tunel treba da ga nosi

Windows Always On VPN ima tunel uređaja i korisnički tunel, koji se konfigurišu kao odvojeni profili s odvojenim certifikatima i obuhvatima. Tunel uređaja obično nosi samo infrastrukturu potrebnu prije prijave, poput upravljanja i domenskih servisa; široki pristup zaposlenika aplikacijama pripada korisničkom tunelu.

Filteri saobraćaja su funkcija tunela uređaja, zato Microsoftov primjer njima pokriva upravljački saobraćaj. Kopiranje tog primjera u opšti profil pristupa resursima daje tunel koji se povezuje ali nosi pogrešan skup. Provjerite aktivnu vezu pomoću Get-VpnConnection i testirajte pod tom vezom.

Korak 3: Provjerite rutu za stvarnu adresu

Razriješite naziv jednom, zatim provjerite rutu: Find-NetRoute -RemoteIPAddress 10.20.5.10 prikazuje odabrani interfejs, sljedeći skok i izvornu adresu. Ako je interfejs fizički adapter, prefiks nedostaje u skupu ruta tunela ili ga je klijent isključio kroz podijeljeni tunel. Uporedite s definicijom profila umjesto da dodajete lokalnu rutu.

Lokalna route add može učiniti da test prođe i nestati pri sljedećem osvježavanju politike, zato promjena pripada upravljanom profilu. Provjerite prefiks u korisničkom i profilu uređaja, i provjerite postavku podijeljenog tunela: puni tunel ne treba rutu po prefiksu, podijeljeni treba jednu za svaki privatni prefiks koji nosi.

Korak 4: Testirajte razrješavanje privatnih imena odvojeno

Privatna imena imaju vlastitu putanju politike. Profil može isporučiti NRPT pravila i listu za pretragu DNS sufiksa, važeću dok je tunel povezan. Pročitajte pomoću Get-DnsClientNrptPolicy šta je klijent zaista primio, pa testirajte ime i adresu u istoj sesiji. Imena koja padaju dok adrese rade upućuju na rezolver; oboje što pada upućuje na rutu.

Ime se može razriješiti i u adresu izvan ruta tunela, što miješa uspjeh i istek vremena. Uporedite vraćenu adresu s prefiksom u zapisu; ako se razlikuju, privatna zona odgovara javnom ili alternativnom adresom i ruta koja se poklopila nije projektovana.

Korak 5: Provjerite filtere, identitet i vlastita vrata aplikacije

Filteri saobraćaja ograničavaju koji protokoli i portovi smiju koristiti tunel uređaja, a uzak skup može blokirati resurs koji bi ruta nosila. Profil dodjeljuje vezu grupi, ali resurs ima vlastitu autorizaciju: korisnik koji se može povezati nije automatski prihvaćen na serveru datoteka.

Mijenjajte upravljani profil kroz njegovog vlasnika, bilo Intune, ProfileXML implementaciju ili operativnu skriptu, pa ponovo testirajte nakon normalnog ponovnog povezivanja i nakon restarta: uobičajeni kvar je zastarjela lokalna ruta ili profil primijenjen samo jednom. Držite verziju profila uz rezultat testa.