Windows VPN-utlösare per app kontra delad tunnel: vad isolerar

Två Windows-uppsättningar ser likadana ut i Inställningar och beter sig inte alls likadant. Den ena är en kopierad VPN-profil med en applikationsutlösare, så att start av en körbar fil reser tunneln. Den andra är en profil med delad tunnel vars ruttlista råkar täcka det som applikationen pratar med. Den första svarar när tunneln finns. Den andra svarar vilka paket som kommer in i den, och bara den andra lämnar resten av maskinen på den fysiska länken medan appen förblir ansluten.

Utlösaren är en livscykelregel, inte en routningsregel

Add-VpnConnectionTriggerApplication binder en körbar sökväg till ett profilnamn. När processen startar ringer Anslutningshanteraren för fjärråtkomst upp profilen, och när utlösarvillkoret upphör kan anslutningen falla. Inget i det utbytet inspekterar sockets. Cmdleten kräver ett förhöjt skal, den fullständiga sökvägen till binären och -Force när du ersätter en befintlig post. Bekräfta att kopplingen överlevde med Get-VpnConnectionTrigger i stället för att lita på prompten; Microsofts referens för Add-VpnConnectionTriggerApplication listar parametrarna och exemplen.

Två gränser förklarar de flesta rapporter om att ”utlösaren inte gör något”. Utlösare byggs kring profiler för alla användare, så profilomfånget är det första att reda ut, och applikationens sökväg måste matcha binären som faktiskt körs, inte en genväg eller en startare som skapar en andra process. Den andra gränsen är avsiktlig: i ett nätverk som Windows klassar som betrott förblir utlösaren overksam, eftersom profilen är avsedd att verka utanför 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

Delad tunnel avgör vad som korsar tunneln

Med delad tunnel av installerar Windows en klassbaserad standardrutt med låg metrik på VPN-gränssnittet. Varje socket följer den, inklusive webbläsaren och uppdateringstjänsten, så en utlösare i den konfigurationen flyttar hela maskinen så länge profilen är ansluten. Utlösaren är fortfarande bara en livscykelregel; skadradien kom från rutten.

Med delad tunnel på bär profilen bara de prefix som gatewayen skjuter eller som du lägger till på VPN-gränssnittet. Allt annat fortsätter använda den fysiska standardrutten. Det är den ordning folk oftast menar med ”en app genom en separat utgång”, och det är ett routningsbeslut från början till slut.

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

Där en routad delning slutar isolera din app

Det vanliga felet är en destination som aldrig dyker upp i tunnelns ruttlista. En app som loggar in mot en adress och sedan strömmar från ett CDN, eller löser upp ett dussin roterande slutpunkter, lägger några anslutningar på VPN-gränssnittet och resten på Wi-Fi. IPv6 är en egen tabell, så en profil som bara skjuter IPv4-prefix kan se korrekt ut medan appens IPv6-trafik stannar lokalt.

Två mindre effekter betyder lika mycket. Längsta prefixmatchning vinner, så en mer specifik on-link-rutt, ett /32 som skjuts för en administrationsvärd eller ett andra adapters subnät kan slå tunneln för exakt den adress du bryr dig om. Uppslagning sker också före routning: om inte profilens DNS-servrar eller en NRPT-regel täcker namnet kan appen slå upp via det fysiska adaptern och sedan ringa en adress som aldrig låg inom de tunnlade prefixen.

Tre former, och vad var och en köper

Tabellen är den del jag skulle tejpa på väggen, eftersom beslutet handlar om skadradie och inte funktioner. Om appens destinationer är stabila prefix du kan lista ger den routade delningen isolering med minsta fotavtryck. Om inte håller en standardruttprofil bakom en VM eller en andra enhet isär det ärligt till priset av att flytta mer än en process.

Det ingen av dessa ger är bindning på socketnivå på värden. Den klassiska Windows VPN-klienten har ingen regel som säger att denna process måste använda den adaptern; utlösare och ruttfilter lever i olika lager, och lagret som väljer ett gränssnitt är ruttabellen. Om en guide lovar tillämpning per app enbart från en kopierad profil, fråga vilken rutt eller vilket filter som gör jobbet.

Verifiera paret i ett svep

Testa livscykeln och routningen separat, i den ordningen. Stäng appen, bekräfta att profilen rapporterar Disconnected, starta sedan appen och kontrollera att tillståndet ändrades. Först när tunneln är uppe bör du fråga vart en viss destination tar vägen, och du bör använda adressen som appen faktiskt ringer, inte en gissning.

$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 namnger gränssnittet och nästa hopp som skulle bära den destinationen. Ett fysiskt alias där betyder att tunneln är uppe och irrelevant för det flödet: kontrollera de skjutna prefixen, sedan de mer specifika rutterna, sedan IPv6. Om tillståndet inte ändras alls utlöstes inte utlösaren, och sökvägen till den körbara filen, profilomfånget och VPN-klientens driftlogg är de tre ställena att titta på.

Städa ordentligt så att nästa test är ärligt

Ta bort i omvänd ordning mot hur du byggde: först applikationsutlösaren, sedan profilen. Att radera profilen medan utlösaren finns kvar lämnar en hängande koppling som gör nästa försök förvirrande, och Remove-VpnConnection -Force rensar inte alltid en telefonbokspost som skapades utanför cmdletarna.

Poster per användare ligger i användarens rasphone.pbk under Roaming-profilen; poster för alla användare ligger under ProgramData. Kontrollera lagret som matchar profilomfånget, återanslut profilen du behöll och bekräfta att dess rutter och DNS fortfarande beter sig, så att ett senare test mäter ändringen du gjorde och inte kvarvarande tillstånd.

• Tunneln startar vid processstart, inte vid inloggning.
• Bara de avsedda prefixen syns på VPN-gränssnittet.
• Appens verkliga fjärradress löses upp till VPN-aliaset.
• Ingen hängande utlösare finns kvar efter att profilen tagits bort.