Kill switch i appen kontra kill switch i brandväggen: vad var och en blockerar

En kill switch på en funktionslista säger nästan ingenting om vad som händer när tunneln faller. En implementering stänger valda processer, en annan installerar paketfilter vid operativsystemets gräns, och en tredje försöker helt enkelt återansluta. Skillnaden visar sig i sekunderna efter ett fel, inte på inställningsskärmen. Gå igenom dessa kontroller i ordning och stanna vid den första du inte kan svara ärligt på, för det är där din verkliga täckning slutar.

Namnge verkställighetsmekanismen först

Processterminering är en funktion i applikationens livscykel. Den hittar valda program efter ett upptäckt tunnelfel och stänger dem. Allt som inte är huvudprocessen överlever: hjälptjänster, bakgrundssynkronisering och varje applikation som startas en sekund senare har sin egen livscykel och sin egen timing.

Paketfiltrering är en operativsystemfunktion. Den avvisar trafik som inte följer den tillåtna vägen, vilket är ett starkare löfte, men bara så långt regeln faktiskt träffar. Adressfamilj, gränssnitt, uteslutna applikationer och undantag avgör det, inte etiketten i klienten.

Överlever blockeringen klienten?

Ställ fyra frågor i denna ordning: vad händer vid en krasch, vid manuell avstängning, vid utloggning och vid omstart. En regel som klienten själv underhåller tas vanligtvis bort vid en snygg avstängning och blir ofta kvar efter en krasch. En regel som installeras i plattformens lager kan bete sig omvänt: överleva både klienten och ibland avinstallationen.

Stäng klienten mitt i en lång nedladdning och se om överföringen stannar eller fortsätter.

Leta efter standardhålen

IPv6 är det första. En regel skriven för IPv4-adresser lämnar IPv6-trafik orörd, och många klienter skriver bara v4-halvan. Det andra är gränssnittet: USB-tethering, en andra Wi-Fi-adapter och ett mobilmodem ingår kanske inte i en regel som är begränsad till den primära anslutningen. Uteslutna applikationer och undantag för lokala nätverk är det tredje.

På Windows kan du läsa de installerade reglerna i stället för att lita på reglaget: Get-NetFirewallRule -DisplayName '*VPN*' och netsh wfp show filters visar båda vad som finns. På Linux täcker iptables -S, ip6tables -S och nft list ruleset de vanliga fallen, och att jämföra alla tre är poängen.

DNS är den vanliga läckan

Att blockera TCP medan UDP 53 står öppet ger dig en mycket övertygande kill switch som fortfarande svarar på varje värdnamnsfråga. Samma sak gäller när DNS lämnas till en resolver på ett annat gränssnitt, eller när klienten bara blockerar v4 och resolvern nås via v6.

Med tunneln nere, slå upp ett känt namn och se om ett svar kommer tillbaka. Om det gör det är trafiken inte helt blockerad, vad statusikonen än säger.

Testa övergången, inte reglaget

Att stänga av VPN:en från dess egen meny är en snygg avstängning, och det snygga fallet hanterar varje implementering bra. Övergången som betyder något är den brutala: döda tunnelprocessen, dra ut nätverket, låt servern sluta svara. Starta sedan en förfrågan och se om den misslyckas eller tyst använder den fysiska länken.

Ett resultat från en bärbar dator överförs inte till en telefon eller router. Olika plattforms-API:er, olika standardvärden, och på Android är skillnaden skarp: always-on med blockering verkställs av systemet i stället för klienten, så det fortsätter att fungera när klienten inte gör det. Androids VPN-vägledning beskriver den uppdelningen.

Behåll en väg tillbaka

Blockering på systemnivå har det motsatta felläget. Filter som överlever klienten kan lämna en maskin helt utan nätverk efter en avinstallation, vilket är ett supportärende utan uppenbar orsak. Innan du aktiverar en kill switch som skriver plattformsregler, notera hur den tas bort, och håll leverantörens reparationsväg där du kan hitta den.

Om du inte kan svara på krasch-, IPv6-, DNS- och övergångskontrollerna för din klient, behandla den som en brytare på appnivå med kända hål och planera därefter.