Windows VPN-udløser pr. app kontra delt tunnel: hvad isolerer

To Windows-opsætninger ser ens ud i Indstillinger og opfører sig helt forskelligt. Den ene er en kopieret VPN-profil med en applikationsudløser, så start af én eksekverbar fil rejser tunnelen. Den anden er en profil med delt tunnel, hvis ruteliste tilfældigvis dækker det, den applikation taler med. Den første svarer på, hvornår tunnelen findes. Den anden svarer på, hvilke pakker der kommer ind i den, og kun den anden lader resten af maskinen blive på det fysiske link, mens appen forbliver forbundet.

Udløseren er en livscyklusregel, ikke en ruteringsregel

Add-VpnConnectionTriggerApplication binder en eksekverbar sti til et profilnavn. Når den proces starter, ringer Fjernadgangsforbindelsesstyringen op til profilen, og når udløserbetingelsen slutter, kan forbindelsen falde. Intet i den udveksling undersøger sockets. Cmdletten kræver et forhøjet shell, den fulde sti til binæren og -Force når du erstatter en eksisterende post. Bekræft, at tilknytningen overlevede, med Get-VpnConnectionTrigger i stedet for at stole på prompten; Microsofts reference til Add-VpnConnectionTriggerApplication viser parametrene og eksemplerne.

To grænser forklarer de fleste rapporter om, at “udløseren intet gør”. Udløsere er bygget op omkring profiler for alle brugere, så profilens omfang er det første, der skal afklares, og applikationsstien skal matche den binære fil, der faktisk kører, ikke en genvej eller en starter, der starter en anden proces. Den anden grænse er tilsigtet: på et netværk, som Windows klassificerer som betroet, forbliver udløseren inaktiv, fordi profilen er beregnet til at virke uden for 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 afgør, hvad der krydser tunnelen

Med delt tunnel slået fra installerer Windows en klassebaseret standardrute med lav metrik på VPN-grænsefladen. Hver socket følger den, inklusive browseren og opdateringstjenesten, så en udløser i den konfiguration flytter hele maskinen, så længe profilen er forbundet. Udløseren er stadig kun en livscyklusregel; skadesradius kom fra ruten.

Med delt tunnel slået til bærer profilen kun de præfikser, som gatewayen sender, eller som du føjer til VPN-grænsefladen. Alt andet bruger fortsat den fysiske standardrute. Det er den ordning, folk normalt mener med “én app gennem en separat udgang”, og det er en ruteringsbeslutning hele vejen igennem.

Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefix

Hvor en rutet deling holder op med at isolere din app

Den almindelige fejl er en destination, der aldrig dukker op på tunnelens ruteliste. En app, der logger ind mod én adresse og derefter streamer fra et CDN, eller opløser et dusin roterende endepunkter, vil lægge nogle forbindelser på VPN-grænsefladen og resten på Wi-Fi. IPv6 er en separat tabel, så en profil, der kun sender IPv4-præfikser, kan se rigtig ud, mens appens IPv6-trafik bliver lokal.

To mindre effekter betyder lige så meget. Længste præfiks vinder, så en mere specifik on-link-rute, et /32 sendt til en administrationsvært eller et andet adapters undernet kan slå tunnelen for netop den adresse, du bekymrer dig om. Opløsning sker også før rutering: medmindre profilens DNS-servere eller en NRPT-regel dækker navnet, kan appen opløse gennem det fysiske adapter og derefter ringe til en adresse, der aldrig var inde i de tunnelerede præfikser.

Tre former, og hvad hver især køber

Tabellen er den del, jeg ville tape på væggen, fordi beslutningen handler om skadesradius frem for funktioner. Hvis appens destinationer er stabile præfikser, du kan liste, giver den rutede deling isolering med det mindste fodaftryk. Hvis ikke, holder en profil med standardrute bag en VM eller en anden enhed adskillelsen ærlig på bekostning af at flytte mere end én proces.

Det, ingen af disse giver, er binding på socket-niveau på værten. Den klassiske Windows VPN-klient har ingen regel om, at denne proces skal bruge det adapter; udløsere og rutefiltre lever i forskellige lag, og det lag, der vælger en grænseflade, er rutetabellen. Hvis en guide lover håndhævelse pr. app alene ud fra en kopieret profil, så spørg, hvilken rute eller hvilket filter der gør arbejdet.

Bekræft parret i én kørsel

Test livscyklus og rutering hver for sig, i den rækkefølge. Luk appen, bekræft at profilen viser Disconnected, start derefter appen og kontroller, at tilstanden ændrede sig. Først når tunnelen er oppe, bør du spørge, hvor en bestemt destination går hen, og du bør bruge den adresse, appen faktisk ringer til, i stedet for et gæt.

$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 navngiver den grænseflade og det næste hop, der ville bære den destination. Et fysisk alias der betyder, at tunnelen er oppe og irrelevant for det flow: kontroller de sendte præfikser, derefter de mere specifikke ruter, derefter IPv6. Hvis tilstanden slet ikke ændrer sig, blev udløseren ikke fyret, og den eksekverbare sti, profilens omfang og VPN-klientens driftlog er de tre steder at kigge.

Ryd op ordentligt, så den næste test er ærlig

Fjern i omvendt rækkefølge af det, du byggede: applikationsudløseren først, derefter profilen. Sletning af profilen, mens udløseren bliver, efterlader en hængende tilknytning, der gør det næste forsøg forvirrende, og Remove-VpnConnection -Force rydder ikke altid en telefonbogspost skabt uden for cmdletterne.

Poster pr. bruger ligger i brugerens rasphone.pbk under Roaming-profilen; poster for alle brugere ligger under ProgramData. Kontroller det lager, der matcher profilens omfang, genopret forbindelsen til den profil, du beholdt, og bekræft, at dens ruter og DNS stadig opfører sig, så en senere test måler den ændring, du lavede, i stedet for resttilstand.

• Tunnelen starter ved processtart, ikke ved login.
• Kun de tilsigtede præfikser vises på VPN-grænsefladen.
• Appens faktiske fjernadresse opløses til VPN-aliaset.
• Ingen hængende udløser er tilbage, efter profilen er fjernet.