To VPN-apper samtidig: hvilken kill switch gjelder egentlig?
En annen VPN-klient arver aldri den førstes kill switch. Tre forhold avgjør hvilken policy som gjelder, og hvordan du sjekker din.
To VPN-klienter kan kjøre side om side, men kill switchene deres smelter ikke sammen til én policy. Hver klient installerer regler for sin egen tunnel, og ingen av dem vet at den andre finnes. Jeg traff på dette med en jobbklient tilkoblet først: den andre appen fikk ikke fullført håndtrykket, ble stående på «Connecting» i ti minutter, og den første tunnelen fraktet alt i stillhet. Om den andre appen blir beskyttet, avhenger av tre forhold, ikke av om begge ikonene sier Tilkoblet.
Hva en kill switch egentlig er avgrenset til
Ingenting i operativsystemet har ett enkelt kill switch-flagg. En klient som annonserer ett, installerer et regelsett: slipp alt som ikke går ut gjennom tunnelen min, og ofte fail closed når tunnelen forsvinner. På Linux er det som regel en nftables- eller iptables-kjede, på Windows et sett Windows Filtering Platform-filtre, på Android og iOS tunneltjenestens egen ruting pluss systeminnstillingen som blokkerer tilkoblinger uten VPN. Android VPN-veiledningen beskriver den tjenestemodellen hvis du vil ha plattformperspektivet.
Omfanget er den delen som betyr noe. En regel som «tillat bare pakker på utgrensesnitt wg0» bryr seg ikke om det finnes en andre tunnel. Hvis en annen klient tar opp wg1, behandler reglene til den første klienten disse pakkene som vanlig trafikk: som oftest forkastet, av og til tillatt. Uansett er det den første klienten som bestemmer, og den aner ikke at en andre app venter.
Tre forhold som avgjør hvem som blir dekket
Du trenger ikke gå gjennom hver kombinasjon. Tre spørsmål avgjør det på noen minutter.
- Tillater plattformen i det hele tatt en andre tunnel? De fleste Android-telefoner og iPhones godtar bare én aktiv VPN-tjeneste for hver brukerprofil, så den andre appen har aldri en tunnel og håndhever aldri noe. Du får én policy, fra appen som vant plassen.
- Hvilken prosess eier standardruten? Windows, macOS og Linux bærer gjerne to tunneler. Standardruten tilhører klienten som konfigurerte den sist eller med best metrikk, og den andre klienten er tilkoblet men ledig. På Linux bruker wg-quicks standardrutemodus policy routing med en privat tabell og en fwmark-regel, slik at en andre wg-quick-tunnel legger til en konkurrerende regel i stedet for å erstatte den første.
- Når den andre klienten sin egen server? Hvis den første kill switchen er default-deny, er det ytre endepunktet til den andre appen bare nok en forkastet destinasjon. Den prøver igjen i stillhet og rapporterer aldri en feil.
Kortversjonen, for supporttråder:
| 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 av disse radene ser identiske ut fra ikonet i systemkurven, og derfor er ikonet det dårligste beviset som finnes her.
Hva som svikter først, og hvordan det ser ut
En klient som henger på «Connecting» mens den andre er frisk, er nesten alltid endepunktsult: den kjørende kill switchen forkaster håndtrykket til den andre klienten mot dens egen server. Bekreft det billig ved å sette blokkeringsreglene til den første klienten på pause i ett forsøk. Kobler den andre seg til med en gang, er spørsmålet besvart.
DNS er den andre feilen. Klienter setter resolverkonfigurasjon for sitt eget grensesnitt, og noen overskriver rett og slett den globale resolverlisten. Med begge tunnelene oppe kan spørringer gå ut gjennom den ene siden mens resolveren tilhører den andre. Koble fra en av appene, og den overlevende beholder en utilgjengelig navneserver: sider henger i ett minutt og løses så opp igjen, mens VPN fortsatt viser tilkoblet.
Den tredje er route-flapping. Gjenoppkoblinger omordner standardruten, og en grensesnittbundet kill switch følger den ikke. Trafikk som for et øyeblikk siden var inne i tunnelen, treffer nå en forkastningsregel, noe som på brukersiden leses som en VPN som tilfeldig slutter å virke.
Kontroller hvilken policy som faktisk gjelder
Gjør dette med ufarlig trafikk, ikke med noe du ville savne.
Spør kjernen på Linux hvem som vinner og hva brannmuren binder til. ip -4 route show default navngir tunnelen som eier utgangen. ip rule show viser om policy routing er i spill. sudo nft list ruleset | grep -n oifname viser om forkastninger er bundet til et grensesnittnavn, en markering eller hele utkjeden.
På Windows bor den samme historien 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.
Gjør så trinnet folk hopper over: stans tunnelen med vilje og bekreft at trafikken du forventer skal feile, virkelig feiler. Et tilkoblet ikon er en UI-tilstand, ikke håndheving.
Når to klienter er feil design
Hvis det eneste kravet bak den andre appen er mer beskyttelse, fjern den. To blokkeringspolicyer som påvirker hverandre, er mindre forutsigbare enn én, og hver gjenoppkobling er en sjanse til å havne i en tilstand ingen leverandør tester.
Hvis du virkelig trenger kjedning, for eksempel en bedriftsgateway nådd over et kommersielt hopp, velg et design med ett håndhevingspunkt. Det betyr normalt en ruter eller én klient som støtter kjeden, ikke to skrivebordsapper som kappes om den samme standardruten. På en administrert enhet beholder du den godkjente klienten og behandler alt annet som utenfor omfanget, uansett hva det viser i systemkurven.
Sjekkliste før du beholder begge
Gå gjennom listen i rekkefølge; det første punktet som feiler, er det du må rette.
- Bekreft at nøyaktig én klient eier standardruten og resolveren.
- Vil du ha den andre klienten oppe, tillat endepunktet til serveren dens eksplisitt og sjekk på nytt etter hver klientoppdatering.
- Skriv ned forventet utfall når en av tunnelene faller, og test akkurat det tilfellet.
- Sjekk feilveien etter en omstart, når startrekkefølgen er annerledes.
- På en administrert profil: stopp og spør eieren før du legger til noe.
Hvis trinn tre feiler, er det ærlige svaret at bare én klient gir deg en policy. Bestem hvilken du stoler på og la den andre gå.