VPN-killswitch: vilken trafik den blockerar och när
Återanslutning återställer en tunnel; en killswitch avgör vad som händer medan den är borta. Testa avbrott, manuell frånkoppling, appavslut och nätverksbyte var för sig.
Två funktioner beskrivs med samma ord och gör olika jobb. Automatisk återanslutning försöker få tillbaka tunneln, och det kan lyckas inom en sekund medan förfrågningar misslyckas i mellanrummet. En killswitch avgör vad som händer med trafiken i det mellanrummet. Att läsa en klient som om de två var en enda inställning är hur människor till slut litar på en ikon i stället för en policy.
Blockering och återanslutning är två separata beslut
En klient blockerar bara när avbrottet är oväntat, återansluter sedan och häver blockeringen. En annan håller en blockering på systemnivå tills någon ändrar en inställning för hand, och en tredje ser en avsiktlig frånkoppling som tillstånd att återställa vanlig åtkomst. Det är tre olika beteenden, och leverantörens dokumentation säger vilket din version implementerar.
Import av en profil avgör ingenting i den frågan. Samma serverprofil läses in i två klienter med motsatt blockeringsbeteende, eftersom profilen bär inställningar och inte ett löfte. Därför kan också en kryssruta på skrivbordet och en brytare på mobilen med liknande etiketter implementera olika regler. Läs beskrivningen vid kontrollen på din plattform och testa sedan vad den gör.
Samma profil beter sig olika i två klienter
Inställningarna i OpenVPN Connect-appen beskriver ett tunnelläge som håller kvar vanlig trafik bara medan klienten rapporterar ett pausat eller återanslutande tillstånd, vilket är snävare än ett allmänt löfte om varje händelse på varje plattform. Läs de angivna tillstånden, inte produktnamnet. En beskrivning skriven för en klientversion överförs inte till en annan leverantörs klient.
Android visar samma ord för två kontroller, eftersom alltid på-VPN och blockering av anslutningar utan VPN dokumenteras separat. En skrivbordsklient med en liknande kryssruta kan implementera något snävare eller bredare än någon av dem. Behandla en delad etikett i två menyer som en tillfällighet tills båda beskrivningarna har lästs. Hanterade enheter lägger till ett tredje lager, eftersom en enhetsprofil kan tvinga fram en inställning som användaren inte ser och inte kan åsidosätta.
Plattformsinställningar som ser lika ut är inte likvärdiga
Jämför kontrollen du ser med den policy som faktiskt gäller. På en hanterad enhet kan den synliga brytaren vara grå, eller den kan vara påslagen medan en profil på högre nivå tvingar fram motsatsen. Fråga efter den effektiva policyn i stället för den lokala, och få svaret skriftligt.
Skriv ner vad varje lager hävdar innan du testar något, eftersom de två ofta är oense och oenigheten är lätt att tappa när testerna börjar. En enhet som blockerar korrekt under ett test blockerar kanske av en anledning som ingen har dokumenterat.
Kör en händelse i taget och anteckna koden
Testa en händelse per körning, med en ofarlig förfrågan, och gör varje försök till en ny förfrågan i stället för en sida som kanske redan ligger i cachen. Kommandona nedan tar ner tunneln, ber om en sida och visar om gränssnittet kom tillbaka.
ip link set tun0 down
curl -s -o /dev/null -w "%{http_code}\n" --max-time 5 https://example.com
ip -brief address show tun0
Tabellen knyter varje åtgärd till den observation som spelar roll och till det bevis som är värt att spara. En förfrågan som misslyckas inom tidsgränsen säger att blockeringen slog till; en förfrågan som går igenom säger att trafiken hittade en annan väg, vilket kan vara en utesluten rutt och inte en avstängd blockering. Upprepa hela uppsättningen efter en betydande programuppdatering eller ändring av ruttpolicyn, eftersom båda kan ändra grenen utan att någon synlig inställning rör sig. Till slut vill du ha förutsägbart felbeteende, inte en lugnande ikon.
| What I do | What I watch | Evidence to keep |
|---|---|---|
| Bring the tunnel down by hand | Whether a fresh request fails at once | The HTTP code and the client state at that second |
| Choose Disconnect in the client | Whether ordinary access returns on purpose | The same request succeeding with no tunnel up |
| Quit the app, then reboot | Whether the block outlives the client | A request made from a clean boot |
| Move from Wi-Fi to cellular | Whether DNS and IPv6 follow the policy | The resolver answer, the route table and the code again |
Undantag, gästportaler och vad en blockering inte kan
Åtkomst till det lokala nätverket är det vanliga undantaget, och det ändrar löftets räckvidd. En klient kan nå en skrivare i samma subnät medan den blockerar allt annat, vilket är rimligt hemma och tveksamt på ett gästnätverk. Bestäm om du vill ha det undantaget innan en incident upptäcker det åt dig.
En strikt blockering gör också inloggning på en gästportal besvärlig, eftersom portalen är precis den direkta trafik som blockeringen finns för att stoppa. Lär dig det stödda sättet att auktorisera nätverket och återställ sedan policyn medvetet i stället för att stänga av kontroller tills en sida laddas. Håll resolverns svar och rutttabellen i samma anteckning, som nedan. Det en killswitch inte kan göra är att göra tjänsten anonym, eftersom blockering av trafik utanför tunneln inte säger något om vad som händer inuti den.
resolvectl query example.com
ss -tunp | grep -v tun0