Always On VPN er ekki LAN-aðgangur: gátlisti fyrir auðlindir

Always On er lífsferill tengingar: sniðið tengist við innskráningu eða fyrir hana og tengist aftur án þess að notandinn ýti á nokkuð. Það þýðir ekki að hver einkadestínsstaður, siðareglur og notandi séu leyfðir. Hin praktíska spurning er hvaða auðlindir dreifða sniðið skilar í raun, og það svar krefst athugunar fyrir hverja auðlind, ekki augnatills á Connected-merkið.

Skref 1: Skrifaðu auðlindina niður áður en þú prófar hana

Byrjaðu á stuttri færslu fyrir hvert forrit, fengna úr raunverulegu umhverfi: nafn, forskeyti áfangastaðar, þjónusta og port, hlutverk göngunnar, auðkennisflokkur og slóð leysisins.

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

Færslan þvingar fjórar aðskildar spurningar. Leið ræður því hvert vistfangið fer; DNS-stefna ræður því hvernig biðlarinn lærir vistfangið; umferðarsía ræður því hvort sú umferð megi nota tenginguna; eldveggur áfangastaðar og heimildir forritsins ráða því hvort beiðnin er samþykkt. Ekkert þessara fjögurra leiðir af tengdri göngu.

Skref 2: Ákvarða hvaða göng eigi að bera hana

Windows Always On VPN hefur tækjagöng og notendagöng, stillt sem aðskilin snið með aðskildum skírteinum og umfangi. Tækjagöngin bera venjulega aðeins þann grunn sem þarf fyrir innskráningu, svo sem stjórnun og lénsþjónustur; víðtækur forritaaðgangur starfsfólks heyrir undir notendagöngin.

Umferðarsíur eru eiginleiki tækjaganganna, þess vegna notar dæmi Microsoft þær fyrir stjórnunarumferð. Að afrita það dæmi í almennt auðlindasnið gefur göng sem tengjast en bera ranga mengið. Staðfestu virku tenginguna með Get-VpnConnection og prófaðu undir þeirri tengingu.

Skref 3: Sannreyna leiðina fyrir raunverulega vistfangið

Leystu nafnið einu sinni og athugaðu svo leiðina: Find-NetRoute -RemoteIPAddress 10.20.5.10 sýnir valda viðmótið, næsta stökk og upprunavistfangið. Ef viðmótið er líkamlegi millistykkið vantar forskeytið í leiðamengi ganganna eða biðlarinn útilokaði það með skiptum göngum. Berðu saman við skilgreiningu sniðsins í stað þess að bæta við staðbundinni leið.

Staðbundið route add getur látið prófið standast og hverfur við næstu stefnuuppfærslu, þess vegna á breytingin heima í stýrðu sniðinu. Athugaðu forskeytið í bæði notenda- og tækjasniðinu, og stillinguna fyrir skipt göng: full göng þurfa enga leið fyrir hvert forskeyti, skipt göng þurfa eina fyrir hvert einkaforskeyti.

Skref 4: Prófaðu upplausn einkanafna sér

Einkanöfn hafa sína eigin stefnuslóð. Sniðið getur skilað NRPT-reglum og DNS-viðskeytaleit, sem gilda meðan göngin eru uppi. Lestu með Get-DnsClientNrptPolicy hvað biðlarinn fékk í raun, prófaðu svo nafn og vistfang í sama lotu. Ef nöfn mistakast á meðan vistföng virka er leysirinn; ef bæði mistakast er það leiðin.

Nafn getur líka leyst í vistfang utan leiða ganganna, sem blandar árangri og tímanum. Berðu saman vistfangið sem kom til baka við forskeytið í færslunni þinni; ef þau eru ólík svarar einkasvæðið með opinberu eða öðru vistfangi og leiðin sem passaði er ekki sú hönnuða.

Skref 5: Athugaðu síur, auðkenni og eigið hlið forritsins

Umferðarsíur takmarka hvaða siðareglur og port mega nota tækjagöngin, og þröngt mengi getur lokað auðlind sem leiðin myndi bera. Sniðið úthlutar tengingunni til flokks, en auðlindin hefur sína eigin heimild: notandi sem getur tengst er ekki sjálfkrafa samþykktur af skráarþjóninum.

Breyttu stýrða sniðinu í gegnum eiganda þess, hvort sem er Intune, dreifing ProfileXML eða rekstrarskript, og prófaðu svo aftur eftir venjulega endurtengingu og eftir endurræsingu: venjulega bilunin er úrelt staðbundin leið eða snið sem var beitt einu sinni. Haltu útgáfu sniðsins við hlið prófniðurstöðunnar.