Zwei iPhone-VPNs gleichzeitig: Welches trägt den Datenverkehr?

Zwei VPN-Apps zeigen beide Verbunden an, und die Annahme ist, dass der Datenverkehr nun durch beide läuft, die eine in der anderen. Meistens ist das nicht der Fall. iOS hat ein bestimmtes Koexistenzmodell, und es ist keine Kette. Eine Konfigurationsklasse ist auf eine einzige aktivierte Instanz beschränkt, die andere kann daneben laufen, und die Routenpriorität entscheidet Konflikte. Zwei eingeschaltete Schalter sind keine zwei Hops. Das Modell ist dokumentiert, also lässt sich der Pfad vorhersagen, statt ihn aus den Symbolen zu erraten.

Mythos: zwei verbundene VPNs sind eine Kette

Eine Kette mit zwei Hops braucht einen definierten äußeren Transport, einen definierten inneren Tunnel, kompatibles Endpunkt-Routing und einen Plan, was passiert, wenn einer der beiden ausfällt. Zwei unabhängige Konfigurationen erzeugen das nicht allein dadurch, dass sie gleichzeitig existieren. Routenpriorität ist nicht dasselbe wie Kapselung, und dass eine Konfiguration eine Routensuche gewinnt, sagt nichts darüber, ob die andere die resultierenden Pakete trägt.

Wenn Sie Verschachtelung brauchen, entwerfen Sie sie als Verschachtelung. Leiten Sie sie nicht aus zwei Verbindungsindikatoren ab. Diese Unterscheidung spart viel Fehlersuche.

Das dokumentierte Modell hinter diesem Mythos

Apples NETunnelProviderManager beschreibt reguläre Unternehmens-VPN-Konfigurationen und stellt fest, dass von dieser Art nur eine gleichzeitig aktiviert sein kann. Dieselbe Referenz erlaubt es einem Personal VPN, daneben aktiviert und verbunden zu bleiben, und gibt den Unternehmensrouten Vorrang, wo sich beide überschneiden.

Personal VPN ist hier der API-Begriff für die integrierte IPsec- oder IKEv2-Implementierung, die über NEVPNManager verwaltet wird. NETunnelProviderManager ist das Tunnelanbieter-Modell. Eine Verbraucher-App kann das Anbietermodell verwenden, ein Produktname mit personal klassifiziert sie also nicht.

Apple dokumentiert eine zulässige Kombination, und die Erlaubnis sagt nichts darüber, ob die Profile zweier Anbieter kompatibel sind, deshalb fragen Sie jeden Anbieter, welches Paar unterstützt wird. Ihre Konfigurationstypen, Routen und Richtlinien entscheiden weiterhin das Ergebnis.

Mythos: das persönliche VPN bekommt den Surfverkehr

Ein Arbeitsprofil, das jedes Ziel beansprucht, gewinnt die Routensuche auch für öffentliches Surfen, sodass der persönliche Ausgang nichts davon trägt. Nach der dokumentierten Priorität gewinnen die Unternehmensrouten, wo sie kollidieren, also nimmt öffentliches Surfen nicht automatisch den persönlichen Ausgang, nur weil diese App ebenfalls verbunden meldet. Eine engere Arbeitskonfiguration kann das Routingbild ändern, aber der Client der Organisation kann weiterhin DNS-, Sperr- oder Geräteanforderungen auferlegen. Holen Sie die unterstützte Regelung von ihrem Eigentümer, statt diese Anforderungen lokal zu ändern.

Verwaltete Konfigurationen pro App haben ihren eigenen Geltungsbereich. Übertragen Sie eine Regel auf Geräteebene nicht auf jede verwaltete Bereitstellung.

Notieren Sie vor dem Test die beiden Ströme: den privaten Namen und Bereich des Arbeitsdienstes und eine frische öffentliche Browsing-Anfrage. Beide sind legitim, und sie brauchen unterschiedliche Prüfungen.

Routenpriorität mit einem Arbeitsprofil mit geteiltem Tunnel

Ein Arbeitsprofil mit geteiltem Tunnel beansprucht die privaten Präfixe und das interne DNS-Suffix, die es auflistet, und diese Routen gewinnen jede Suche, die zu ihnen passt. Öffentliche Ziele, die zu keiner Unternehmensroute passen, fallen auf die physische Verbindung durch, es sei denn, das persönliche VPN beansprucht sie zuerst. Die Vorrangregel entscheidet nur die überlappenden Treffer, weshalb die beiden Profile als Routentabellen und nicht als Symbole gelesen werden müssen.

Schreiben Sie das Paar als zwei Zeilen und benennen Sie den erwarteten Gewinner für jede: Ein Arbeits-Hostname, der sich zu 10.x oder 172.16.x auflöst, sollte durch den Unternehmens-Tunnel hinausgehen, und eine öffentliche Adresse ohne passendes Präfix sollte die verbleibende Standardroute nehmen. Wenn beide Zeilen denselben Ausgang nennen, leistet die Aufteilung nicht, was die Dokumentation beschreibt.

Zwei Ströme notieren und jeden testen

Halten Sie für jeden Strom fest, welche genehmigte Konfiguration ihn tragen soll und welcher Resolver jede Namensart erhalten soll. Überprüfen Sie dann mit frischen Anfragen, nicht mit einer zwischengespeicherten Arbeitsseite oder einem alten IP-Ergebnis.

Stoppen Sie eine Konfiguration und wiederholen Sie beide Ströme. Das Fehlerverhalten ist Teil des Entwurfs, und es ist der Teil, den Nutzer bemerken. Wenn die beiden Anbieter die Kombination nicht unterstützen können, legen Sie sich auf eine genehmigte Konfiguration fest und dokumentieren Sie, welchen Strom sie trägt, oder wechseln Sie zu einem verwalteten Einzeltunnel-Design. Die NETunnelProviderManager-Dokumentation ist die Quelle für die Koexistenzregel.