Att tunnla en app flyttar inte dess routning till allt som appen startar, även om gränssnittet antyder motsatsen. En länk lämnar en begäran till ett annat program, det programmet öppnar sin egen socket, och plattformen tillämpar reglerna på den nya processen i stället för på den som visade texten. Det är den andra processen som tunnelpolicyn faktiskt ser, och det är inte den du konfigurerade.

En inkluderad app kan därför öppna en webbläsare som står utanför tunneln. En exkluderad webbläsare kan lämna tillbaka arbete till en app som står innanför den. Båda riktningarna av den överraskningen är normalt beteende.

Den del av arbetsflödet som ingen konfigurerade

Policy per app skrivs mot identiteten hos en körbar fil eller ett paket, och varje anslutning bedöms i det ögonblick den skapas. Webbläsaren, dokumentvisaren, mediaspelaren och systemets delningsark bär var sin identitet, och var och en får sin egen dom. En djup länk bär data, inte policy.

Därför känns observationen godtycklig: samma klick routas två vägar beroende på vilken hanterare som svarar. En e-postklient i tunneln öppnar en länk i en webbläsare som lever utanför tunneln, och sidan laddas från din hemadress. En webbläsare utanför tunneln öppnar ett dokument i en visare som lever innanför den, och filen kommer in genom utgången. Ingen av de två resultaten är ett fel i klienten.

En hanterare som redan körs gör det värre. Om webbläsaren redan är öppen blir länken ett meddelande till en befintlig process, och den processen behåller den routning den hade vid start. Att stänga och öppna hanteraren igen ändrar resultatet, och därför återuppstår aldrig problemet på begäran.

PlatformPolicy objectWhat it is evaluated against
AndroidPer-app VPN allowlistPackage name of the process opening the socket
WindowsApplication traffic filtersApplication path in the filter rule
LinuxUID or cgroup routing rulesOwner of the socket, which can be a different program

Vilken process som faktiskt skapade anslutningen

Mät den mottagande sidan i stället för att resonera om den. Håll tunneln uppe, klicka på en oskyldig länk och titta på socketarna som det nya programmet håller.

ss -tnp state established '( dport = :443 )'
Get-NetTCPConnection -State Established | Select-Object RemoteAddress,OwningProcess

Det första kommandot namnger processen bakom varje etablerad socket i Linux, och det andra gör samma sak i Windows genom att lösa identiteten för den ägande processen. Jämför processnamnet med namnen i din policy. Om namnet är webbläsaren och webbläsaren är exkluderad lämnade klicket tunneln med avsikt och inte på grund av ett fel. Att para en policyregel med en levande socket är hela metoden.

Upprepa kontrollen med hanteraren redan igång och sedan med den stängd. De två resultaten kan skilja sig, och den skillnaden förklarar de flesta sporadiska rapporterna om länkar som slipper ut ur en tunnel.

Täckning är en egenskap hos arbetsflödet

Om en uppgift ska stanna i tunneln från början till slut måste varje komponent den kan nå vara inom policyn: startaren, hanteraren, visaren och alla förmedlare som plattformen sätter in mellan dem. Bredare täckning är ofta det ärliga svaret, och det är billigare än att granska varje delningsmål.

Att exkludera en systemförmedlare för att laga en enda app är ett vanligt misstag. Förmedlare delas, så undantaget följer varje annan app som använder samma väg, oftast utan att någon märker det förrän en rapport kommer veckor senare. Läs vad mer som beror på komponenten innan du exkluderar den.

Håll identitet åtskild från routning. En länk kan bära en sessionstoken eller en kontoinriktning oavsett vilken utgång som tar emot begäran. Ett korrekt routat klick kan fortfarande berätta för målet exakt vem som följde det.

Dokumentera arbetsflödet, inte den första kryssrutan. När en uppgift spänner över fyra program är diagrammet med fyra program det som förutsäger vart trafiken tar vägen, och inställningen för en enda app är bara en rad i det.

Relaterade artiklar