Always On VPN nije pristup LAN-u: kontrolni popis resursa

Always On je životni ciklus veze: profil se povezuje pri ili prije prijave i ponovno se povezuje bez ikakvog pritiska korisnika. To ne znači da su svako privatno odredište, protokol i korisnik dopušteni. Praktično pitanje je koje resurse raspoređeni profil doista 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 razrješ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 kamo ide adresa; DNS politika odlučuje kako klijent saznaje adresu; filtar prometa odlučuje smije li taj promet koristiti vezu; vatrozid odredišta i dopuštenja aplikacije odlučuju hoće li zahtjev biti prihvaćen. Nijedno od toga ne slijedi iz povezanog tunela.

Korak 2: Odredite koji tunel to treba nositi

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

Filtri prometa funkcija su tunela uređaja, zato Microsoftov primjer njima pokriva upravljački promet. Kopiranje tog primjera u opći 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 odabrano sučelje, sljedeći skok i izvornu adresu. Ako je sučelje fizički adapter, prefiks nedostaje u skupu ruta tunela ili ga je klijent isključio kroz podijeljeni tunel. Usporedite 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.

Korak 4: Testirajte razrješavanje privatnih naziva odvojeno

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

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

Korak 5: Provjerite filtre, identitet i vlastita vrata aplikacije

Filtri prometa 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 vlastito ovlaštenje: korisnik koji se može povezati nije automatski prihvaćen na poslužitelju datoteka.

Mijenjajte upravljani profil kroz njegovog vlasnika, bilo Intune, ProfileXML implementaciju ili operativnu skriptu, pa ponovno 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.