Windows VPN-utløysar per app kontra delt tunnel: kva isolerer
Ein app-utløyst Windows VPN-profil startar berre ein tunnel. Ein ruta delt tunnel avgjer kva som kjem inn i han, og kvar av dei feilar ulikt for éin app.
To Windows-oppsett ser like ut i Innstillingar og oppfører seg heilt ulikt. Det eine er ein kopiert VPN-profil med ein applikasjonsutløysar, slik at start av éi køyrbar fil reiser tunnelen. Det andre er ein profil med delt tunnel der rutenettet tilfeldigvis dekkjer det den applikasjonen snakkar med. Den første svarar når tunnelen finst. Den andre svarar kva pakkar som kjem inn i han, og berre den andre lèt resten av maskina bli på den fysiske lenkja medan appen blir verande tilkopla.
Utløysaren er ein livssyklusregel, ikkje ein ruteringsregel
Add-VpnConnectionTriggerApplication binder ein køyrbar bane til eit profilnamn. Når den prosessen startar, ringer Remote Access Connection Manager opp profilen, og når utløysartilstanden tek slutt, kan tilkoplinga falle. Ingenting i den utvekslinga granskar sockets. Cmdleten treng eit forhøgd shell, den fulle banen til binæra og -Force når du byter ut ei eksisterande oppføring. Stadfest at tilknytinga overlevde med Get-VpnConnectionTrigger i staden for å stole på ledeteksta; Microsoft sin referanse for Add-VpnConnectionTriggerApplication listar opp parametrane og døma.
To grenser forklarer dei fleste meldingane om at «utløysaren ikkje gjer noko». Utløysarar er bygde rundt profilar for alle brukarar, så profilomfanget er det første som må avklarast, og applikasjonsbanen må samsvare med binæra som faktisk køyrer, ikkje ei snøggveg eller ein oppstartar som startar ein andre prosess. Den andre grensa er tilsikta: på eit nettverk Windows klassifiserer som klarert, blir utløysaren inaktiv, fordi profilen er meint å verke utanfor 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 avgjer kva som kryssar tunnelen
Med delt tunnel av installerer Windows ei klassebasert standardrute med låg metrikk på VPN-grensesnittet. Kvar socket følgjer henne, inkludert nettlesaren og oppdateringstenesta, så ein utløysar i den konfigurasjonen flyttar heile maskina så lenge profilen er tilkopla. Utløysaren er framleis berre ein livssyklusregel; skaderadiusen kom frå ruta.
Med delt tunnel på ber profilen berre prefiksa som gatewayen dytter, eller som du legg til på VPN-grensesnittet. Alt anna held fram med å bruke den fysiske standardruta. Det er ordninga folk vanlegvis meiner med «éin app gjennom ein separat utgang», og det er ei ruteringsavgjerd frå ende til annan.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix
Der ei ruta deling sluttar å isolere appen din
Den vanlege feilen er ein destinasjon som aldri dukkar opp på rutelista til tunnelen. Ein app som loggar på mot éi adresse og deretter strøymer frå eit CDN, eller løyser opp eit dusin roterande endepunkt, vil leggje nokre tilkoplingar på VPN-grensesnittet og resten på Wi-Fi. IPv6 er ei eiga tabell, så ein profil som berre dytter IPv4-prefiks kan sjå riktig ut medan IPv6-trafikken til appen blir lokal.
To mindre effektar tyder like mykje. Lengste prefiks vinn, så ei meir spesifikk on-link-rute, eit /32 dytta for ein administrasjonsvert eller subnettet til ein andre adapter kan slå tunnelen for nøyaktig den adressa du bryr deg om. Oppslag skjer òg før rutering: med mindre DNS-servarane til profilen eller ein NRPT-regel dekkjer namnet, kan appen slå opp gjennom den fysiske adapteren og deretter ringe ei adresse som aldri var inne i dei tunneliserte prefiksa.
Tre former, og kva kvar av dei kjøper
Tabellen er den delen eg ville teipa på veggen, fordi avgjerda handlar om skaderadius og ikkje funksjonar. Viss destinasjonane til appen er stabile prefiks du kan liste, gir den ruta delinga isolasjon med det minste fotavtrykket. Viss ikkje, held ein standardruteprofil bak ein VM eller ein annan eining skillet ærleg på kostnad av å flytte meir enn éin prosess.
| 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 |
Det ingen av desse gir, er binding på socketnivå på verten. Den klassiske Windows VPN-klienten har ingen regel som seier at denne prosessen må bruke den adapteren; utløysarar og rutefilter lever i ulike lag, og laget som vel eit grensesnitt er rutetabellen. Viss ei rettleiing lovar handheving per app berre frå ein kopiert profil, spør kva rute eller kva filter som gjer jobben.
Verifiser paret i éin runde
Test livssyklusen og ruteringa kvar for seg, i den rekkjefølgja. Lat appen att, stadfest at profilen rapporterer Disconnected, start deretter appen og sjekk at tilstanden endra seg. Først når tunnelen er oppe bør du spørje kvar ein bestemt destinasjon går, og du bør bruke adressa appen faktisk ringer, ikkje ei gissing.
$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 namngir grensesnittet og neste hopp som ville bera den destinasjonen. Eit fysisk alias der tyder at tunnelen er oppe og irrelevant for den straumen: sjekk dei dytta prefiksa, deretter dei meir spesifikke rutene, deretter IPv6. Viss tilstanden ikkje endrar seg i det heile, vart ikkje utløysaren utløyst, og banen til den køyrbare fila, profilomfanget og driftloggen til VPN-klienten er dei tre stadene å sjå.
Rydd ordentleg slik at neste test er ærleg
Fjern i motsett rekkjefølgje av det du bygde: applikasjonsutløysaren først, deretter profilen. Sletting av profilen medan utløysaren blir, etterlèt ei hengjande tilknyting som gjer neste forsøk forvirrande, og Remove-VpnConnection -Force fjerner ikkje alltid ei telefonbokoppføring som vart oppretta utanfor cmdletane.
Oppføringar per brukar ligg i brukaren sin rasphone.pbk under Roaming-profilen; oppføringar for alle brukarar ligg under ProgramData. Sjekk lageret som passar til profilomfanget, kople til profilen du behaldt på nytt, og stadfest at rutene og DNS framleis oppfører seg, slik at ein seinare test måler endringa du gjorde og ikkje gjenverande tilstand.
- Tunnelen startar ved prosessstart, ikkje ved pålogging.
- Berre dei tiltenkte prefiksa viser seg på VPN-grensesnittet.
- Den faktiske eksterne adressa til appen blir løyst opp til VPN-aliaset.
- Ingen hengjande utløysar er igjen etter at profilen er fjerna.