Always On VPN er ikkje LAN-tilgang: ei sjekkliste for ressursar

Always On er livssyklusen til ei tilkopling: profilen koplar til ved eller før innlogging og koplar til att utan at brukaren trykkjer på noko. Det tyder ikkje at kvar privat destinasjon, protokoll og brukar er tillaten. Det praktiske spørsmålet er kva ressursar den utrulla profilen faktisk leverer, og svaret krev ein sjekk per ressurs, ikkje eit blikk på Connected-merket.

Steg 1: Skriv ned ressursen før du testar han

Byrj med ein kort post per program, henta frå det verkelege miljøet: namn, destinasjonsprefiks, teneste og port, tunnelrolle, identitetsgruppe og resolversti.

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

Posten tvingar fram fire skilde spørsmål. Ei rute avgjer kvar adressa går; ein DNS-politikk avgjer korleis klienten lærer adressa; eit trafikkfilter avgjer om trafikken får bruke tilkoplinga; brannmuren og programløyva på destinasjonen avgjer om førespurnaden vert teken imot. Ingen av dei fire følgjer av ein tilkopla tunnel.

Steg 2: Avgjer kva tunnel som skal bera han

Windows Always On VPN har ein einingstunnel og ein brukartunnel, sette opp som skilde profilar med skilde sertifikat og omfang. Einingstunnelen ber vanlegvis berre infrastrukturen som trengst før innlogging, som administrasjon og domenetenester; brei programtilgang for tilsette høyrer til brukartunnelen.

Trafikkfilter er ein funksjon i einingstunnelen, og difor nyttar dømet frå Microsoft dei til administrasjonstrafikk. Kopierer du det dømet inn i ein generell ressursprofil, får du ein tunnel som koplar til men ber feil sett. Stadfest den aktive tilkoplinga med Get-VpnConnection og test under den tilkoplinga.

Steg 3: Stadfest ruta for den verkelege adressa

Løys namnet éin gong og kontroller deretter ruta: Find-NetRoute -RemoteIPAddress 10.20.5.10 viser valt grensesnitt, neste hopp og kjeldeadresse. Er grensesnittet den fysiske adapteren, manglar prefikset i rutesettet til tunnelen, eller klienten har utelukka det via delt tunnel. Samanlikn med profildfinisjonen i staden for å leggje til ei lokal rute.

Ei lokal route add kan få testen til å gå gjennom og forsvinne ved neste policyoppdatering, så endringa høyrer heime i den styrte profilen. Kontroller prefikset i både brukar- og einingprofilen, og kontroller innstillinga for delt tunnel: full tunnel treng ikkje rute per prefiks, delt tunnel treng éi for kvar privat prefiks han ber.

Steg 4: Test namneløysing for private namn separat

Private namn har sin eigen politikkveg. Profilen kan levera NRPT-reglar og ei søkjliste for DNS-suffiks, gyldige medan tunnelen er oppe. Les med Get-DnsClientNrptPolicy kva klienten faktisk fekk, og test deretter eit namn og ei adresse i same økta. Namn som fell medan adresser verkar, peikar på resolveren; begge som fell peikar på ruta.

Eit namn kan også løysast til ei adresse utanfor rutene til tunnelen, noko som blandar suksess og tidsavbrot. Samanlikn adressa som kom attende med prefikset i posten din; er dei ulike, svarar den private sona med ei open eller alternativ adresse, og ruta som passa er ikkje den designa.

Steg 5: Kontroller filter, identitet og den eigne porten til programmet

Trafikkfilter avgrensar kva protokollar og portar som får bruke einingstunnelen, og eit smalt sett kan blokkere ein ressurs som ruta elles ville bera. Profilen tildeler tilkoplinga til ei gruppe, men ressursen har si eiga autorisasjon: ein brukar som kan kople til, vert ikkje automatisk teken imot av filtenaren.

Endre den styrte profilen gjennom eigaren, anten det er Intune, ei ProfileXML-utrulling eller eit driftsskript, og test deretter på nytt etter ei vanleg attkopling og etter ein omstart: den vanlege feilen er ei utdatert lokal rute eller ein profil som berre vart brukt éin gong. Hald profilversjonen ved sida av testresultatet.