Windows VPN-trigger per applikaasje tsjin dielde tunnel: wat isolearret
In troch in applikaasje aktivearre Windows VPN-profyl begjint allinnich in tunnel. In rutele dielde tunnel beslút wat der ynkomt, en elk fan beide falt oars út foar ien applikaasje.
Twa Windows-ynstellingen lykje itselde yn Ynstellingen en gedrage har hielendal oars. De iene is in kopiearre VPN-profyl mei in applikaasjetrigger, sadat it starten fan ien útfierber bestân de tunnel omheech hellet. De oare is in profyl mei dielde tunnel wêrfan't de rûtelist tafallich dekt wat dy applikaasje sprekt. De earste antwurdet wannear't de tunnel bestiet. De twadde antwurdet hokker pakketten deryn komme, en allinnich de twadde lit de rest fan 'e masine op 'e fysike link wylst de applikaasje ferbûn bliuwt.
De trigger is in libsensyklusregel, gjin rûtelregel
Add-VpnConnectionTriggerApplication bynt in útfierber paad oan in profylnamme. Wannear't dat proses begjint, skillet de Remote Access Connection Manager it profyl, en wannear't de triggertastân einiget, kin de ferbining falle. Neat yn dy útwikseling besjocht sockets. It cmdlet hat in ferhege shell nedich, it folsleine paad nei it binêre bestân, en -Force wannear't jo in besteande ynfier ferfange. Befêstigje dat de assosjaasje oerlibbe hat mei Get-VpnConnectionTrigger yn plak fan op 'e prompt te fertrouwen; Microsoft syn referinsje foar Add-VpnConnectionTriggerApplication listet de parameters en de foarbylden.
Twa beheiningen ferklearje de measte berjochten dat „de trigger neat docht”. Triggers binne boud om profylen foar alle brûkers hinne, dus it profylberik is it earste ding dat regele wurde moat, en it applikaasjepaad moat oerienkomme mei it binêre bestân dat echt rint, net in fluchtoets of in starter dy't in twadde proses begjint. De oare beheining is mei opsetsin: op in netwurk dat Windows as fertroud klassifisearret, bliuwt de trigger stil, om't it profyl bedoeld is om bûten it kantoar te wurkjen.
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,AllUserConnectionDielde tunnel beslút wat de tunnel oerstekt
Mei dielde tunnel út, ynstallearret Windows in klassebasearre standertrûte mei in lege metryske wearde op 'e VPN-ynterface. Elke socket folget dy, ynklusyf de browser en de fernijingsstsjinst, dus in trigger yn dy konfiguraasje ferpleatst de hiele masine salang't it profyl ferbûn is. De trigger is noch altyd mar in libsensyklusregel; de radius fan effekt kaam fan 'e rûte.
Mei dielde tunnel oan, draacht it profyl allinnich de foarheaksels dy't de gateway triuwt of dy't jo oan 'e VPN-ynterface tafoegje. Al it oare bliuwt de fysike standertrûte brûken. Dat is de regeling dy't minsken meastentiids bedoele mei „ien applikaasje troch in aparte útgong”, en it is fan begjin oant ein in rûtelbeslút.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixWêr't in rutele dieling ophâldt jo applikaasje te isolearjen
De gewoane flater is in bestimming dy't nea yn 'e rûtelist fan 'e tunnel ferskynt. In applikaasje dy't him oanmeldt by ien adres en dan streamt fan in CDN, of in tsiental rotearjende einpunten oplost, sil guon ferbiningen op 'e VPN-ynterface sette en de rest op Wi-Fi. IPv6 is in aparte tabel, dus in profyl dat allinnich IPv4-foarheaksels triuwt, kin der goed útsjen wylst it IPv6-ferkear fan 'e applikaasje lokaal bliuwt.
Twa lytsere effekten telle likefolle. De langste foarheaksel-oerienkomst wint, dus in mear spesifike on-link-rûte, in /32 dy't foar in behearhost triuwd wurdt, of it subnet fan in twadde adapter kinne de tunnel ferslaan foar krekt it adres dat jo oanbelanget. Oplossing bart ek foar it rûteljen: of it moatte de DNS-servers fan it profyl of in NRPT-regel wêze dy't de namme dekke, oars kin de applikaasje fia de fysike adapter oplosse en dan in adres skilje dat nea binnen de tunnelde foarheaksels wie.
Trije foarmen, en wat elk keapet
De tabel is it diel dat ik op 'e muorre plakke soe, om't it beslút oer radius fan effekt giet en net oer funksjes. As de bestimmingen fan 'e applikaasje stabile foarheaksels binne dy't jo listje kinne, jout de rutele dieling isolaasje mei it lytste fuotprint. As dat net sa is, hâldt in standertrûteprofyl efter in VM of in twadde apparaat de skieding earlik tsjin 'e priis fan mear as ien proses ferpleatsen.
| 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 net ien fan dizze biedt, is bining op socketnivo op 'e host. De klassike Windows VPN-klant hat gjin regel dy't seit dat dit proses dy adapter brûke moat; triggers en rûtefilters libje yn ferskillende lagen, en de laach dy't in ynterface kiest, is de rûtetabel. As in gids per-applikaasje-ôftwining ûnthjit fan in kopiearre profyl allinnich, freegje dan hokker rûte of hokker filter it wurk docht.
Ferifiearje it pear yn ien passaazje
Test de libsensyklus en it rûteljen apart, yn dy folchoarder. Slút de applikaasje, befêstigje dat it profyl Disconnected meldt, start dan de applikaasje en kontrolearje dat de tastân feroare is. Pas as de tunnel omheech is, moatte jo freegje wêr't in spesifike bestimming hinne giet, en jo moatte it adres brûke dat de applikaasje echt skillet, net in gruming.
$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 neamt de ynterface en de folgjende hop dy't dy bestimming drage soe. In fysike alias dêr betsjut dat de tunnel omheech is en foar dy stream irrelevant: kontrolearje de triuwde foarheaksels, dan de mear spesifike rûtes, dan IPv6. As de tastân hielendal net feroaret, is de trigger net ôfgien, en it paad fan it útfierbere bestân, it profylberik en it bedriuwslog fan 'e VPN-klant binne de trije plakken om te sykjen.
Romje skjin op sadat de folgjende test earlik is
Ferwiderje yn 'e omkearde folchoarder fan wat jo boud hawwe: earst de applikaasjetrigger, dan it profyl. It profyl wiskje wylst de trigger bliuwt, lit in hingjende assosjaasje efter dy't de folgjende poging ferwarrend makket, en Remove-VpnConnection -Force wisket net altyd in telefoanboekynfier dy't bûten de cmdlets makke is.
Ynfoeren per brûker libje yn it rasphone.pbk fan 'e brûker, ûnder it Roaming-profyl; ynfoeren foar alle brûkers libje ûnder ProgramData. Kontrolearje it argyf dat by it profylberik past, ferbyn it profyl opnij dat jo holden hawwe, en befêstigje dat syn rûtes en DNS noch wurkje, sadat in lettere test de feroaring mjit dy't jo makke hawwe en net oerbliuwende tastân.
- Tunnel begjint by prosesstart, net by oanmelding.
- Allinnich de bedoelde foarheaksels ferskine op 'e VPN-ynterface.
- It echte remote-adres fan 'e applikaasje wurdt oplost nei de VPN-alias.
- Gjin hingjende trigger bliuwt efter nei it ferwiderjen fan it profyl.