Always On VPN nie je prístup do LAN: kontrolný zoznam zdrojov

Always On je životný cyklus pripojenia: profil sa pripojí pri prihlásení alebo pred ním a znovu sa pripojí bez toho, aby používateľ čokoľvek stlačil. Neznamená to, že je povolený každý súkromný cieľ, protokol a používateľ. Praktická otázka je, ktoré zdroje nasadený profil skutočne doručí, a odpoveď si vyžaduje kontrolu po jednotlivých zdrojoch, nie pohľad na odznak Connected.

Krok 1: Zapíšte zdroj skôr, než ho otestujete

Začnite krátkym záznamom pre každú aplikáciu, prevzatým z reálneho prostredia: názov, prefix cieľa, služba a port, rola tunela, skupina identity a cesta prekladač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

Záznam vynúti štyri oddelené otázky. Trasa rozhoduje, kam adresa ide; politika DNS rozhoduje, ako sa klient dozvie adresu; filter premávky rozhoduje, či táto premávka smie použiť pripojenie; firewall cieľa a povolenia aplikácie rozhodujú, či bude požiadavka prijatá. Nič z toho nevyplýva z pripojeného tunela.

Krok 2: Určte, ktorý tunel to má niesť

Windows Always On VPN má tunel zariadenia a používateľský tunel, konfigurované ako samostatné profily so samostatnými certifikátmi a rozsahmi. Tunel zariadenia zvyčajne nesie len infraštruktúru potrebnú pred prihlásením, napríklad správu a doménové služby; široký prístup zamestnancov k aplikáciám patrí používateľskému tunelu.

Filtre premávky sú funkciou tunela zariadenia, preto ich príklad Microsoftu používa na prevádzku správy. Skopírovanie tohto príkladu do všeobecného profilu zdrojov dá tunel, ktorý sa pripojí, ale nesie nesprávnu množinu. Overte aktívne pripojenie pomocou Get-VpnConnection a testujte pod ním.

Krok 3: Overte trasu pre skutočnú adresu

Preložte názov raz a potom skontrolujte trasu: Find-NetRoute -RemoteIPAddress 10.20.5.10 hlási zvolené rozhranie, ďalší skok a zdrojovú adresu. Ak je rozhraním fyzický adaptér, prefix v množine trás tunela chýba alebo ho klient vylúčil rozdeleným tunelom. Porovnajte s definíciou profilu namiesto pridania lokálnej trasy.

Lokálna route add môže nechať test prejsť a pri ďalšej obnove politiky zmizne, preto zmena patrí do spravovaného profilu. Skontrolujte prefix v používateľskom aj zariadenovom profile a nastavenie rozdeleného tunela: plný tunel nepotrebuje trasu pre každý prefix, rozdelený potrebuje jednu pre každý súkromný prefix.

Krok 4: Otestujte preklad súkromných názvov oddelene

Súkromné názvy majú vlastnú cestu politiky. Profil môže doručiť pravidlá NRPT a zoznam hľadaných prípon DNS, platné počas pripojenia tunela. Prečítajte pomocou Get-DnsClientNrptPolicy, čo klient skutočne dostal, a potom otestujte názov aj adresu v tej istej relácii. Keď názvy zlyhávajú a adresy fungujú, ide o prekladač; keď oboje, o trasu.

Názov sa môže preložiť aj na adresu mimo trás tunela, čo mieša úspech s vypršaním. Porovnajte vrátenú adresu s prefixom v zázname; ak sa líšia, súkromná zóna odpovedá verejnou alebo alternatívnou adresou a zodpovedajúca trasa nie je tá navrhnutá.

Krok 5: Skontrolujte filtre, identitu a vlastnú bránu aplikácie

Filtre premávky obmedzujú, ktoré protokoly a porty smú používať tunel zariadenia, a úzka množina môže zablokovať zdroj, ktorý by trasa niesla. Profil priradí pripojenie skupine, ale zdroj má vlastnú autorizáciu: používateľ, ktorý sa dokáže pripojiť, nemusí byť súborovým serverom prijatý.

Meňte spravovaný profil cez jeho vlastníka, či je to Intune, nasadenie ProfileXML alebo skript prevádzky, a potom testujte znova po bežnom opätovnom pripojení a po reštarte: obvyklá závada je zastaraná lokálna trasa alebo profil aplikovaný raz. Uchovávajte verziu profilu vedľa výsledku testu.