Twee VPN’s op één telefoon: kies de opstelling, niet het aantal apps

Twee VPN’s gebruiken is niet één verzoek. Het kan betekenen dat je twee organisaties na elkaar bereikt, werk- en privé-apps gescheiden houdt, of de ene tunnel in de andere laat lopen. Android behandelt die drie gevallen volledig verschillend, en het aantal VPN-apps dat op de telefoon is geïnstalleerd is niet de architectuur. De vraag die ze scheidt is eenvoudig: moeten twee paden op hetzelfde moment bestaan voor dezelfde app?

Drie opstellingen, één vraag

Als het antwoord nee is, omdat de twee netwerken op verschillende tijden worden gebruikt, wil je een bewuste wissel. Als het antwoord nee is omdat de apps zelf gescheiden zijn, wil je profielscheiding, waarbij elke app in de context zit die zijn tunnel bezit. Als het antwoord ja is, en het ene pad het andere fysiek moet dragen, wil je een keten, en dat is de enige van de drie waarbij de volgorde deel van het ontwerp is.

Al het andere volgt uit die keuze. Wisselen heeft een overgangsvenster, scheiding heeft een beleidsgrens, en een keten heeft een overhead- en een afhankelijkheidskost. De verkeerde kiezen faalt niet netjes; het levert een telefoon op die verbonden lijkt en een app die niets bereikt.

Wisselen binnen één gebruikerscontext

Android staat één actieve VPN-dienst per gebruiker toe. Een tweede VPN-app in dezelfde context starten vervangt de eerste of wordt botweg geweigerd; het stelt de twee routesets nooit samen en stapelt zeker hun versleuteling niet. Binnen één gebruiker zijn twee tunnels een reeks, geen som.

Dat is werkbaar wanneer toegang echt sequentieel is. Geef de profielen namen zodat het actieve duidelijk is, rond alles wat gevoelig is af voordat je wisselt, en verwacht een kort venster waarin geen van beide paden volledig tot stand is gebracht. Een browsertab sluiten is niet hetzelfde als een sessie beëindigen: de tab kan zijn accountstatus behouden en gewoon het volgende verzoek via het zojuist gekozen netwerk sturen, en dat is precies de lek die mensen achteraf opmerken.

Wat wisselen je niet kan geven, is een machine die tegelijk op beide netwerken zit. Als een app van elke kant een privéadres nodig heeft, brengt geen enkele klantdiscipline dat voort.

Scheiden per profiel

Een beheerd werkprofiel is een aparte gebruiker met eigen apps, eigen keystore en eigen netwerkbeleid. Een werk-mailclient kan de tunnel van de organisatie gebruiken terwijl een persoonlijke browser een persoonlijke gebruikt, en beide kunnen tegelijk verbonden zijn omdat ze niet in dezelfde context om de plaats concurreren.

De scheiding is ook de grens. De persoonlijke browser leent de werk-tunnel niet, ziet de DNS-suffixen van het werk niet en bereikt het werknetwerk niet alleen omdat beide diensten als verbonden worden getoond. Als iemand meldt dat een link niet opent, controleer dan welke kopie van de app hem heeft afgehandeld en welk profiel dat account bezit voordat je een van de twee VPN’s aanraakt.

Behandel de grens als vast. Een tweede profiel aanmaken of een werkprofiel verwijderen om een routeringsbeslissing van een werkgever te omzeilen, vernietigt juist de scheiding die de opstelling liet werken, en op een beheerd apparaat is dat meestal een beleidsschending en geen configuratiewijziging.

Een keten, waar de volgorde het ontwerp is

Een keten is de opstelling die mensen meestal bedoelen als ze beide tegelijk zeggen: de tunnel van de telefoon reist in de tunnel van de router. Het kan werken, en de beperkingen zijn concreet. De buitenste provider moet een werkend pad naar het VPN-eindpunt van de telefoon toestaan, wat voor UDP-gebaseerde protocollen betekent dat de buitenste dienst dat verkeer niet mag blokkeren of beperken.

Begrijp wie wat ziet. De buitenste provider ziet een verbinding richting het binnenste eindpunt. De binnenste provider ontvangt het verkeer van de telefoon van de buitenste uitgang en stuurt het door. De uiteindelijke bestemming ziet normaal gesproken de uitgang van de binnenste dienst, en geen provider langs de keten is blind; appaccounts identificeren de gebruiker nog steeds, ongeacht het pad.

Verwacht praktische kosten. Elke laag voegt inkapseling toe, dus de effectieve MTU daalt en een waarde die voor één tunnel prima was, fragmenteert of stokt nu tot de MTU van de binnenste tunnel conservatief wordt gezet. Twee lagen betekenen ook twee faalafhankelijkheden en twee sets keepalive-berichten, en een TCP-gebaseerde binnenste tunnel over een verliesrijke buitenste verbinding kan stokken op manieren die op een dode server lijken.

Het belangrijkste: een keten voegt twee privénetwerken niet samen. Routes, overlappende prefixen, DNS-resolutie en toegangsregels blijven aparte beslissingen, en een router die één VPN draagt terwijl een telefoon een andere draagt, geeft de telefoon niet beide adresruimtes.

Controleer het ontwerp voordat je het gaat debuggen

Schrijf de opstelling in één zin op en test hem tegen de app die faalde. Sequentiële toegang zou één tunnel tegelijk moeten tonen; profielscheiding zou elke app in zijn eigen gebruiker moeten tonen; een keten zou moeten tonen dat de binnenste tunnel zich opbouwt over een buitenste interface in plaats van de fysieke.

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

Als de route-opzoeking de fysieke interface noemt terwijl een app de tunnel verwacht, zijn het ontwerp en de app-context het oneens, en geen enkele extra VPN-app zal ze verzoenen. De documentatie over beheerde profielen dekt de scheidingsregels als je het beleidsdetail nodig hebt in plaats van het routeringsdetail.