Två VPN i en och samma telefon: välj upplägget, inte antalet appar

Att använda två VPN är inte en enda begäran. Det kan betyda att nå två organisationer efter varandra, att hålla arbets- och privatappar åtskilda, eller att köra en tunnel inuti en annan. Android hanterar de tre fallen på helt olika sätt, och antalet VPN-appar installerade i telefonen är inte arkitekturen. Frågan som skiljer dem är enkel: måste två vägar finnas i samma ögonblick för samma app?

Tre upplägg, en fråga

Om svaret är nej, eftersom de två näten används vid olika tidpunkter, vill du ha ett medvetet byte. Om svaret är nej eftersom apparna själva är åtskilda, vill du ha profilseparering, där varje app sitter i det sammanhang som äger dess tunnel. Om svaret är ja, och en väg fysiskt måste bära den andra, vill du ha en kedja, och det är den enda av de tre där ordningen är en del av konstruktionen.

Allt annat följer av det valet. Byte har ett övergångsfönster, separering har en policygräns, och en kedja har en överkostnad och en beroendekostnad. Att välja den felaktiga misslyckas inte rent; den ger en telefon som ser ansluten ut och en app som inte når något.

Byta inom en och samma användarkontext

Android tillåter en aktiv VPN-tjänst per användare. Att starta en andra VPN-app i samma kontext ersätter den första eller avvisas direkt; den sammanfogar aldrig de två ruttsätten och staplar definitivt inte deras kryptering. Inom en användare är två tunnlar en sekvens, inte en summa.

Det är genomförbart när åtkomsten verkligen är sekventiell. Namnge profilerna så att den aktiva är uppenbar, slutför allt känsligt innan du byter, och förvänta dig ett kort fönster där ingen av de två vägarna är fullt etablerad. Att stänga en flik i webbläsaren är inte samma sak som att avsluta en session: fliken kan behålla sitt kontoläge och bara skicka nästa begäran över nätet som just valdes, och det är precis den läcka som folk märker efteråt.

Vad byte inte kan ge dig är en maskin som är på båda näten samtidigt. Om en app behöver en privat adress från varje sida kommer ingen klientdisciplin att åstadkomma det.

Separera per profil

En hanterad arbetsprofil är en separat användare med egna appar, eget nyckellager och egen nätverkspolicy. En arbetsmejlklient kan använda organisationens tunnel medan en personlig webbläsare använder en personlig, och båda kan vara anslutna samtidigt eftersom de inte är i samma kontext och konkurrerar om platsen.

Separeringen är också gränsen. Den personliga webbläsaren lånar inte arbetstunneln, ser inte arbetets DNS-suffix och når inte arbetsnätet bara för att båda tjänsterna visas som anslutna. När någon rapporterar att en länk inte öppnas, kontrollera vilken kopia av appen som hanterade den och vilken profil som äger det kontot innan du rör någon av de två VPN:erna.

Behandla gränsen som fast. Att skapa en andra profil eller ta bort en arbetsprofil för att kringgå en arbetsgivares routingbeslut förstör just den separering som gjorde upplägget fungerande, och på en hanterad enhet är det oftast en policyöverträdelse och inte en konfigurationsändring.

En kedja, där ordningen är konstruktionen

En kedja är det upplägg folk oftast menar när de säger båda samtidigt: telefonens tunnel reser inuti routerns tunnel. Det kan fungera, och begränsningarna är konkreta. Den yttre leverantören måste tillåta en fungerande väg till telefonens VPN-slutpunkt, vilket för UDP-baserade protokoll betyder att den yttre tjänsten inte får blockera eller strypa den trafiken.

Förstå vem som ser vad. Den yttre leverantören ser en anslutning mot den inre slutpunkten. Den inre leverantören tar emot telefonens trafik från den yttre utgången och vidarebefordrar den. Den slutliga destinationen ser normalt den inre tjänstens utgång, och ingen leverantör längs kedjan är blind; appkonton identifierar fortfarande användaren oavsett väg.

Förvänta dig praktiska kostnader. Varje lager lägger till inkapsling, så den effektiva MTU:n sjunker och ett värde som var bra för en tunnel fragmenteras eller stannar nu tills den inre tunnelns MTU sätts konservativt. Två lager innebär också två felberoenden och två uppsättningar keepalive-meddelanden, och en TCP-baserad inre tunnel över en förlustdrabbad yttre länk kan stanna på sätt som ser ut som en död server.

Viktigast: en kedja smälter inte samman två privata nät. Rutter, överlappande prefix, DNS-uppslagning och åtkomstregler förblir separata beslut, och en router som bär ett VPN medan en telefon bär ett annat ger inte telefonen båda adressrymderna.

Kontrollera konstruktionen innan du felsöker den

Skriv ner upplägget i en mening och testa det mot appen som misslyckades. Sekventiell åtkomst bör visa en tunnel i taget; profilseparering bör visa varje app i sin egen användare; en kedja bör visa att den inre tunneln etableras över ett yttre gränssnitt i stället för det fysiska.

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

Om ruttsökningen namnger det fysiska gränssnittet medan en app förväntar sig tunneln, är konstruktionen och appens kontext inte överens, och ingen extra VPN-app kommer att försona dem. Dokumentationen om hanterade profiler täcker separeringsreglerna om du behöver policydetaljen i stället för routingdetaljen.