Windows-per-aplikaĵa VPN-ekigilo kontraŭ dividita tunelo: kio izolas
Per aplikaĵo ekigita Windows VPN-profilo nur malfermas tunelon. Rutigita dividita tunelo decidas kio eniras ĝin, kaj ĉiu malsukcesas alimaniere por unu aplikaĵo.
Du Windows-agordoj aspektas samaj en Agordoj kaj kondutas tute malsame. Unu estas kopiita VPN-profilo kun aplikaĵa ekigilo, do lanĉi unu plenumeblan dosieron levigas la tunelon. La alia estas profilo de dividita tunelo kies voja listo hazarde kovras tion, kun kio parolas tiu aplikaĵo. La unua respondas kiam la tunelo ekzistas. La dua respondas kiuj pakaĵoj eniras ĝin, kaj nur la dua lasas la reston de la maŝino sur la fizika ligo dum la aplikaĵo restas konektita.
La ekigilo estas vivocikla regulo, ne rutiga regulo
Add-VpnConnectionTriggerApplication ligas plenumeblan vojon al profilnomo. Kiam tiu procezo komenciĝas, la Administranto de Foraj Aliraj Kunligoj vokas la profilon, kaj kiam la ekigila kondiĉo finiĝas, la kunligo povas fali. Nenio en tiu interŝanĝo inspektas poŝojn. La komando bezonas altigitan ŝelon, la plenan vojon al la duuma dosiero kaj -Force kiam vi anstataŭigas ekzistantan eron. Konfirmu, ke la ligo postvivis per Get-VpnConnectionTrigger anstataŭ fidi la inviton; la referenco de Add-VpnConnectionTriggerApplication listigas la parametrojn kaj la ekzemplojn.
Du limoj klarigas la plej multajn raportojn, ke „la ekigilo faras nenion“. Ekigiloj estas konstruitaj ĉirkaŭ profiloji por ĉiuj uzantoj, do la profila amplekso estas la unua afero solvenda, kaj la aplikaĵa vojo devas kongrui kun la duuma dosiero kiu vere ruliĝas, ne kun fulmokopio aŭ lanĉilo kiu kreas duan procezon. La alia limo estas intenca: en reto, kiun Windows klasifikas kiel fidindan, la ekigilo restas neaktiva, ĉar la profilo estas destinita funkcii ekster la oficejo.
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
Dividita tunelo decidas kio transiras la tunelon
Kun dividita tunelo malŝaltita, Windows instalas klaskategorian defaŭltan vojon kun malalta metriko sur la VPN-aparataro. Ĉiu poŝo sekvas ĝin, inkluzive la retumilon kaj la ĝisdatigan servon, do ekigilo en tiu agordo movas la tutan maŝinon dum la profilo estas konektita. La ekigilo restas nur vivocikla regulo; la efika radiuso venis de la vojo.
Kun dividita tunelo ŝaltita, la profilo portas nur la prefiksojn kiujn la enirejo puŝas aŭ kiujn vi aldonas al la VPN-aparataro. Ĉio alia daŭre uzas la fizikan defaŭltan vojon. Tio estas la aranĝo, kiun homoj kutime celas per „unu aplikaĵo tra aparta eliro“, kaj ĝi estas rutiga decido de komenco ĝis fino.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix
Kie rutigita divido ĉesas izoli vian aplikaĵon
La kutima fiasko estas celo, kiu neniam aperas en la voja listo de la tunelo. Aplikaĵo, kiu ensalutas kontraŭ unu adreso kaj poste elsendas fluon el CDN, aŭ solvas dekduon da rotaciaj finpunktoj, metos kelkajn kunligojn sur la VPN-aparataro kaj la reston sur Wi-Fi. IPv6 estas aparta tabelo, do profilo kiu puŝas nur IPv4-prefiksojn povas aspekti ĝusta dum la IPv6-trafiko de la aplikaĵo restas loka.
Du pli malgrandaj efikoj same gravas. La plej longa prefiksa kongruo venkas, do pli specifa on-link-vojo, /32 puŝita por administra gastiganto aŭ la subreto de dua adaptilo povas venki la tunelon ĝuste por la adreso, pri kiu vi zorgas. Ankaŭ nomrezolvo okazas antaŭ rutigado: se la DNS-serviloj de la profilo aŭ regulo NRPT ne kovras la nomon, la aplikaĵo povas solvi tra la fizika adaptilo kaj poste voki adreson, kiu neniam estis ene de la tunelitaj prefiksoj.
Tri formoj, kaj kion ĉiu aĉetas
La tabelo estas la parto, kiun mi gluumus sur la muron, ĉar la decido temas pri efika radiuso, ne pri trajtoj. Se la celoj de la aplikaĵo estas stabilaj prefiksoj, kiujn vi povas listigi, la rutigita divido donas izolon kun la plej malgranda spuro. Se ne, defaŭltvoja profilo malantaŭ VM aŭ dua aparato tenas la apartigon honesta je la kosto movi pli ol unu procezon.
| 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 |
Kion neniu el tiuj ofertas estas ligado je poŝa nivelo sur la gastiganto. La klasika Windows VPN-kliento havas neniun regulon, ke ĉi tiu procezo devas uzi tiun adaptilon; ekigiloj kaj vojaj filtriloj vivas en diversaj tavoloj, kaj la tavolo, kiu elektas aparataron, estas la vojtkabelo. Se gvidilo promesas per-aplikaĵan devigon nur el kopiita profilo, demandu, kiu vojo aŭ kiu filtrilo faras la laboron.
Kontrolu la paron en unu paso
Testu la vivociklon kaj la rutigadon aparte, en tiu ordo. Fermu la aplikaĵon, konfirmu ke la profilo raportas Disconnected, poste lanĉu la aplikaĵon kaj kontrolu, ĉu la stato ŝanĝiĝis. Nur post kiam la tunelo staras vi devus demandi, kien iras difinita celo, kaj vi devus uzi la adreson, kiun la aplikaĵo vere vokas, anstataŭ konjekto.
$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 nomas la aparataron kaj la sekvan salteton, kiu portus tiun celon. Fizika kaŝnomo tie signifas, ke la tunelo staras kaj estas nerelevanta por tiu fluo: kontrolu la puŝitajn prefiksojn, poste la pli specifajn vojojn, poste IPv6. Se la stato tute ne ŝanĝiĝas, la ekigilo ne ekigis, kaj la vojo de la plenumebla dosiero, la profila amplekso kaj la operacia registro de la VPN-kliento estas la tri lokoj por rigardi.
Purigu dece, por ke la sekva testo estu honesta
Forigu en la inversa ordo ol vi konstruis: unue la aplikaĵan ekigilon, poste la profilon. Forigi la profilon dum la ekigilo restas lasas pendantan ligon, kiu konfuzas la sekvan provon, kaj Remove-VpnConnection -Force ne ĉiam purigas telefonlibran eron kreitan ekster la komandoj.
Eroj por uzanto troviĝas en la rasphone.pbk de la uzanto sub la profilo Roaming; eroj por ĉiuj uzantoj troviĝas sub ProgramData. Kontrolu la konservejon kongruan kun la profila amplekso, rekonektu la profilon, kiun vi konservis, kaj konfirmu, ke ĝiaj vojoj kaj DNS ankoraŭ funkcias, por ke posta testo mezuru la ŝanĝon, kiun vi faris, ne restan staton.
- La tunelo startas ĉe proceza starto, ne ĉe ensaluto.
- Nur la celitaj prefiksoj aperas sur la VPN-aparataro.
- La reala fora adreso de la aplikaĵo solviĝas al la VPN-kaŝnomo.
- Neniu pendanta ekigilo restas post forigo de la profilo.