Always On VPN nav LAN piekļuve: resursu pārbaudes saraksts

Always On ir savienojuma dzīves cikls: profils pieslēdzas pieteikšanās laikā vai pirms tam un atkal pieslēdzas bez jebkādas lietotāja darbības. Tas nenozīmē, ka ir atļauts katrs privātais galamērķis, protokols un lietotājs. Praktiskais jautājums ir, kādus resursus izvietotais profils patiešām piegādā, un atbildei nepieciešama pārbaude katram resursam, nevis skatiens uz Connected zīmi.

1. solis: pierakstiet resursu pirms pārbaudes

Sāciet ar īsu ierakstu katrai lietotnei, ņemtu no reālās vides: nosaukums, galamērķa prefikss, pakalpojums un ports, tuneļa loma, identitātes grupa un atrisinātāja ceļš.

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

Ieraksts uzspiež četrus atsevišķus jautājumus. Maršruts izlemj, kurp iet adrese; DNS politika izlemj, kā klients uzzina adresi; satiksmes filtrs izlemj, vai šī satiksme drīkst izmantot savienojumu; galamērķa ugunsmūris un lietotnes atļaujas izlemj, vai pieprasījums tiks pieņemts. Neviens no četriem neizriet no pieslēgta tuneļa.

2. solis: nosakiet, kuram tunelim tas jānes

Windows Always On VPN ir ierīces tunelis un lietotāja tunelis, kas konfigurēti kā atsevišķi profili ar atsevišķiem sertifikātiem un tvērumiem. Ierīces tunelis parasti nes tikai pirms pieteikšanās nepieciešamo infrastruktūru, piemēram, pārvaldību un domēna pakalpojumus; plašā darbinieku piekļuve lietotnēm pieder lietotāja tunelim.

Satiksmes filtri ir ierīces tuneļa funkcija, tāpēc Microsoft piemērs tos izmanto pārvaldības satiksmei. Kopējot šo piemēru vispārīgā resursu profilā, iegūst tuneli, kas pieslēdzas, bet nes nepareizo kopu. Apstipriniet aktīvo savienojumu ar Get-VpnConnection un pārbaudiet tieši šajā savienojumā.

3. solis: pārbaudiet maršrutu reālajai adresei

Atrisiniet nosaukumu vienreiz, tad pārbaudiet maršrutu: Find-NetRoute -RemoteIPAddress 10.20.5.10 parāda izvēlēto saskarni, nākamo lēcienu un avota adresi. Ja saskarne ir fiziskais adapteris, prefiksa nav tuneļa maršrutu kopā vai klients to izslēdza ar sadalīto tuneli. Salīdziniet ar profila definīciju, nevis pievienojiet lokālu maršrutu.

Lokāls route add var ļaut testam izturēt un pazust nākamajā politikas atsvaidzinājumā, tāpēc izmaiņa pieder pārvaldītajam profilam. Pārbaudiet prefiksu gan lietotāja, gan ierīces profilā un sadalītā tuneļa iestatījumu: pilnajam tunelim nav vajadzīgs maršruts katram prefiksam, sadalītajam vajag vienu katram privātajam prefiksam.

4. solis: atsevišķi pārbaudiet privāto nosaukumu atrisināšanu

Privātajiem nosaukumiem ir savs politikas ceļš. Profils var piegādāt NRPT kārtulas un DNS sufiksu meklēšanas sarakstu, kas ir spēkā, kamēr tunelis ir uzcelts. Izlasiet ar Get-DnsClientNrptPolicy, ko klients patiešām saņēma, tad tajā pašā sesijā pārbaudiet nosaukumu un adresi. Ja nosaukumi krīt, kamēr adreses strādā, vainīgs ir atrisinātājs; ja abi, tad maršruts.

Nosaukums var atrisināties arī uz adresi ārpus tuneļa maršrutiem, kas sajauc panākumus ar noildzi. Salīdziniet atgriezto adresi ar prefiksu savā ierakstā; ja tās atšķiras, privātā zona atbild ar publisku vai alternatīvu adresi, un sakritušais maršruts nav projektētais.

5. solis: pārbaudiet filtrus, identitāti un pašas lietotnes vārtus

Satiksmes filtri ierobežo, kuri protokoli un porti drīkst izmantot ierīces tuneli, un šaura kopa var bloķēt resursu, ko maršruts nestu. Profils piešķir savienojumu grupai, bet resursam ir sava autorizācija: lietotājs, kurš var pieslēgties, netiek automātiski pieņemts failu serverī.

Mainiet pārvaldīto profilu caur tā īpašnieku, vai tas būtu Intune, ProfileXML izvietošana vai operāciju skripts, tad atkārtojiet testu pēc parastas atkārtotas pieslēgšanās un pēc pārstartēšanas: parastā kļūda ir novecojis lokālais maršruts vai vienreiz piemērots profils. Glabājiet profila versiju blakus testa rezultātam.