Always On VPN ei ole LAN-juurdepääs: ressursside kontrollnimekiri

Always On on ühenduse elutsükkel: profiil ühendub sisselogimisel või enne seda ja taastab ühenduse ilma, et kasutaja midagi vajutaks. See ei tähenda, et iga privaatne sihtkoht, protokoll ja kasutaja on lubatud. Praktiline küsimus on, milliseid ressursse juurutatud profiil tegelikult edastab, ja vastus nõuab kontrolli iga ressursi kohta, mitte pilku Connected-märgisele.

Samm 1: Kirjutage ressurss üles enne testimist

Alustage lühikese kirjega iga rakenduse kohta, võetuna tegelikust keskkonnast: nimi, sihtkoha prefiks, teenus ja port, tunneli roll, identiteedirühm ja resolveri tee.

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

Kirje sunnib neli eraldi küsimust. Marsruut otsustab, kuhu aadress läheb; DNS-poliitika otsustab, kuidas klient aadressi teada saab; liiklusfilter otsustab, kas see liiklus tohib ühendust kasutada; sihtkoha tulemüür ja rakenduse load otsustavad, kas päring võetakse vastu. Ükski neljast ei tulene ühendatud tunnelist.

Samm 2: Tehke kindlaks, milline tunnel peab selle kandma

Windows Always On VPN-is on seadme tunnel ja kasutaja tunnel, mis konfigureeritakse eraldi profiilidena eraldi sertifikaatide ja ulatustega. Seadme tunnel kannab tavaliselt ainult enne sisselogimist vajalikku taristut, näiteks haldust ja domeeniteenuseid; töötajate lai rakendustele juurdepääs kuulub kasutaja tunnelile.

Liiklusfiltrid on seadme tunneli funktsioon, seetõttu kasutab Microsofti näide neid haldusliikluse jaoks. Selle näite kopeerimine üldisesse ressursiprofiili annab tunneli, mis ühendub, kuid kannab vale komplekti. Kinnitage aktiivne ühendus käsuga Get-VpnConnection ja testige selle ühenduse all.

Samm 3: Kontrollige marsruuti tegeliku aadressi jaoks

Lahendage nimi üks kord ja kontrollige siis marsruuti: Find-NetRoute -RemoteIPAddress 10.20.5.10 näitab valitud liidest, järgmist hüpet ja lähteaadressi. Kui liides on füüsiline adapter, puudub prefiks tunneli marsruudikomplektist või on klient selle jagatud tunneliga välja jätnud. Võrrelge profiili määratlusega, selle asemel et lisada kohalik marsruut.

Kohalik route add võib testi läbida ja järgmisel poliitika värskendusel kaduda, seepärast kuulub muudatus hallatavasse profiili. Kontrollige prefiksi nii kasutaja- kui ka seadmeprofiilis ning jagatud tunneli seadet: täistunnel ei vaja marsruuti iga prefiksi kohta, jagatud tunnel vajab ühte iga privaatse prefiksi kohta.

Samm 4: Testige privaatsete nimede lahendamist eraldi

Privaatsetel nimedel on oma poliitikatee. Profiil võib edastada NRPT reeglid ja DNS-i sufiksi otsinguloendi, mis kehtivad, kuni tunnel on üleval. Lugege käsuga Get-DnsClientNrptPolicy, mida klient tegelikult sai, ja testige siis sama seansi jooksul nime ja aadressi. Kui nimed ebaõnnestuvad aadresside toimimise ajal, on süüdi resolver; kui mõlemad, siis marsruut.

Nimi võib lahenduda ka aadressiks väljaspool tunneli marsruute, mis segab õnnestumise ja aegumise. Võrrelge tagastatud aadressi oma kirje prefiksiga; kui need erinevad, vastab privaatne tsoon avaliku või alternatiivse aadressiga ja sobiv marsruut ei ole projekteeritud oma.

Samm 5: Kontrollige filtreid, identiteeti ja rakenduse enda väravat

Liiklusfiltrid piiravad, millised protokollid ja pordid tohivad seadme tunnelit kasutada, ja kitsas komplekt võib blokeerida ressursi, mida marsruut muidu kannaks. Profiil määrab ühenduse rühmale, kuid ressursil on oma autoriseerimine: kasutajat, kes suudab ühenduda, ei võta failiserver automaatselt vastu.

Muutke hallatavat profiili selle omaniku kaudu, olgu selleks Intune, ProfileXML juurutus või operatsiooniskript, ja testige seejärel uuesti pärast tavalist taasühendumist ja pärast taaskäivitust: tavaline tõrge on vananenud kohalik marsruut või üks kord rakendatud profiil. Hoidke profiili versiooni testitulemuse kõrval.