Två VPN-appar samtidigt: vilken kill switch gäller egentligen?

Två VPN-klienter kan köra sida vid sida, men deras kill switch-regler smälter inte samman till en enda policy. Varje klient installerar regler för sin egen tunnel, och ingen av dem vet att den andra finns. Jag råkade ut för det med en jobbklient ansluten först: den andra appen kunde inte slutföra sin handskakning, låg på ”Connecting” i tio minuter och den första tunneln transporterade allt i tysthet. Om den andra appen blir skyddad hänger på tre villkor, inte på om båda ikonerna säger Ansluten.

Vad en kill switch egentligen är avgränsad till

Inget i operativsystemet har en enda kill switch-flagga. En klient som annonserar en installerar en regeluppsättning: släpp allt som inte lämnar genom min tunnel, och ofta fail closed när tunneln försvinner. På Linux är det oftast en nftables- eller iptables-kedja, på Windows en uppsättning Windows Filtering Platform-filter, på Android och iOS tunneltjänstens egen routing plus systeminställningen som blockerar anslutningar utan VPN. Android VPN-guiden beskriver den tjänstemodellen om du vill ha plattformsperspektivet.

Omfattningen är den del som spelar roll. En regel som ”tillåt bara paket på utgående gränssnitt wg0” bryr sig inte om en andra tunnel finns. Om en annan klient tar upp wg1 behandlar den första klientens regler de paketen som vanlig trafik: oftast droppade, ibland tillåtna. Hur som helst är det den första klienten som bestämmer, och den har ingen aning om att en andra app väntar.

Tre villkor som avgör vem som täcks

Du behöver inte gå igenom varje kombination. Tre frågor avgör det på några minuter.

1. Tillåter plattformen ens en andra tunnel? De flesta Android-telefoner och iPhone tar bara emot en aktiv VPN-tjänst per användarprofil, så den andra appen har aldrig en tunnel och genomdriver aldrig något. Du får en enda policy, från appen som vann platsen.
2. Vilken process äger standardrutten? Windows, macOS och Linux bär gärna två tunnlar. Standardrutten tillhör den klient som konfigurerade den sist eller med bäst metrik, och den andra klienten är ansluten men sysslolös. På Linux använder wg-quicks läge för standardrutt policy routing med en privat tabell och en fwmark-regel, så en andra wg-quick-tunnel lägger till en konkurrerande regel i stället för att ersätta den första.
3. Kan den andra klienten nå sin egen server? Om den första kill switchen är default-deny är den andra appens yttre endpoint bara ännu ett droppat mål. Den försöker igen i tysthet och rapporterar aldrig ett fel.

Den korta versionen, för supporttrådar:

Två av de raderna ser identiska ut från ikonen i aktivitetsfältet, och därför är ikonen det sämsta beviset som finns här.

Vad som fallerar först, och hur det ser ut

En klient som hänger på ”Connecting” medan den andra mår bra är nästan alltid endpoint-svält: den aktiva kill switchen droppar den andra klientens handskakning till dess egen server. Bekräfta det billigt genom att pausa den första klientens blockeringsregler under ett försök. Ansluter den andra direkt är frågan besvarad.

DNS är det andra felet. Klienter sätter resolverkonfiguration för sitt eget gränssnitt, och en del skriver helt enkelt över den globala resolverlistan. Med båda tunnlarna uppe kan frågor gå ut genom ena sidan medan resolvern tillhör den andra. Koppla från någon av apparna och den överlevande behåller en onåbar namnserver: sidor hänger i en minut och löses sedan igen, medan VPN fortfarande visar ansluten.

Det tredje är route-flapping. Återanslutningar ordnar om standardrutten, och en gränssnittsbunden kill switch följer den inte. Trafik som för en stund sedan låg i tunneln matchar nu en droppregel, vilket på användarsidan läses som en VPN som slumpmässigt slutar fungera.

Kontrollera vilken policy som faktiskt gäller

Gör det med ofarlig trafik, inte med något du skulle sakna.

Fråga kärnan på Linux vem som vinner och vad brandväggen binder till. ip -4 route show default namnger tunneln som äger utgången. ip rule show visar om policy routing är i spel. sudo nft list ruleset | grep -n oifname visar om dropp är bundna till ett gränssnittsnamn, en markering eller hela utkedjan.

På Windows bor samma historia i rutmetriken och filterlistan: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric och Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". På macOS netstat -rn -f inet | head -5 och scutil --dns | head -20.

Gör sedan steget folk hoppar över: stoppa tunneln med avsikt och bekräfta att trafiken du förväntar dig ska misslyckas verkligen misslyckas. En ansluten ikon är ett UI-läge, inte genomdrivande.

När två klienter är fel design

Om det enda kravet bakom den andra appen är mer skydd, ta bort den. Två blockeringspolicyer som samverkar är mindre förutsägbara än en, och varje återanslutning är en chans att hamna i ett läge som ingen leverantör testar.

Om du verkligen behöver kedjning, till exempel en företagsgateway nådd via ett kommersiellt hopp, välj en design med en enda genomdrivningspunkt. Det betyder normalt en router eller en enda klient som stöder kedjan, inte två skrivbordsappar som kappas om samma standardrutt. På en hanterad enhet behåller du den godkända klienten och behandlar allt annat som utanför omfånget, vad det än visar i aktivitetsfältet.

Checklista innan du behåller båda

Arbeta igenom listan i ordning; första punkten som fallerar är den du ska åtgärda.

• Bekräfta att exakt en klient äger standardrutten och resolvern.
• Om du vill ha den andra klienten uppe, tillåt uttryckligen dess server-endpoint och kontrollera igen efter varje klientuppdatering.
• Skriv ner det förväntade utfallet när någon av tunnlarna fallerar och testa just det fallet.
• Kontrollera felvägen efter en omstart, när startordningen är annorlunda.
• På en hanterad profil: stanna och fråga ägaren innan du lägger till något.

Om steg tre fallerar är det ärliga svaret att bara en klient ger dig en policy. Bestäm vilken du litar på och låt den andra gå.