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

Korak 1: Zapišite resurs pre testiranja

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

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 sme li taj saobraćaj koristiti vezu; firewall odredišta i dozvole aplikacije odlučuju hoće li zahtev biti prihvaćen. Nijedno od toga ne sledi iz povezanog tunela.

Korak 2: Odredite koji tunel treba da ga nosi

Windows Always On VPN ima tunel uređaja i korisnički tunel, konfigurisane kao odvojene profile sa odvojenim sertifikatima i obuhvatima. Tunel uređaja obično nosi samo infrastrukturu potrebnu pre prijave, poput upravljanja i domenskih servisa; širok pristup zaposlenih aplikacijama pripada korisničkom tunelu.

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

Korak 3: Proverite rutu za stvarnu adresu

Razrešite naziv jednom, zatim proverite rutu: Find-NetRoute -RemoteIPAddress 10.20.5.10 prikazuje izabrani interfejs, sledeći skok i izvornu adresu. Ako je interfejs fizički adapter, prefiks nedostaje u skupu ruta tunela ili ga je klijent isključio kroz podeljeni tunel. Uporedite sa definicijom profila umesto da dodajete lokalnu rutu.

Lokalna route add može učiniti da test prođe i nestati pri sledećem osvežavanju politike, zato promena pripada upravljanom profilu. Proverite prefiks u korisničkom i profilu uređaja, i proverite postavku podeljenog tunela: puni tunel ne treba rutu po prefiksu, podeljeni treba jednu za svaki privatni prefiks.

Korak 4: Testirajte razrešavanje privatnih naziva odvojeno

Privatni nazivi imaju sopstvenu putanju politike. Profil može isporučiti NRPT pravila i listu za pretragu DNS nastavaka, važeću dok je tunel povezan. Pročitajte pomoću Get-DnsClientNrptPolicy šta je klijent zaista primio, pa testirajte naziv i adresu u istoj sesiji. Nazivi koji padaju dok adrese rade upućuju na razrešivač; oboje što pada upućuje na rutu.

Naziv se može razrešiti i u adresu izvan ruta tunela, što meša uspeh i istek vremena. Uporedite vraćenu adresu sa prefiksom u zapisu; ako se razlikuju, privatna zona odgovara javnom ili alternativnom adresom i ruta koja se poklopila nije projektovana.

Korak 5: Proverite filtere, identitet i sopstvena vrata aplikacije

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

Menjajte 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 zastarela lokalna ruta ili profil primenjen samo jednom. Držite verziju profila uz rezultat testa.

Povezani članci