Windows VPN-utløser per app kontra delt tunnel: hva isolerer

To Windows-oppsett ser like ut i Innstillinger og oppfører seg helt forskjellig. Det ene er en kopiert VPN-profil med en applikasjonsutløser, slik at start av én kjørbar fil reiser tunnelen. Det andre er en delt tunnel-profil der rutenettet tilfeldigvis dekker det den applikasjonen snakker med. Den første svarer når tunnelen finnes. Den andre svarer hvilke pakker som kommer inn i den, og bare den andre lar resten av maskinen bli på den fysiske lenken mens appen forblir tilkoblet.

Utløseren er en livssyklusregel, ikke en ruteringsregel

Add-VpnConnectionTriggerApplication binder en kjørbar bane til et profilnavn. Når den prosessen starter, ringer Remote Access Connection Manager opp profilen, og når utløsertilstanden tar slutt, kan tilkoblingen falle. Ingenting i den utvekslingen undersøker sockets. Cmdleten trenger et forhøyet shell, den fulle banen til binæren og -Force når du erstatter en eksisterende oppføring. Bekreft at tilknytningen overlevde med Get-VpnConnectionTrigger i stedet for å stole på ledeteksten; Microsofts referanse for Add-VpnConnectionTriggerApplication lister opp parameterne og eksemplene.

To grenser forklarer de fleste meldingene om at «utløseren ikke gjør noe». Utløsere er bygget rundt profiler for alle brukere, så profilomfanget er det første som må avklares, og applikasjonsbanen må samsvare med binæren som faktisk kjører, ikke en snarvei eller en oppstarter som starter en andre prosess. Den andre grensen er tilsiktet: på et nettverk Windows klassifiserer som klarert, blir utløseren inaktiv, fordi profilen er ment å virke utenfor kontoret.

Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnection

Delt tunnel avgjør hva som krysser tunnelen

Med delt tunnel av installerer Windows en klassebasert standardrute med lav metrikk på VPN-grensesnittet. Hver socket følger den, inkludert nettleseren og oppdateringstjenesten, så en utløser i den konfigurasjonen flytter hele maskinen så lenge profilen er tilkoblet. Utløseren er fortsatt bare en livssyklusregel; skaderadiusen kom fra ruten.

Med delt tunnel på bærer profilen bare prefiksene som gatewayen dytter, eller som du legger til på VPN-grensesnittet. Alt annet fortsetter å bruke den fysiske standardruten. Det er ordningen folk vanligvis mener med «én app gjennom en separat utgang», og det er en ruteringsavgjørelse fra ende til annen.

Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix

Der en rutet deling slutter å isolere appen din

Den vanlige feilen er en destinasjon som aldri dukker opp på tunnelens ruteliste. En app som logger på mot én adresse og deretter strømmer fra et CDN, eller løser opp et dusin roterende endepunkter, vil legge noen tilkoblinger på VPN-grensesnittet og resten på Wi-Fi. IPv6 er en egen tabell, så en profil som bare dytter IPv4-prefikser kan se riktig ut mens appens IPv6-trafikk blir lokal.

To mindre effekter betyr like mye. Lengste prefiks vinner, så en mer spesifikk on-link-rute, et /32 dyttet for en administrasjonsvert eller subnettet til en andre adapter kan slå tunnelen for nøyaktig den adressen du bryr deg om. Oppslag skjer også før rutering: med mindre profilens DNS-servere eller en NRPT-regel dekker navnet, kan appen slå opp gjennom den fysiske adapteren og deretter ringe en adresse som aldri var inne i de tunneliserte prefiksene.

Tre former, og hva hver av dem kjøper

Tabellen er den delen jeg ville teipet på veggen, fordi avgjørelsen handler om skaderadius og ikke funksjoner. Hvis appens destinasjoner er stabile prefikser du kan liste, gir den rutede delingen isolasjon med det minste fotavtrykket. Hvis ikke, holder en standardruteprofil bak en VM eller en annen enhet skillet ærlig på bekostning av å flytte mer enn én prosess.

Det ingen av disse gir, er binding på socketnivå på verten. Den klassiske Windows VPN-klienten har ingen regel som sier at denne prosessen må bruke den adapteren; utløsere og rutefiltre lever i forskjellige lag, og laget som velger et grensesnitt er rutetabellen. Hvis en veiledning lover håndhevelse per app alene fra en kopiert profil, spør hvilken rute eller hvilket filter som gjør jobben.

Verifiser paret i én runde

Test livssyklusen og ruteringen hver for seg, i den rekkefølgen. Lukk appen, bekreft at profilen rapporterer Disconnected, start deretter appen og sjekk at tilstanden endret seg. Først når tunnelen er oppe bør du spørre hvor en bestemt destinasjon går, og du bør bruke adressen appen faktisk ringer, ikke en gjetning.

$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10

Find-NetRoute navngir grensesnittet og neste hopp som ville bære den destinasjonen. En fysisk alias der betyr at tunnelen er oppe og irrelevant for den strømmen: sjekk de dyttede prefiksene, deretter de mer spesifikke rutene, deretter IPv6. Hvis tilstanden ikke endrer seg i det hele tatt, ble ikke utløseren utløst, og banen til den kjørbare filen, profilomfanget og driftloggen til VPN-klienten er de tre stedene å se.

Rydd ordentlig slik at neste test er ærlig

Fjern i motsatt rekkefølge av det du bygget: applikasjonsutløseren først, deretter profilen. Sletting av profilen mens utløseren blir, etterlater en hengende tilknytning som gjør neste forsøk forvirrende, og Remove-VpnConnection -Force fjerner ikke alltid en telefonbokoppføring som ble opprettet utenfor cmdletene.

Oppføringer per bruker ligger i brukerens rasphone.pbk under Roaming-profilen; oppføringer for alle brukere ligger under ProgramData. Sjekk lageret som passer til profilomfanget, koble til profilen du beholdt på nytt, og bekreft at rutene og DNS fortsatt oppfører seg, slik at en senere test måler endringen du gjorde og ikke gjenværende tilstand.

• Tunnelen starter ved prosessstart, ikke ved pålogging.
• Bare de tiltenkte prefiksene vises på VPN-grensesnittet.
• Appens faktiske eksterne adresse løses opp til VPN-aliaset.
• Ingen hengende utløser er igjen etter at profilen er fjernet.