Twee iPhone-VPN's tegelijk: welke draagt je verkeer?

Twee VPN-apps tonen beide Connected, en de aanname is dat het verkeer nu door beide gaat, de ene in de andere. Meestal is dat niet zo. iOS heeft een specifiek coëxistentiemodel, en dat is geen keten. Eén configuratieklasse is beperkt tot één ingeschakelde instantie, de andere kan ernaast draaien, en routeprioriteit beslist conflicten. Twee brandende schakelaars zijn geen twee hops. Het model is gedocumenteerd, wat betekent dat het pad kan worden voorspeld in plaats van geraden uit de pictogrammen.

Mythe: twee verbonden VPN's zijn een keten

Een keten van twee hops vereist een gedefinieerd buitenste transport, een gedefinieerde binnenste tunnel, compatibele endpoint-routing en een plan voor wat er gebeurt als een van beide faalt. Twee onafhankelijke configuraties creëren dat niet alleen door tegelijk te bestaan. Routeprioriteit is niet hetzelfde als inkapseling, en dat één configuratie een route-opzoeking wint zegt niets over of de andere de resulterende pakketten draagt.

Als je nesting nodig hebt, ontwerp het dan als nesting. Leid het niet af uit twee verbindingsindicatoren. Dat onderscheid bespaart veel debuggen.

Het gedocumenteerde model achter die mythe

Apples NETunnelProviderManager beschrijft gewone enterprise-VPN-configuraties en stelt dat daarvan slechts één tegelijk kan worden ingeschakeld. Dezelfde referentie staat toe dat een Personal VPN ernaast ingeschakeld en verbonden blijft, en geeft de enterpriseroutes voorrang waar de twee overlappen.

Personal VPN is hier de API-term voor de ingebouwde IPsec- of IKEv2-implementatie die via NEVPNManager wordt beheerd. NETunnelProviderManager is het tunnelprovider-model. Een consumenten-app kan het providermodel gebruiken, dus een productnaam met personal classificeert het niet.

Apple documenteert één toegestane combinatie, en de toestemming zegt niet dat de profielen van twee leveranciers compatibel zijn, dus vraag elke leverancier welk paar wordt ondersteund. Hun configuratietypen, routes en beleid beslissen nog steeds het resultaat.

Mythe: de persoonlijke VPN krijgt het browseverkeer

Een werkprofiel dat elke bestemming opeist, wint ook de route-opzoeking voor openbaar browsen, dus de persoonlijke uitgang draagt daar niets van. Volgens de gedocumenteerde voorrang winnen de enterpriseroutes waar ze botsen, dus openbaar browsen neemt niet automatisch de persoonlijke uitgang alleen omdat die app ook verbonden meldt. Een smallere werkconfiguratie kan het routingbeeld veranderen, maar de client van de organisatie kan nog steeds DNS-, blokkeer- of apparaatvereisten opleggen. Haal de ondersteunde regeling bij de eigenaar op in plaats van die vereisten lokaal te bewerken.

Beheerde configuraties per app hebben hun eigen bereik. Generaliseer een regel op apparaatniveau niet naar elke beheerde uitrol.

Noteer de twee stromen voor je test: de privénaam en het bereik van de werkdienst, en een nieuwe openbare browse-aanvraag. Beide zijn legitiem, en ze vragen verschillende controles.

Routeprioriteit met een werkprofiel met gesplitste tunnel

Een werkprofiel met gesplitste tunnel eist de privéprefixen en het interne DNS-suffix dat het vermeldt, en die routes winnen elke opzoeking die erbij past. Openbare bestemmingen die bij geen enkele enterpriseroute passen, vallen terug op de fysieke link tenzij de persoonlijke VPN ze eerst opeist. De voorrangsregel beslist alleen de overlappende treffers, daarom moeten de twee profielen als routetabellen worden gelezen en niet als pictogrammen.

Schrijf het paar als twee regels en noem de verwachte winnaar voor elk: een werkhostnaam die naar 10.x of 172.16.x resolvet, zou via de enterprisetunnel naar buiten moeten gaan, en een openbaar adres zonder passende prefix zou de resterende standaardroute moeten nemen. Als beide regels dezelfde uitgang noemen, doet de splitsing niet wat de documentatie beschrijft.

Noteer twee stromen en test elk

Noteer voor elke stroom welke goedgekeurde configuratie die moet dragen en welke resolver elk soort naam moet ontvangen. Controleer daarna met nieuwe aanvragen, niet met een gecachte werkpagina of een oud IP-resultaat.

Stop één configuratie en herhaal beide stromen. Het faalgedrag is deel van het ontwerp, en het is het deel dat gebruikers opmerken. Wanneer de twee providers de combinatie niet kunnen ondersteunen, kies dan één goedgekeurde configuratie en documenteer welke stroom die draagt, of stap over op een beheerd ontwerp met één tunnel. De NETunnelProviderManager-documentatie is de bron van de coëxistentieregel.