Always On VPN ni dostop do LAN: kontrolni seznam virov

Always On je življenjski cikel povezave: profil se poveže ob ali pred prijavo in se znova poveže, ne da bi uporabnik karkoli pritisnil. To ne pomeni, da so dovoljeni vsak zasebni cilj, protokol in uporabnik. Praktično vprašanje je, katere vire nameščeni profil v resnici dostavi, in odgovor zahteva preverjanje po viru, ne pogled na značko Connected.

Korak 1: Zapišite vir, preden ga preizkusite

Začnite s kratkim zapisom za vsako aplikacijo, vzetim iz resničnega okolja: ime, predpona cilja, storitev in vrata, vloga tunela, skupina identitete in pot razreševalnika.

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 vsili štiri ločena vprašanja. Pot odloči, kam gre naslov; politika DNS odloči, kako odjemalec izve naslov; filter prometa odloči, ali sme ta promet uporabljati povezavo; požarni zid cilja in dovoljenja aplikacije odločijo, ali bo zahteva sprejeta. Nobeno od teh štirih ne izhaja iz povezanega tunela.

Korak 2: Določite, kateri tunel ga mora prenašati

Windows Always On VPN ima tunel naprave in uporabniški tunel, nastavljena kot ločena profila z ločenimi potrdili in obsegi. Tunel naprave običajno prenaša le infrastrukturo, potrebno pred prijavo, na primer upravljanje in domenske storitve; širok dostop zaposlenih do aplikacij spada v uporabniški tunel.

Filtri prometa so funkcija tunela naprave, zato jih Microsoftov primer uporablja za upravljanje prometa. Če ta primer kopirate v splošen profil virov, dobite tunel, ki se poveže, a prenaša napačen nabor. Potrdite dejavno povezavo z Get-VpnConnection in preizkusite pod njo.

Korak 3: Preverite pot za resnični naslov

Razrešite ime enkrat in nato preverite pot: Find-NetRoute -RemoteIPAddress 10.20.5.10 poroča o izbranem vmesniku, naslednjem skoku in izvornem naslovu. Če je vmesnik fizični adapter, predpone ni v naboru poti tunela ali pa jo je odjemalec izključil z razdeljenim tunelom. Primerjajte z definicijo profila, namesto da dodate lokalno pot.

Lokalna route add lahko poskrbi, da preizkus uspe, in izgine ob naslednji osvežitvi pravilnika, zato sprememba spada v upravljani profil. Preverite predpono v uporabniškem in napravnem profilu ter nastavitev razdeljenega tunela: polni tunel ne potrebuje poti na predpono, razdeljeni potrebuje eno za vsako zasebno predpono.

Korak 4: Ločeno preizkusite razreševanje zasebnih imen

Zasebna imena imajo svojo pot pravilnika. Profil lahko dostavi pravila NRPT in seznam iskanja pripon DNS, veljavne, dokler je tunel pokonci. Preberite z Get-DnsClientNrptPolicy, kaj je odjemalec v resnici prejel, in nato preizkusite ime in naslov v isti seji. Če imena odpovedo, medtem ko naslovi delujejo, je kriv razreševalnik; če oboje, pot.

Ime se lahko razreši tudi v naslov zunaj poti tunela, kar meša uspeh s pretekom časa. Primerjajte vrnjeni naslov s predpono v zapisu; če se razlikujeta, zasebna cona odgovarja z javnim ali nadomestnim naslovom in ujemajoča pot ni načrtovana.

Korak 5: Preverite filtre, identiteto in lastna vrata aplikacije

Filtri prometa omejujejo, kateri protokoli in vrata smejo uporabljati tunel naprave, in ozek nabor lahko blokira vir, ki bi ga pot prenašala. Profil dodeli povezavo skupini, a vir ima svojo avtorizacijo: uporabnik, ki se lahko poveže, ni samodejno sprejet na strežniku datotek.

Upravljani profil spreminjajte prek njegovega lastnika, naj bo to Intune, uvajanje ProfileXML ali operacijska skripta, in nato znova preizkusite po običajnem ponovnem povezovanju in po ponovnem zagonu: običajna napaka je zastarela lokalna pot ali profil, uporabljen samo enkrat. Hranite različico profila ob rezultatu preizkusa.