To VPN-appar samtidig: kva kill switch gjeld eigentleg?
Ein annan VPN-klient arvar aldri kill switchen til den første. Tre vilkår avgjer kva policy som gjeld, og korleis du sjekkar din.
To VPN-klientar kan køyre side om side, men kill switcher går ikkje saman til ein einaste policy. Kvar klient legg inn reglar for sin eigen tunnel, og ingen av dei veit at den andre finst. Eg råka på dette med ein jobbklient tilkopla først: den andre appen fekk ikkje fullført handtrykket, sat på «Connecting» i ti minutt, og den første tunnelen frakta alt i stillheit. Om den andre appen blir verna, kjem an på tre vilkår, ikkje på om begge ikona seier Tilkopla.
Kva ein kill switch eigentleg er avgrensa til
Ingenting i operativsystemet har eitt einskilt kill switch-flagg. Ein klient som annonserer eitt, legg inn eit regelsett: slepp alt som ikkje går ut gjennom tunnelen min, og ofte fail closed når tunnelen forsvinn. På Linux er det som regel ei nftables- eller iptables-kjede, på Windows eit sett Windows Filtering Platform-filter, på Android og iOS eigen ruting i tunneltjenesta pluss systeminnstillinga som blokkerer tilkoplingar utan VPN. Android VPN-veiledninga skildrar den tenestemodellen viss du vil ha plattformperspektivet.
Omfanget er den delen som tel. Ein regel som «tillat berre pakkar på utgrensesnittet wg0» bryr seg ikkje om det finst ein andre tunnel. Viss ein annan klient tek opp wg1, handsamar reglane til den første klienten dei pakkane som vanleg trafikk: oftast forkasta, av og til tillatne. Uansett er det den første klienten som bestemmer, og han anar ikkje at ein andre app ventar.
Tre vilkår som avgjer kven som blir dekt
Du treng ikkje gå gjennom kvar kombinasjon. Tre spørsmål avgjer det på nokre minutt.
- Tillèt plattforma i det heile ein andre tunnel? Dei fleste Android-telefonar og iPhone godtek berre éi aktiv VPN-teneste for kvar brukarprofil, så den andre appen har aldri ein tunnel og handhevar aldri noko. Du får éin policy, frå appen som vann plassen.
- Kva prosess eig standardruta? Windows, macOS og Linux ber gjerne to tunnelar. Standardruta høyrer til klienten som sette henne opp sist eller med best metrikk, og den andre klienten er tilkopla men ledig. På Linux nyttar standardrutemodusen i wg-quick policy routing med ein privat tabell og ein fwmark-regel, slik at ein andre wg-quick-tunnel legg til ein konkurrerande regel i staden for å erstatta den første.
- Når den andre klienten sin eigen server? Viss den første kill switchen er default-deny, er det ytre endepunktet til den andre appen berre nok ein forkasta destinasjon. Han prøver på nytt i stillheit og rapporterer aldri ein feil.
Kortversjonen, for supporttrådar:
| 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 dei radene ser identiske ut frå ikonet i systemkurva, og difor er ikonet det dårlegaste beviset som finst her.
Kva som sviktar først, og korleis det ser ut
Ein klient som heng på «Connecting» medan den andre er frisk, er nesten alltid endepunktsvolt: den køyrande kill switchen forkastar handtrykket til den andre klienten mot hans eigen server. Stadfest det billeg ved å setja blokkeringsreglane til den første klienten på pause i eitt forsøk. Koplar den andre seg til med ein gong, er spørsmålet svara.
DNS er den andre feilen. Klientar set resolverkonfigurasjon for sitt eige grensesnitt, og nokre skriv rett og slett over den globale resolverlista. Med begge tunnelane oppe kan spørjingar gå ut gjennom den eine sida medan resolveren høyrer til den andre. Kopl frå ein av appane, og den overlevande held på ein utilgjengeleg namneserver: sider heng i eitt minutt og løysest så opp att, medan VPN framleis viser tilkopla.
Den tredje er route-flapping. Attilkoplingar ordnar om standardruta, og ein grensesnittbunden kill switch følgjer henne ikkje. Trafikk som for eit augneblink sidan var inne i tunnelen, treffer no ein forkastingsregel, noko som på brukarsida blir lese som ein VPN som tilfeldig sluttar å verka.
Kontroller kva policy som faktisk gjeld
Gjer dette med ufarleg trafikk, ikkje med noko du ville sakna.
Spør kjernen på Linux kven som vinn og kva brannmuren bind til. ip -4 route show default namngir tunnelen som eig utgangen. ip rule show viser om policy routing er i spel. sudo nft list ruleset | grep -n oifname viser om forkastingar er bundne til eit grensesnittnamn, ei merking eller heile utkjeda.
På Windows bur den same historia i rutemetrikken og filterlista: 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.
Gjer så trinnet folk hoppar over: stans tunnelen med vilje og stadfest at trafikken du ventar skal feila, verkeleg feilar. Eit tilkopla ikon er ein UI-tilstand, ikkje handheving.
Når to klientar er feil design
Viss det einaste kravet bak den andre appen er meir vern, fjern han. To blokkeringspolicyar som påverkar kvarandre, er mindre føreseielege enn éin, og kvar attilkopling er ein sjanse til å hamna i ein tilstand ingen leverandør testar.
Viss du verkeleg treng kjedding, til dømes ein bedriftsgateway nådd over eit kommersielt hopp, vel eit design med eitt handhevingspunkt. Det tyder normalt ein ruter eller éin klient som støttar kjeda, ikkje to skrivebordsappar som kappast om den same standardruta. På ein administrert eining held du den godkjende klienten og handsamar alt anna som utanfor omfanget, uansett kva det viser i systemkurva.
Sjekkliste før du held på begge
Gå gjennom lista i rekkjefølgje; det første punktet som feilar, er det du må retta.
- Stadfest at nøyaktig éin klient eig standardruta og resolveren.
- Vil du ha den andre klienten oppe, tillat endepunktet til serveren hans eksplisitt og sjekk på nytt etter kvar klientoppdatering.
- Skriv ned venta utfall når ein av tunnelane fell, og test akkurat det tilfellet.
- Sjekk feilvegen etter ein omstart, når startrekkjefølgja er annleis.
- På ein administrert profil: stopp og spør eigaren før du legg til noko.
Viss trinn tre feilar, er det ærlege svaret at berre éin klient gir deg ein policy. Bestem kven du stolar på og lat den andre gå.