Ein zweites VPN zu starten ersetzt den Zustand des ersten
Ein Telefon erlaubt jeweils einen VPN-Dienst; auf einem Desktop streiten Clients um dieselben Routen. Keines von beiden erzeugt ohne echtes Design einen verschachtelten Tunnel.
Zwei Clients, zwei verbundene Symbole und die Überzeugung, dass der Datenverkehr nun durch beide läuft. Vergleichen Sie diese Überzeugung damit, was jede Plattform tatsächlich erlaubt. Ein Telefon hat normalerweise genau einen Platz für einen VPN-Dienst; ein Desktop kann mehrere Clients ausführen, die um dieselben Routen und denselben Resolver streiten. Der Unterschied zwischen diesen beiden Situationen erklärt die meisten Berichte über ein VPN, das ausfällt, wenn ein anderes startet.
Die Symbole beschreiben Prozesse, keine Kette.
Ein Platz auf dem Telefon, mehrere Anwärter auf dem Desktop
Unter Android bietet die Plattform ein VPN-Dienstmodell mit einem einzigen aktiven VPN pro Benutzerprofil, sodass das Starten eines zweiten das erste beendet. Das ist das System, das seine eigene Regel durchsetzt, kein Fehler in einem der Clients. Auf einem Desktop können mehrere Clients gleichzeitig laufen, und dann konkurrieren sie um die Routing-Tabelle, Policy-Regeln, Resolver-Konfiguration und virtuelle Schnittstellen. Beide Ergebnisse sind die Plattform, die wie vorgesehen arbeitet.
Keines der Ergebnisse erzeugt für sich genommen einen verschachtelten Tunnel. Eine Kette erfordert, dass ein Tunnel die verschlüsselten Pakete des anderen trägt, und das ist eine Architektur, kein Zufall der Reihenfolge.
Was der zweite Client überschreibt
Der zweite Client installiert typischerweise eine Standardroute, fügt eigene Regeln hinzu und setzt seinen eigenen Resolver durch. Der erste kann als Prozess ohne Verkehr überleben oder eine Route behalten, die nicht mehr gewinnt. Domänenspezifische Routen sind das übliche Opfer, weshalb manche Ziele weiter funktionieren, während andere ausfallen. Das sichtbare Symptom ist eine Trennung, und der tatsächliche Zustand ist eine teilweise Ersetzung.
Eine Prüfung der Exit-IP wird das nicht aufdecken. Sie meldet eine Adresse für ein Ziel und sagt nichts darüber, welche Routen überschrieben wurden oder welcher Resolver jetzt antwortet. Um den Schaden zu sehen, lesen Sie die Routing-Tabelle und den Resolver-Zustand.
Verschachtelung ist ein Design, keine Reihenfolge von Klicks
Wenn eine Verschachtelung beabsichtigt ist, dokumentieren Sie den äußeren Pfad jedes Endpunkts, seine Fehlerrichtlinie und die MTU-Folgen. Entscheiden Sie, was passiert, wenn der äußere Tunnel ausfällt, während der innere noch glaubt, verbunden zu sein. Clients in einer glücklichen Reihenfolge zu starten ist keine Konfiguration, denn das nächste Update oder Wiederverbinden ordnet sie neu. Eine verschachtelte Anordnung braucht dieselbe Sorgfalt wie jede andere Topologie.
Wenn eine Verbindung für die Arbeit und eine andere privat ist, verlassen Sie sich auf die Isolation oder verwaltete Regelung, die die Plattform unterstützt. Die Unternehmenskontrollen herauszureißen ist keine Trennungsstrategie.
Prüfen Sie mit der Anwendung, nicht mit dem Symbol
Testen Sie die Anwendungen, die wirklich wichtig sind, aus jedem Kontext, den Sie nutzen wollen, und nehmen Sie Resolver-Verhalten und Wiederverbindungen in den Test auf. Eine endgültige Exit-Adresse kann nicht jede überschriebene Route identifizieren, und ein grünes Symbol kann keine davon identifizieren. Halten Sie fest, wer die Verbindung besitzt und welche Kombination tatsächlich unterstützt wird.
Wenn ein Produkt die Koexistenz mit einem anderen ausdrücklich nicht unterstützt, erzeugt eine zufällige Routen- oder Berechtigungsänderung keine wartbare Bereitstellung. Sie erzeugt eine, die bis zum nächsten Update funktioniert.
Schreiben Sie auf, welcher Client die Standardroute besitzt, welcher Resolver antwortet und was passiert, wenn jeder von ihnen stoppt.