Zwei VPNs auf einem Telefon: die Anordnung wählen, nicht die App-Anzahl

Zwei VPNs zu nutzen ist keine einzelne Anforderung. Es kann bedeuten, zwei Organisationen nacheinander zu erreichen, Arbeits- und Privat-Apps getrennt zu halten oder einen Tunnel in einem anderen laufen zu lassen. Android behandelt diese drei Fälle völlig unterschiedlich, und die Anzahl der auf dem Telefon installierten VPN-Apps ist nicht die Architektur. Die Frage, die sie trennt, ist einfach: Müssen zwei Pfade im selben Moment für dieselbe App existieren?

Drei Anordnungen, eine Frage

Ist die Antwort nein, weil die beiden Netze zu unterschiedlichen Zeiten genutzt werden, wollen Sie einen bewussten Wechsel. Ist die Antwort nein, weil die Apps selbst getrennt sind, wollen Sie eine Profiltrennung, bei der jede App in dem Kontext sitzt, dem ihr Tunnel gehört. Ist die Antwort ja und muss ein Pfad den anderen physisch tragen, wollen Sie eine Kette, und das ist die einzige der drei, bei der die Reihenfolge Teil des Entwurfs ist.

Alles andere folgt aus dieser Wahl. Ein Wechsel hat ein Übergangsfenster, eine Trennung hat eine Politikgrenze, und eine Kette hat einen Overhead- und einen Abhängigkeitspreis. Die falsche zu wählen scheitert nicht sauber; sie erzeugt ein Telefon, das verbunden aussieht, und eine App, die nichts erreicht.

Wechseln innerhalb eines Nutzerkontexts

Android erlaubt einen aktiven VPN-Dienst pro Nutzer. Eine zweite VPN-App im selben Kontext zu starten ersetzt die erste oder wird rundweg abgelehnt; sie fügt die beiden Routensätze nie zusammen und stapelt schon gar nicht ihre Verschlüsselung. Innerhalb eines Nutzers sind zwei Tunnel eine Abfolge, keine Summe.

Das ist praktikabel, wenn der Zugang wirklich sequenziell ist. Benennen Sie die Profile so, dass das aktive offensichtlich ist, schließen Sie alles Sensible ab, bevor Sie wechseln, und rechnen Sie mit einem kurzen Fenster, in dem keiner der beiden Pfade vollständig aufgebaut ist. Einen Browsertab zu schließen ist nicht dasselbe wie eine Sitzung zu beenden: Der Tab kann seinen Kontozustand behalten und die nächste Anfrage einfach über das neu gewählte Netz senden, und genau das ist das Leck, das Leute hinterher bemerken.

Was ein Wechsel Ihnen nicht geben kann, ist eine Maschine, die in beiden Netzen gleichzeitig ist. Wenn eine App eine private Adresse von jeder Seite braucht, wird keine noch so große Client-Disziplin sie erzeugen.

Trennung nach Profil

Ein verwaltetes Arbeitsprofil ist ein eigener Nutzer mit eigenen Apps, eigenem Keystore und eigener Netzwerkrichtlinie. Ein Arbeits-Mailclient kann den Tunnel der Organisation nutzen, während ein privater Browser einen privaten nutzt, und beide können gleichzeitig verbunden sein, weil sie nicht im selben Kontext um den Platz konkurrieren.

Die Trennung ist auch die Grenze. Der private Browser leiht sich den Arbeitstunnel nicht, sieht die DNS-Suffixe der Arbeit nicht und erreicht das Arbeitsnetz nicht, nur weil beide Dienste als verbunden angezeigt werden. Wenn jemand meldet, dass ein Link nicht öffnet, prüfen Sie, welche Kopie der App ihn bearbeitet hat und welches Profil dieses Konto besitzt, bevor Sie eines der beiden VPNs anfassen.

Behandeln Sie die Grenze als fest. Ein zweites Profil anzulegen oder ein Arbeitsprofil zu entfernen, um die Routing-Entscheidung eines Arbeitgebers zu umgehen, zerstört genau die Trennung, die die Anordnung funktionieren ließ, und auf einem verwalteten Gerät ist das meist ein Richtlinienverstoß statt einer Konfigurationsänderung.

Eine Kette, bei der die Reihenfolge der Entwurf ist

Eine Kette ist die Anordnung, die Leute meist meinen, wenn sie beides gleichzeitig sagen: Der Tunnel des Telefons reist im Tunnel des Routers. Es kann funktionieren, und die Einschränkungen sind konkret. Der äußere Anbieter muss einen funktionierenden Pfad zum VPN-Endpunkt des Telefons zulassen, was bei UDP-basierten Protokollen bedeutet, dass der äußere Dienst diesen Verkehr nicht blockieren oder drosseln darf.

Verstehen Sie, wer was sieht. Der äußere Anbieter sieht eine Verbindung zum inneren Endpunkt. Der innere Anbieter empfängt den Verkehr des Telefons vom äußeren Ausgang und leitet ihn weiter. Das endgültige Ziel sieht normalerweise den Ausgang des inneren Dienstes, und kein Anbieter entlang der Kette ist blind; Anwendungskonten identifizieren den Nutzer weiterhin unabhängig vom Pfad.

Rechnen Sie mit praktischen Kosten. Jede Schicht fügt Kapselung hinzu, sodass die effektive MTU sinkt und ein Wert, der für einen Tunnel in Ordnung war, nun fragmentiert oder stockt, bis die MTU des inneren Tunnels konservativ gesetzt wird. Zwei Schichten bedeuten auch zwei Ausfallabhängigkeiten und zwei Sätze Keepalives, und ein TCP-basierter innerer Tunnel über eine verlustbehaftete äußere Strecke kann auf Arten stocken, die wie ein toter Server aussehen.

Vor allem: Eine Kette verschmilzt nicht zwei private Netze. Routen, überlappende Präfixe, DNS-Auflösung und Zugriffsregeln bleiben getrennte Entscheidungen, und ein Router, der ein VPN trägt, während ein Telefon ein anderes trägt, gibt dem Telefon nicht beide Adressräume.

Prüfen Sie den Entwurf, bevor Sie ihn debuggen

Schreiben Sie die Anordnung in einem Satz auf und testen Sie sie gegen die App, die versagt hat. Sequenzieller Zugang sollte jeweils einen Tunnel zeigen; Profiltrennung sollte jede App in ihrem eigenen Nutzer zeigen; eine Kette sollte zeigen, dass der innere Tunnel über eine äußere Schnittstelle aufgebaut wird statt über die physische.

adb shell ip -br addr
adb shell ip route get 10.20.0.8
adb shell dumpsys connectivity | grep -i vpn

Wenn die Routensuche die physische Schnittstelle nennt, während eine App den Tunnel erwartet, stimmen Entwurf und App-Kontext nicht überein, und keine zusätzliche VPN-App wird sie versöhnen. Die Dokumentation zu verwalteten Profilen deckt die Trennungsregeln ab, wenn Sie das Richtlinien- statt des Routing-Details brauchen.