Blockerar din säkerhetsbrytare appen som du har uteslutit från tunneln?

Säkerhetsbrytaren är på, en app är avsiktligt utesluten från tunneln, och de två kraven motsäger nu varandra. Det ena säger att inget får gå ut utom genom tunneln, det andra säger att det här programmet måste gå direkt. Varje klient löser den konflikten olika, och inställningssidan förklarar sällan vilken regel som vinner. Skriv policyn per applikation innan du litar på någon etikett.

Två policyer, en maskin

En säkerhetsbrytare är ett löfte om fel: när tunneln inte skyddar trafiken stannar trafiken. Delad tunnling är ett löfte om urval: de här programmen eller destinationerna använder tunneln, och de andra gör det inte. Det andra löftet skapar trafik som det första måste ta ställning till. Inget av löftena är fel; de skrevs bara av olika människor för olika hot.

Tre utfall är möjliga och bara ett av dem är det som utrullningen avsåg. Den uteslutna appen kan förbli direkt under ett avbrott, vilket respekterar delningen och bryter säkerhetsbrytaren. Den kan blockeras tillsammans med allt annat, vilket respekterar säkerhetsbrytaren och bryter delningen. Eller så blockeras den bara ibland, beroende på hur plattformen bedömer regeln efter att ett gränssnitt försvinner. Det sista fallet är det som genererar ärenden.

Skriv applistan före regeln

Lista programmen som måste använda tunneln, de som måste gå direkt, och namnen eller destinationerna som aldrig får förekomma på någon av listorna. Ta med resolverbeteende och IPv6-sidan separat, eftersom båda kan följa en annan policy än sidtrafik.

Regler per app matchar oftast en körbar fil eller ett paket, inte en profil inuti den. En webbläsarprofil, ett privat fönster och ett tillägg bär ingen egen nätverksidentitet, så de ärver det processen fick. En hjälpprocess som startades av den webbläsaren ärver kanske inte samma regel alls.

Det behövs två listor, inte en: vad tunneln ska bära och vad som inte under några omständigheter får resa utanför den. Ett program som står på båda är en kravkonflikt och inte en implementeringsdetalj, och den måste klaras ut innan klienten konfigureras.

Vad klienten gör under ett avbrott

Vissa implementeringar blockerar uteslutna appar under ett avbrott och återställer deras åtkomst vid återanslutning. Andra behåller den direkta vägen hela tiden, vilket stämmer med delningen och är svagare som säkerhetsegenskap. Låsning på plattformsnivå kan helt åsidosätta klientens eget val per app. Den skillnaden är inte kosmetisk, eftersom den avgör om den uteslutna appen är ett policyundantag eller ett hål.

Androids alltid på-VPN med alternativet att blockera anslutningar utan VPN är det tydligaste fallet, eftersom plattformen genomdriver låsningen och inte klienten, och ett uteslutet paket blockeras tillsammans med allt annat medan tunneln är nere. En skrivbordsklient som tillämpar undantag per app i sin egen drivrutin lämnar oftast den uteslutna processen på det fysiska gränssnittet, eftersom den aldrig ägde den processens trafik. Båda beteendena är försvarbara och bara ett av dem passar ett krav som säger att den uteslutna appen måste förbli användbar. Fråga vilken komponent som genomdriver regeln innan du tolkar resultatet.

Läs beteendet för operativsystemet framför dig, inte inställningen med samma namn någon annanstans. Genomdrivnings-API:erna skiljer sig, och en kryssruta kan betyda strikt olika saker på en dator och i en telefon. Versionen spelar också roll, eftersom låskontrollen har flyttats mellan skärmar genom Android-utgåvorna, och en undantagslista på klientsidan är inte samma kontroll som en plattformslåsning.

Tre ögonblick: tunnel uppe, tunnel nere, återansluten

Använd ofarliga förfrågningar vid tre tillfällen: medan tunneln fungerar, under avbrottet du bryr dig om och efter återanslutning. Ett enda webbläsarresultat kan inte fastställa den uteslutna appens beteende.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

Utgångsadressen visar vilken väg som valdes, och det uttryckliga gränssnittstestet visar vad som händer när tunneln är den enda tillgängliga utgången. Notera det förväntade resultatet vid varje rad innan du kör någon av dem, annars tolkas utdata i efterhand.

Om en utesluten app går offline, undersök policyprioriteten innan du lägger till ett brett brandväggstillstånd, eftersom den rättelsen förstör den skillnad du testade. Om den förblir direkt, bekräfta att det var det dokumenterade undantaget och inte en oavsiktlig återgång. Vid ett strikt krav för hela enheten, förkorta undantagslistan tills den kan testas manuellt.