Always On VPN är inte LAN-åtkomst: en checklista för resurser

Always On är en anslutningslivscykel: profilen ansluter vid eller före inloggning och återansluter utan att användaren trycker på något. Det betyder inte att varje privat destination, protokoll och användare är tillåten. Den praktiska frågan är vilka resurser den utrullade profilen faktiskt levererar, och svaret kräver en kontroll per resurs, inte en blick på märket Connected.

Steg 1: Skriv ned resursen innan du testar den

Börja med en kort post per applikation, hämtad från den verkliga miljön: namn, destinationsprefix, tjänst och port, tunnelroll, identitetsgrupp och resolverväg.

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 fyra separata frågor. En route avgör vart adressen tar vägen; en DNS-princip avgör hur klienten lär sig adressen; ett trafikfilter avgör om trafiken får använda anslutningen; brandväggen och appens behörigheter på destinationen avgör om begäran accepteras. Ingen av de fyra följer av en ansluten tunnel.

Steg 2: Bestäm vilken tunnel som ska bära den

Windows Always On VPN har en enhetstunnel och en användartunnel, konfigurerade som separata profiler med separata certifikat och omfång. Enhetstunneln bär normalt bara den infrastruktur som behövs före inloggning, som hantering och domäntjänster; bred appåtkomst för anställda hör till användartunneln.

Trafikfilter är en funktion i enhetstunneln, och därför använder Microsofts exempel dem för hanteringstrafik. Kopierar du det exemplet till en allmän resursprofil får du en tunnel som ansluter men bär fel uppsättning. Bekräfta den aktiva anslutningen med Get-VpnConnection och testa under den anslutningen.

Steg 3: Verifiera routen för den verkliga adressen

Lös upp namnet en gång och kontrollera sedan routen: Find-NetRoute -RemoteIPAddress 10.20.5.10 rapporterar valt gränssnitt, nästa hopp och källadress. Är gränssnittet det fysiska nätverkskortet saknas prefixet i tunnelns routemängd, eller så har klienten uteslutit det via delad tunnel. Jämför med profilens definition i stället för att lägga till en lokal route.

En lokal route add kan få testet att gå igenom och försvinna vid nästa principuppdatering, så ändringen hör hemma i den hanterade profilen. Kontrollera prefixet i både användar- och enhetsprofilen, och kontrollera inställningen för delad tunnel: full tunnel behöver ingen route per prefix, delad tunnel behöver en för varje privat prefix som den bär.

Steg 4: Testa namnuppslag för privata namn separat

Privata namn har sin egen principväg. Profilen kan leverera NRPT-regler och en söklista för DNS-suffix, giltiga så länge tunneln är uppe. Läs med Get-DnsClientNrptPolicy vad klienten faktiskt fick och testa sedan ett namn och en adress i samma session. Namn som fallerar medan adresser fungerar pekar på resolvern; båda som fallerar pekar på routen.

Ett namn kan också lösas upp till en adress utanför tunnelns routes, vilket blandar framgång med timeout. Jämför den returnerade adressen med prefixet i din post; skiljer de sig svarar den privata zonen med en publik eller alternativ adress och routen som matchade är inte den designade.

Steg 5: Kontrollera filter, identitet och appens egen port

Trafikfilter begränsar vilka protokoll och portar som får använda enhetstunneln, och en smal uppsättning kan blockera en resurs som routen skulle bära. Profilen tilldelar anslutningen till en grupp, men resursen har sin egen auktorisation: en användare som kan ansluta accepteras inte automatiskt av filservern.

Ändra den hanterade profilen via ägaren, vare sig det är Intune, en ProfileXML-utrullning eller ett driftsskript, och testa sedan igen efter en normal återanslutning och efter en omstart: det vanliga felet är en inaktuell lokal route eller en profil som bara tillämpades en gång. Behåll profilversionen bredvid testresultatet.