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

Always On er livsløpet til en tilkobling: profilen kobler opp ved eller før pålogging og kobler opp igjen uten at brukeren rører noe. Det betyr ikke at enhver privat destinasjon, protokoll og bruker er tillatt. Det praktiske spørsmålet er hvilke ressurser den utrullede profilen virkelig leverer, og svaret krever en kontroll per ressurs, ikke et blikk på Connected-merket.

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

Begynn med ett kort notat per applikasjon, hentet fra det virkelige miljøet: navn, prefiks for destinasjonen, tjeneste og port, tunnelrolle, identitetsgruppe og stien til oppslageren.

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

Notatet tvinger fram fire atskilte spørsmål. En rute bestemmer hvor adressen tar veien; en DNS-policy bestemmer hvordan klienten får vite adressen; et trafikkfilter bestemmer om den trafikken kan bruke tilkoblingen; brannmuren og apptillatelsene på destinasjonen bestemmer om forespørselen blir godtatt. Ingen av de fire kommer av seg selv fra en tilkoblet tunnel.

Trinn 2: Avgjør hvilken tunnel som skal bære den

Windows Always On VPN har en enhetstunnel og en brukertunnel, satt opp som atskilte profiler med atskilte sertifikater og virkeområder. Enhetstunnelen bærer som regel bare infrastrukturen som trengs før pålogging, slik som administrasjon og domenetjenester; bred apptilgang for ansatte hører til brukertunnelen.

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

Trinn 3: Kontroller ruten for den faktiske adressen

Slå opp navnet én gang, og sjekk så ruten: Find-NetRoute -RemoteIPAddress 10.20.5.10 rapporterer grensesnittet som ble valgt, neste hopp og kildeadressen. Er grensesnittet det fysiske kortet, mangler prefikset i rutesettet til tunnelen, eller klienten har holdt det utenfor med delt tunnel. Sammenlign med definisjonen av profilen i stedet for å legge inn en lokal rute.

En lokal route add kan få testen til å gå gjennom og forsvinne ved neste policyoppdatering, så endringen hører hjemme i den styrte profilen. Sjekk prefikset i både brukerprofilen og enhetsprofilen, og sjekk innstillingen for delt tunnel: full tunnel trenger ingen rute per prefiks, delt tunnel trenger én for hvert private prefiks den bærer.

Trinn 4: Test oppslag av private navn for seg

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

Et navn kan også slås opp til en adresse utenfor rutene til tunnelen, og det blander suksess med tidsavbrudd. Sammenlign adressen som kom tilbake med prefikset i notatet ditt; er de forskjellige, svarer den private sonen med en offentlig eller alternativ adresse, og ruten som passet er ikke den planlagte.

Trinn 5: Sjekk filtre, identitet og appens egen port

Trafikkfiltre begrenser hvilke protokoller og porter som kan bruke enhetstunnelen, og et smalt sett kan stenge 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 opp, blir ikke automatisk godtatt av filserveren.

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