Windows-VPN-trigger per app versus split tunneling: wat isoleert
Een door een app geactiveerd Windows-VPN-profiel start alleen een tunnel. Een gerouteerde split tunnel bepaalt wat erin komt, en elk faalt anders voor één app.
Twee Windows-configuraties lijken op elkaar in Instellingen en gedragen zich totaal niet hetzelfde. De ene is een gekopieerd VPN-profiel met een applicatietrigger, zodat het starten van één uitvoerbaar bestand de tunnel opzet. De andere is een split-tunnelprofiel waarvan de routelijst toevallig dekt waar die applicatie mee praat. De eerste antwoordt wanneer de tunnel bestaat. De tweede antwoordt welke pakketten erin gaan, en alleen de tweede laat de rest van de machine op de fysieke link terwijl de app verbonden blijft.
De trigger is een levenscyclusregel, geen routeringsregel
Add-VpnConnectionTriggerApplication koppelt een uitvoerbaar pad aan een profielnaam. Wanneer dat proces start, kiest Verbindingsbeheer voor externe toegang het profiel, en wanneer de triggervoorwaarde eindigt, kan de verbinding wegvallen. Niets in die uitwisseling inspecteert sockets. De cmdlet vereist een verhoogde shell, het volledige pad naar het binaire bestand en -Force wanneer je een bestaande vermelding vervangt. Bevestig dat de koppeling behouden bleef met Get-VpnConnectionTrigger in plaats van de prompt te vertrouwen; de referentie voor Add-VpnConnectionTriggerApplication noemt de parameters en de voorbeelden.
Twee beperkingen verklaren de meeste meldingen dat “de trigger niets doet”. Triggers zijn gebouwd rond profielen voor alle gebruikers, dus het profielbereik is het eerste dat je moet regelen, en het applicatiepad moet overeenkomen met het binaire bestand dat echt draait, niet met een snelkoppeling of een launcher die een tweede proces start. De andere beperking is bewust: op een netwerk dat Windows als vertrouwd classificeert, blijft de trigger inactief, omdat het profiel bedoeld is om buiten kantoor te werken.
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,AllUserConnectionSplit tunneling bepaalt wat de tunnel oversteekt
Met split tunneling uit installeert Windows een op klasse gebaseerde standaardroute met een lage metriek op de VPN-interface. Elke socket volgt die, inclusief de browser en de updatedienst, dus een trigger in die configuratie verplaatst de hele machine zolang het profiel verbonden is. De trigger blijft alleen een levenscyclusregel; de impact kwam van de route.
Met split tunneling aan draagt het profiel alleen de prefixen die de gateway pusht of die je aan de VPN-interface toevoegt. Al het andere blijft de fysieke standaardroute gebruiken. Dat is de opstelling die mensen meestal bedoelen met “één app via een aparte uitgang”, en het is van begin tot eind een routeringsbeslissing.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixWaar een gerouteerde split je app niet meer isoleert
De gebruikelijke fout is een bestemming die nooit in de routelijst van de tunnel verschijnt. Een app die inlogt op één adres en daarna streamt van een CDN, of een dozijn roterende eindpunten resolveert, zet sommige verbindingen op de VPN-interface en de rest op Wi-Fi. IPv6 is een aparte tabel, dus een profiel dat alleen IPv4-prefixen pusht kan er correct uitzien terwijl het IPv6-verkeer van de app lokaal blijft.
Twee kleinere effecten tellen even zwaar. De langste prefixovereenkomst wint, dus een specifiekere on-link-route, een /32 die voor een beheershost wordt gepusht of het subnet van een tweede adapter kan de tunnel verslaan voor precies het adres dat je aangaat. Resolutie gebeurt ook vóór routering: tenzij de DNS-servers van het profiel of een NRPT-regel de naam dekken, kan de app via de fysieke adapter resolven en dan een adres kiezen dat nooit binnen de getunnelde prefixen lag.
Drie vormen, en wat elk oplevert
De tabel is het deel dat ik op de muur zou plakken, want de beslissing gaat over de impact en niet over functies. Als de bestemmingen van de app stabiele prefixen zijn die je kunt opsommen, geeft de gerouteerde split isolatie met de kleinste voetafdruk. Zo niet, dan houdt een standaardrouteprofiel achter een VM of een tweede apparaat de scheiding eerlijk, tegen de prijs dat meer dan één proces wordt verplaatst.
| Shape | What starts the tunnel | What enters it | Pick it when |
|---|---|---|---|
| Trigger plus routed split | Process start | Only pushed or added prefixes | The app's endpoints are stable prefixes and the host should stay direct |
| Trigger plus default route | Process start | Everything, machine-wide | You need one exit for all traffic and accept the wider scope |
| Separate VM or device | Guest boot or login | Everything inside that guest | The app's destinations rotate, or the host must keep its own public address |
Wat geen van deze biedt, is binding op socketniveau op de host. De klassieke Windows-VPN-client heeft geen regel die zegt dat dit proces die adapter moet gebruiken; triggers en routefilters leven in verschillende lagen, en de laag die een interface kiest is de routetabel. Als een gids per-app-handhaving belooft op basis van alleen een gekopieerd profiel, vraag dan welke route of welk filter het werk doet.
Verifieer het paar in één ronde
Test de levenscyclus en de routering afzonderlijk, in die volgorde. Sluit de app, bevestig dat het profiel Disconnected meldt, start dan de app en controleer of de status is veranderd. Pas als de tunnel staat, moet je vragen waar een specifieke bestemming heen gaat, en je moet het adres gebruiken dat de app werkelijk kiest in plaats van een gok.
$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.10Find-NetRoute noemt de interface en de volgende hop die die bestemming zou dragen. Een fysieke alias daar betekent dat de tunnel staat en voor die stroom irrelevant is: controleer de gepushte prefixen, dan de specifiekere routes, dan IPv6. Als de status helemaal niet verandert, is de trigger niet afgegaan, en het pad naar het uitvoerbare bestand, het profielbereik en het operationele log van de VPN-client zijn de drie plekken om te kijken.
Ruim netjes op zodat de volgende test eerlijk is
Verwijder in de omgekeerde volgorde waarin je hebt gebouwd: eerst de applicatietrigger, dan het profiel. Het profiel verwijderen terwijl de trigger blijft, laat een hangende koppeling achter die de volgende poging verwarrend maakt, en Remove-VpnConnection -Force wist niet altijd een telefoonboekvermelding die buiten de cmdlets is gemaakt.
Vermeldingen per gebruiker staan in het rasphone.pbk van de gebruiker onder het Roaming-profiel; vermeldingen voor alle gebruikers staan onder ProgramData. Controleer het archief dat bij het profielbereik past, verbind het bewaarde profiel opnieuw en bevestig dat de routes en DNS nog werken, zodat een latere test de aangebrachte wijziging meet en niet de achtergebleven toestand.
- De tunnel start bij processtart, niet bij aanmelding.
- Alleen de bedoelde prefixen verschijnen op de VPN-interface.
- Het echte externe adres van de app resolveert naar de VPN-alias.
- Er blijft geen hangende trigger achter nadat het profiel is verwijderd.