Always On VPN er ikke LAN-tilgang: en sjekkliste for ressurser

Always On er en tilkoblingslivssyklus: profilen kobler til ved eller før pålogging og kobler til igjen uten at brukeren trykker på noe. Det betyr ikke at hver privat destinasjon, protokoll og bruker er tillatt. Det praktiske spørsmålet er hvilke ressurser den utrullede profilen faktisk leverer, og svaret krever en sjekk per ressurs, ikke et blikk på Connected-merket.

Trinn 1: Skriv ned ressursen før du tester den

Start med én kort post per applikasjon, hentet fra det virkelige miljøet: navn, destinasjonsprefiks, tjeneste 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 tvinger fram fire separate spørsmål. En rute avgjør hvor adressen går; en DNS-policy avgjør hvordan klienten lærer adressen; et trafikkfilter avgjør om trafikken får bruke tilkoblingen; destinasjonens brannmur og applikasjonens tillatelser avgjør om forespørselen godtas. Ingen av de fire følger av en tilkoblet tunnel.

Trinn 2: Bestem hvilken tunnel som skal bære den

Windows Always On VPN har en enhetstunnel og en brukertunnel, konfigurert som separate profiler med separate sertifikater og omfang. Enhetstunnelen bærer vanligvis bare infrastrukturen som trengs før pålogging, som administrasjon og domenetjenester; bred applikasjonstilgang for ansatte hører til brukertunnelen.

Trafikkfiltre er en funksjon i enhetstunnelen, og derfor bruker Microsofts eksempel dem til administrasjonstrafikk. Kopierer du det eksempelet inn i en generell ressurspolicy, får du en tunnel som kobler til, men bærer feil sett. Bekreft den aktive tilkoblingen med Get-VpnConnection og test under den tilkoblingen.

Trinn 3: Verifiser ruten for den virkelige adressen

Slå opp navnet én gang, og kontroller deretter ruten: Find-NetRoute -RemoteIPAddress 10.20.5.10 viser valgt grensesnitt, neste hopp og kildeadresse. Er grensesnittet den fysiske adapteren, mangler prefikset i tunnelens rutesett, eller klienten har utelukket det via delt tunnel. Sammenlign med profildefinisjonen i stedet for å legge til en lokal rute.

En lokal route add kan få testen til å bestå og forsvinne ved neste policyoppdatering, så endringen hører hjemme i den administrerte profilen. Kontroller prefikset i både bruker- og enhetsprofilen, og kontroller innstillingen for delt tunnel: full tunnel trenger ingen rute per prefiks, delt tunnel trenger én for hvert private prefiks.

Trinn 4: Test navneoppslag for private navn separat

Private navn har sin egen policysti. Profilen kan levere NRPT-regler og en søkeliste for DNS-suffikser, gyldige mens tunnelen er oppe. Les med Get-DnsClientNrptPolicy hva klienten faktisk fikk, og test deretter et navn og en adresse i samme økt. Navn som feiler mens adresser virker, peker på resolveren; begge som feiler peker på ruten.

Et navn kan også slås opp til en adresse utenfor tunnelens ruter, noe som blander suksess og tidsavbrudd. Sammenlign adressen som kom tilbake med prefikset i posten din; er de forskjellige, svarer den private sonen med en offentlig eller alternativ adresse, og ruten som passet er ikke den designede.

Trinn 5: Kontroller filtre, identitet og applikasjonens egen port

Trafikkfiltre begrenser hvilke protokoller og porter som får bruke enhetstunnelen, og et smalt sett kan blokkere en ressurs som ruten ellers ville bære. Profilen tildeler tilkoblingen til en gruppe, men ressursen har sin egen autorisasjon: en bruker som kan koble til, godtas ikke automatisk av filserveren.

Endre den administrerte profilen gjennom eieren, enten det er Intune, en ProfileXML-utrulling eller et driftsskript, og test deretter på nytt etter en normal gjenoppkobling og etter en omstart: den vanlige feilen er en utdatert lokal rute eller en profil som bare ble brukt én gang. Oppbevar profilversjonen ved siden av testresultatet.