Always On VPN er ikke LAN-adgang: en tjekliste for ressourcer

Always On er en forbindelseslivscyklus: profilen opretter forbindelse ved eller før logon og genopretter den, uden at brugeren trykker på noget. Det betyder ikke, at hver privat destination, protokol og bruger er tilladt. Det praktiske spørgsmål er, hvilke ressourcer den udrullede profil faktisk leverer, og svaret kræver et tjek pr. ressource, ikke et blik på Connected-mærket.

Trin 1: Skriv ressourcen ned, før du tester den

Start med én kort post pr. applikation, hentet fra det virkelige miljø: navn, destinationspræfiks, 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 fire adskilte spørgsmål. En rute afgør, hvor adressen går hen; en DNS-politik afgør, hvordan klienten lærer adressen; et trafikfilter afgør, om trafikken må bruge forbindelsen; destinationens firewall og applikationens tilladelser afgør, om anmodningen accepteres. Intet af de fire følger af en tilsluttet tunnel.

Trin 2: Afgør, hvilken tunnel der skal bære den

Windows Always On VPN har en enhedstunnel og en brugertunnel, konfigureret som separate profiler med separate certifikater og scopes. Enhedstunnelen bærer normalt kun den infrastruktur, der er nødvendig før logon, som administration og domænetjenester; bred applikationsadgang for medarbejdere hører til brugertunnelen.

Trafikfiltre er en funktion i enhedstunnelen, og derfor bruger Microsofts eksempel dem til administrationstrafik. Kopierer man det eksempel ind i en generel ressourceprofil, får man en tunnel, der forbinder, men bærer det forkerte sæt. Bekræft den aktive forbindelse med Get-VpnConnection, og test under den forbindelse.

Trin 3: Verificér ruten for den rigtige adresse

Slå navnet op én gang, og kontrollér derefter ruten: Find-NetRoute -RemoteIPAddress 10.20.5.10 viser den valgte grænseflade, næste hop og kildeadresse. Er grænsefladen den fysiske adapter, mangler præfikset i tunnelens rutesæt, eller klienten har udelukket det via split tunnelling. Sammenlign med profildefinitionen i stedet for at tilføje en lokal rute.

En lokal route add kan få testen til at bestå og forsvinde ved næste politikopdatering, så ændringen hører i den administrerede profil. Kontrollér præfikset i både bruger- og enhedsprofilen, og kontrollér indstillingen for split tunnelling: fuld tunnel kræver ingen rute pr. præfiks, split tunnel kræver én for hvert privat præfiks.

Trin 4: Test navneopløsning for private navne separat

Private navne er deres egen politiksti. Profilen kan levere NRPT-regler og en DNS-suffikssøgeliste, der gælder, mens tunnelen er oppe. Læs med Get-DnsClientNrptPolicy, hvad klienten faktisk modtog, og test derefter et navn og en adresse i samme session. Navne, der fejler, mens adresser virker, peger på resolveren; begge, der fejler, peger på ruten.

Et navn kan også opløses til en adresse uden for tunnelens ruter, hvilket blander succes med timeout. Sammenlign den returnerede adresse med præfikset i din post; er de forskellige, svarer den private zone med en offentlig eller alternativ adresse, og den rute, der matchede, er ikke den designede.

Trin 5: Kontrollér filtre, identitet og applikationens egen port

Trafikfiltre begrænser, hvilke protokoller og porte der må bruge enhedstunnelen, og et snævert sæt kan blokere en ressource, som ruten ellers ville bære. Profilen tildeler forbindelsen til en gruppe, men ressourcen har sin egen autorisation: en bruger, der kan forbinde, accepteres ikke automatisk af fileserveren.

Ændr den administrerede profil gennem dens ejer, hvad enten det er Intune, en ProfileXML-udrulning eller et driftsskript, og test derefter igen efter en normal genforbindelse og efter en genstart: den typiske fejl er en forældet lokal rute eller en profil, der kun blev anvendt én gang. Gem profilversionen ved siden af testresultatet.