Zwei VPN-Apps gleichzeitig: Welcher Kill-Switch greift wirklich?
Ein zweiter VPN-Client erbt niemals den Kill-Switch des ersten. Drei Bedingungen entscheiden, welche Richtlinie gilt – und wie Sie Ihre eigene prüfen.
Zwei VPN-Clients können parallel laufen, aber ihre Kill-Switches verschmelzen nicht zu einer einzigen Richtlinie. Jeder Client installiert Regeln für seinen eigenen Tunnel, und keiner weiß, dass der andere existiert. Mir ist das passiert, als zuerst ein Firmen-Client verbunden war: Die zweite App konnte ihren Handshake nicht abschließen, hing zehn Minuten auf „Connecting“ und der erste Tunnel schleppte stillschweigend alles mit. Ob die zweite App geschützt wird, hängt an drei Bedingungen – nicht daran, ob beide Symbole „Verbunden“ anzeigen.
Worauf ein Kill-Switch tatsächlich begrenzt ist
Nichts im Betriebssystem hat ein einzelnes Kill-Switch-Flag. Ein Client, der eines bewirbt, installiert ein Regelwerk: Alles verwerfen, was nicht durch meinen Tunnel hinausgeht, und bei Wegfall des Tunnels oft fail closed. Unter Linux ist das meist eine nftables- oder iptables-Kette, unter Windows eine Reihe von Filtern der Windows Filtering Platform, unter Android und iOS das eigene Routing des Tunnel-Dienstes plus die Systemeinstellung, die Verbindungen ohne VPN blockiert. Der Android-VPN-Leitfaden beschreibt dieses Dienstmodell, wenn Sie die Plattformperspektive wollen.
Der Geltungsbereich ist der entscheidende Teil. Eine Regel wie „nur Pakete auf Ausgabeschnittstelle wg0 zulassen“ interessiert nicht, ob ein zweiter Tunnel existiert. Bringt ein anderer Client wg1 hoch, behandeln die Regeln des ersten Clients diese Pakete als gewöhnlichen Verkehr: meist verworfen, gelegentlich erlaubt. So oder so entscheidet der erste Client – und hat keine Ahnung, dass eine zweite App wartet.
Drei Bedingungen entscheiden, wer abgedeckt wird
Sie müssen nicht jede Kombination durchgehen. Drei Fragen klären es in wenigen Minuten.
- Lässt die Plattform überhaupt einen zweiten Tunnel zu? Die meisten Android-Telefone und iPhones akzeptieren pro Nutzerprofil nur einen aktiven VPN-Dienst, also hält die zweite App nie einen Tunnel und erzwingt nie etwas. Sie bekommen eine Richtlinie – von der App, die den Platz gewonnen hat.
- Welcher Prozess besitzt die Standardroute? Windows, macOS und Linux tragen ohne Weiteres zwei Tunnel. Die Standardroute gehört dem Client, der sie zuletzt oder mit der besseren Metrik konfiguriert hat, und der andere Client ist verbunden, aber untätig. Unter Linux nutzt der Default-Route-Modus von wg-quick Policy-Routing mit einer privaten Tabelle und einer fwmark-Regel, sodass ein zweiter wg-quick-Tunnel eine konkurrierende Regel hinzufügt, statt die erste zu ersetzen.
- Erreicht der zweite Client seinen eigenen Server? Ist der erste Kill-Switch default-deny, ist der äußere Endpunkt der zweiten App nur ein weiteres verworfenes Ziel. Sie versucht es still erneut und meldet nie einen Fehler.
Die Kurzfassung für Support-Threads:
| 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 |
Zwei dieser Zeilen sehen im Tray-Symbol identisch aus – deshalb ist das Symbol hier der schlechteste Beweis, den es gibt.
Was zuerst versagt – und wie das aussieht
Ein Client, der auf „Connecting“ hängt, während der andere gesund ist, bedeutet fast immer Endpoint-Hunger: Der laufende Kill-Switch verwirft den Handshake des zweiten Clients zu dessen eigenem Server. Billig bestätigen lässt sich das, indem Sie die Blockregeln des ersten Clients für einen Versuch pausieren. Verbindet sich der zweite sofort, ist die Frage beantwortet.
DNS ist der zweite Fehler. Clients setzen die Resolver-Konfiguration für ihre eigene Schnittstelle, und manche überschreiben die globale Resolver-Liste schlicht. Bei beiden aktiven Tunnels können Abfragen über die eine Seite hinausgehen, während der Resolver zur anderen gehört. Trennen Sie eine der beiden Apps, behält die übrige einen unerreichbaren Nameserver: Seiten hängen eine Minute und lösen dann wieder auf, während das VPN weiterhin verbunden anzeigt.
Der dritte ist Route-Flapping. Neuverbindungen ordnen die Standardroute neu, und ein an eine Schnittstelle gebundener Kill-Switch folgt ihr nicht. Verkehr, der eben noch im Tunnel war, passt nun auf eine Verwerfungsregel – für den Nutzer liest sich das wie ein VPN, das sporadisch aufhört zu funktionieren.
Prüfen, welche Richtlinie wirklich greift
Machen Sie das mit harmlosem Verkehr, nicht mit etwas, dem Sie nachtrauern würden.
Fragen Sie unter Linux den Kernel, wer gewinnt und woran die Firewall bindet. ip -4 route show default nennt den Tunnel, dem der ausgehende Verkehr gehört. ip rule show zeigt, ob Policy-Routing im Spiel ist. sudo nft list ruleset | grep -n oifname zeigt, ob Verwerfungen an einen Schnittstellennamen, eine Marke oder die ganze Output-Kette gebunden sind.
Unter Windows steckt dieselbe Geschichte in der Routenmetrik und der Filterliste: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric und Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Unter macOS dann netstat -rn -f inet | head -5 und scutil --dns | head -20.
Dann machen Sie den Schritt, den Leute überspringen: Stoppen Sie den Tunnel absichtlich und bestätigen Sie, dass der Verkehr, der scheitern soll, wirklich scheitert. Ein verbundenes Symbol ist ein UI-Zustand, keine Durchsetzung.
Wann zwei Clients das falsche Design sind
Ist die einzige Anforderung hinter der zweiten App mehr Schutz, entfernen Sie sie. Zwei wechselwirkende Block-Richtlinien sind weniger vorhersagbar als eine, und jede Neuverbindung ist eine Chance, in einem Zustand zu landen, den kein Hersteller testet.
Wenn Sie wirklich eine Verkettung brauchen, etwa ein Firmen-Gateway über einen kommerziellen Hop, wählen Sie ein Design mit einem einzigen Durchsetzungspunkt. Das heißt normalerweise ein Router oder ein einzelner Client, der die Kette unterstützt – nicht zwei Desktop-Apps, die um dieselbe Standardroute rennen. Auf einem verwalteten Gerät behalten Sie den freigegebenen Client und behandeln alles andere als außerhalb des Geltungsbereichs, egal was es im Tray anzeigt.
Checkliste, bevor Sie beide behalten
Gehen Sie die Liste der Reihe nach durch; der erste Punkt, der scheitert, ist der zu behebende.
- Bestätigen Sie, dass genau ein Client die Standardroute und den Resolver besitzt.
- Wenn der zweite Client laufen soll, erlauben Sie seinen Server-Endpunkt ausdrücklich und prüfen Sie nach jedem Client-Update erneut.
- Notieren Sie das erwartete Ergebnis, wenn einer der Tunnel wegbricht, und testen Sie genau diesen Fall.
- Prüfen Sie den Fehlerpfad nach einem Neustart, wenn die Startreihenfolge anders ist.
- In einem verwalteten Profil halten Sie an und fragen den Eigentümer, bevor Sie etwas hinzufügen.
Wenn Schritt drei scheitert, lautet die ehrliche Antwort, dass nur ein Client Ihnen eine Richtlinie gibt. Entscheiden Sie, welchem Sie trauen, und lassen Sie den anderen los.