To VPN-apps på én gang: hvilken killswitch gælder egentlig?
En anden VPN-klient arver aldrig den førstes killswitch. Tre betingelser afgør, hvilken politik der gælder, og hvordan du tjekker din.
To VPN-klienter kan køre side om side, men deres killswitches smelter ikke sammen til én politik. Hver klient installerer regler for sin egen tunnel, og ingen af dem ved, at den anden findes. Jeg ramte det med en arbejdsklient, der var forbundet først: den anden app kunne ikke afslutte sit handshake, sad på »Connecting« i ti minutter, og den første tunnel transporterede det hele i al stilhed. Om den anden app bliver beskyttet, afhænger af tre betingelser, ikke af om begge ikoner siger Forbundet.
Hvad en killswitch egentlig er afgrænset til
Intet i styresystemet har ét enkelt killswitch-flag. En klient, der annoncerer et, installerer et regelsæt: smid alt væk, der ikke går ud gennem min tunnel, og ofte fail closed når tunnelen forsvinder. På Linux er det som regel en nftables- eller iptables-kæde, på Windows et sæt Windows Filtering Platform-filtre, på Android og iOS tunneltjenestens egen routing plus den systemindstilling, der blokerer forbindelser uden VPN. Android VPN-vejledningen beskriver den tjenestemodel, hvis du vil have platformsynsvinklen.
Omfanget er den del, der betyder noget. En regel som »tillad kun pakker på udgangsinterface wg0« er ligeglad med, om der findes en anden tunnel. Hvis en anden klient starter wg1, behandler den første klients regler de pakker som almindelig trafik: oftest smidt væk, af og til tilladt. Uanset hvad er det den første klient, der bestemmer, og den aner ikke, at en anden app venter.
Tre betingelser, der afgør, hvem der bliver dækket
Du behøver ikke gennemgå enhver kombination. Tre spørgsmål afgør det på få minutter.
- Tillader platformen overhovedet en anden tunnel? De fleste Android-telefoner og iPhones accepterer kun én aktiv VPN-tjeneste for hver brugerprofil, så den anden app har aldrig en tunnel og håndhæver aldrig noget. Du får én politik, fra den app, der vandt pladsen.
- Hvilken proces ejer standardruten? Windows, macOS og Linux bærer gerne to tunneler. Standardruten tilhører den klient, der konfigurerede den sidst eller med den bedste metrik, og den anden klient er forbundet, men passiv. På Linux bruger wg-quicks standardrutetilstand policy routing med en privat tabel og en fwmark-regel, så en anden wg-quick-tunnel tilføjer en konkurrerende regel i stedet for at erstatte den første.
- Kan den anden klient nå sin egen server? Hvis den første killswitch er default-deny, er den anden apps ydre endpoint bare endnu en destination, der smides væk. Den prøver igen i stilhed og rapporterer aldrig en fejl.
Den korte version til supporttråde:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
To af de rækker ser identiske ud fra ikonet i proceslinjen, og derfor er ikonet det dårligste bevis, der findes her.
Hvad fejler først, og hvordan det ser ud
En klient, der hænger på »Connecting«, mens den anden er sund, er næsten altid endpoint-sult: den kørende killswitch smider den anden klients handshake til dens egen server væk. Bekræft det billigt ved at sætte den første klients blokeringsregler på pause i ét forsøg. Forbinder den anden sig med det samme, er spørgsmålet besvaret.
DNS er den anden fejl. Klienter sætter resolverkonfiguration for deres egen interface, og nogle overskriver ganske enkelt den globale resolverliste. Med begge tunneler oppe kan forespørgsler gå ud ad den ene side, mens resolverserveren hører til den anden. Afbryd en af appene, og den overlevende beholder en uopnåelig navneserver: sider hænger i et minut og slår derefter op igen, mens VPN stadig viser forbundet.
Den tredje er route-flapping. Genopkoblinger omordner standardruten, og en interfacebunden killswitch følger den ikke. Trafik, der for et øjeblik siden var inde i tunnelen, matcher nu en dropregel, hvilket på brugersiden læses som en VPN, der tilfældigt holder op med at virke.
Kontroller, hvilken politik der reelt gælder
Gør det med harmløs trafik, ikke med noget, du ville savne.
Spørg på Linux kernen, hvem der vinder, og hvad firewallen binder til. ip -4 route show default navngiver den tunnel, der ejer udgangen. ip rule show viser, om policy routing er i spil. sudo nft list ruleset | grep -n oifname viser, om drops er bundet til et interfacenavn, et mark eller hele outputkæden.
På Windows bor den samme historie i rutemetrikken og filterlisten: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric og Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". På macOS netstat -rn -f inet | head -5 og scutil --dns | head -20.
Gør så det skridt, folk springer over: stop tunnelen med vilje, og bekræft, at den trafik, du forventer skal fejle, virkelig fejler. Et forbundet ikon er en UI-tilstand, ikke håndhævelse.
Hvornår to klienter er det forkerte design
Er det eneste krav bag den anden app mere beskyttelse, så fjern den. To blokeringspolitikker, der påvirker hinanden, er mindre forudsigelige end én, og hver genopkobling er en chance for at havne i en tilstand, ingen udbyder tester.
Har du virkelig brug for kædning, fx en virksomhedsgateway nået over et kommercielt hop, så vælg et design med ét håndhævelsespunkt. Det betyder normalt en router eller én klient, der understøtter kæden, ikke to desktopapps, der kappes om den samme standardrute. På en administreret enhed beholder du den godkendte klient og betragter alt andet som uden for scope, uanset hvad det viser i proceslinjen.
Tjekliste, før du beholder begge
Gå listen igennem i rækkefølge; det første punkt, der fejler, er det, du skal rette.
- Bekræft, at præcis én klient ejer standardruten og resolverserveren.
- Vil du have den anden klient oppe, så tillad eksplicit dens server-endpoint og tjek igen efter hver klientopdatering.
- Skriv det forventede udfald ned, når en af tunnelerne falder, og test netop det tilfælde.
- Tjek fejlvejen efter en genstart, når startrækkefølgen er anderledes.
- Stop på en administreret profil, og spørg ejeren, før du tilføjer noget.
Fejler trin tre, er det ærlige svar, at kun én klient giver dig en politik. Beslut, hvilken du stoler på, og lad den anden gå.