Windows-VPN-sneller per toepassing teenoor verdeelde tonnel: wat isoleer
’n Windows-VPN-profiel met ’n toepassingsneller maak net ’n tonnel oop. ’n Verdeelde tonnel met roetes bepaal wat daarin gaan, en elkeen faal anders vir een toepassing.
Twee Windows-opstellings lyk dieselfde in Instellings en gedra hulle heeltemal anders. Die een is ’n gekopieerde VPN-profiel met ’n toepassingsneller, sodat die begin van een uitvoerbare lêer die tonnel oopmaak. Die ander is ’n profiel met verdeelde tonnel waarvan die roetelys toevallig dek waarmee daardie toepassing praat. Die eerste antwoord wanneer die tonnel bestaan. Die tweede antwoord watter pakkette daarin gaan, en net die tweede laat die res van die masjien op die fisiese skakel terwyl die toepassing verbind bly.
Die sneller is ’n lewensiklusreël, nie ’n roetereël nie
Add-VpnConnectionTriggerApplication bind ’n uitvoerbare pad aan ’n profielnaam. Wanneer daardie proses begin, skakel die Remote Access Connection Manager die profiel, en wanneer die snellertoestand eindig, kan die verbinding val. Niks in daardie uitruiling ondersoek sokette nie. Die cmdlet het ’n verhoogde shell nodig, die volle pad na die binêre lêer, en -Force wanneer jy ’n bestaande inskrywing vervang. Bevestig dat die assosiasie behoue gebly het met Get-VpnConnectionTrigger in plaas daarvan om die prompt te vertrou; Microsoft se verwysing vir Add-VpnConnectionTriggerApplication lys die parameters en die voorbeelde.
Twee beperkings verduidelik die meeste berigte dat “die sneller niks doen”. Snellers is rondom profiele vir alle gebruikers gebou, so die profielomvang is die eerste ding om te bepaal, en die toepassingspad moet ooreenstem met die binêre lêer wat werklik loop, nie met ’n kortpad of ’n laaier wat ’n tweede proses begin nie. Die ander beperking is opsetlik: op ’n netwerk wat Windows as vertrou klassifiseer, bly die sneller onaktief, want die profiel is bedoel om weg van die kantoor te werk.
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,AllUserConnectionVerdeelde tonnel bepaal wat die tonnel oorsteek
Met verdeelde tonnel af, installeer Windows ’n klasgebaseerde standaardroete met ’n lae metrieke waarde op die VPN-koppelvlak. Elke soket volg dit, insluitend die blaaier en die opdateringsdiens, so ’n sneller in daardie opset skuif die hele masjien solank die profiel gekoppel is. Die sneller is steeds net ’n lewensiklusreël; die skadeomvang kom van die roete.
Met verdeelde tonnel aan, dra die profiel net die voorvoegsels wat die gateway stoot of wat jy by die VPN-koppelvlak voeg. Alles anders bly die fisiese standaardroete gebruik. Dit is die reëling wat mense gewoonlik bedoel met “een toepassing deur ’n aparte uitgang”, en dit is van begin tot end ’n roetebesluit.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixWaar ’n verdeelde tonnel met roetes ophou om jou toepassing te isoleer
Die algemene fout is ’n bestemming wat nooit in die tonnel se roetelys verskyn nie. ’n Toepassing wat by een adres aanmeld en dan van ’n CDN stroom, of ’n dosyn roterende eindpunte oplos, sal sommige verbindings op die VPN-koppelvlak plaas en die res op Wi-Fi. IPv6 is ’n aparte tabel, so ’n profiel wat net IPv4-voorvoegsels stoot, kan korrek lyk terwyl die toepassing se IPv6-verkeer plaaslik bly.
Twee kleiner effekte maak net soveel saak. Langste-voorvoegsel-passing wen, so ’n meer spesifieke skakelroete, ’n /32 wat vir ’n bestuurhost gestoot word, of ’n tweede adapter se subnet kan die tonnel klop vir juis die adres waarvoor jy sorg. Naamoplossing gebeur ook voor roetering: tensy die profiel se DNS-bediener of ’n NRPT-reël die naam dek, kan die toepassing deur die fisiese adapter oplos en dan ’n adres skakel wat nooit binne die tonnelde voorvoegsels was nie.
Drie vorms, en wat elkeen koop
Die tabel is die deel wat ek aan die muur sou plak, want die besluit gaan oor skadeomvang eerder as funksies. As die toepassing se bestemmings stabiele voorvoegsels is wat jy kan lys, gee die verdeelde tonnel met roetes isolasie met die kleinste voetspoor. As dit nie is nie, hou ’n standaardroeteprofiel agter ’n VM of ’n tweede toestel die skeiding eerlik ten koste van meer as een proses.
| 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 nie een van hierdie bied nie, is soketvlak-binding op die gasheer. Die klassieke Windows-VPN-kliënt het geen reël wat sê hierdie proses moet daardie adapter gebruik nie; snellers en roetefilters woon in verskillende lae, en die laag wat ’n koppelvlak kies, is die roetetabel. As ’n gids per-toepassing-afdwinging belowe uit ’n gekopieerde profiel alleen, vra watter roete of watter filter die werk doen.
Verifieer die paar in een pas
Toets die lewensiklus en die roetering afsonderlik, in daardie volgorde. Maak die toepassing toe, bevestig dat die profiel Ontkoppel wys, begin dan die toepassing en kyk of die toestand verander het. Eers nadat die tonnel op is, moet jy vra waar ’n spesifieke bestemming heen gaan, en jy moet die adres gebruik wat die toepassing werklik skakel eerder as ’n raaiskoot.
$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 noem die koppelvlak en die volgende sprong wat daardie bestemming sou dra. ’n Fisiese alias daar beteken die tonnel is op en irrelevant vir daardie vloei: kyk na die gestote voorvoegsels, dan die meer spesifieke roetes, dan IPv6. As die toestand glad nie verander nie, het die sneller nie gewerk nie, en die uitvoerbare pad, die profielomvang en die VPN-kliënt se bedryfslog is die drie plekke om te kyk.
Maak skoon in omgekeerde orde sodat die volgende toets eerlik is
Verwyder in die omgekeerde orde waarin jy gebou het: eers die toepassingsneller, dan die profiel. Om die profiel te skrap terwyl die sneller bly, laat ’n hangende assosiasie wat die volgende poging verwarrend maak, en Remove-VpnConnection -Force maak nie altyd ’n telefoonboekinskrywing skoon wat buite die cmdlets geskep is nie.
Inskrywings per gebruiker woon in die gebruiker se rasphone.pbk onder die Roaming-profiel; inskrywings vir alle gebruikers woon onder ProgramData. Kyk na die stoor wat by die profielomvang pas, koppel weer die profiel wat jy gehou het, en bevestig dat sy roetes en DNS nog werk, sodat ’n latere toets die verandering meet wat jy gemaak het eerder as oorblywende toestand.
- Tonnel begin by prosesbegin, nie by aanmelding nie.
- Net die bedoelde voorvoegsels verskyn op die VPN-koppelvlak.
- Die toepassing se werklike afgeleë adres los op na die VPN-alias.
- Geen hangende sneller bly oor nadat die profiel verwyder is nie.