To VPN-ar på ein telefon: vel oppsettet, ikkje talet på apper

Å bruke to VPN-ar er ikkje éin førespurnad. Det kan tyde å nå to organisasjonar etter kvarandre, halde jobb- og privatappar fråskilde, eller køyre éin tunnel inne i ein annan. Android handterer desse tre tilfella på heilt ulike måtar, og talet på VPN-appar som er installerte på telefonen er ikkje arkitekturen. Spørsmålet som skil dei er enkelt: må to vegan finnast i same augneblink for den same appen?

Tre oppsett, eitt spørsmål

Viss svaret er nei, fordi dei to netta vert brukte på ulike tider, vil du ha eit medvite bytte. Viss svaret er nei fordi appane sjølve er fråskilde, vil du ha profildeling, der kvar app sit i konteksten som eig tunnelen sin. Viss svaret er ja, og éin veg fysisk må bere den andre, vil du ha ei kjede, og det er den einaste av dei tre der rekkjefølgja er ein del av designet.

Alt anna følgjer av det valet. Bytte har eit overgangsvindauge, deling har ei policygrense, og ei kjede har ein meirkostnad og ein avhengigheitskostnad. Å velje den gale feilar ikkje reint; ho produserer ein telefon som ser tilkopla ut og ein app som ikkje når noko.

Bytte innanfor éin brukarkontekst

Android tillèt éi aktiv VPN-teneste per brukar. Å starte ein annan VPN-app i same kontekst erstattar den fyrste eller vert avvist blankt; han set aldri saman dei to ruttesetta, og han staplar i alle fall ikkje krypteringa deira. Innanfor éin brukar er to tunnelar ein sekvens, ikkje ein sum.

Det er gjennomføreleg når tilgangen verkeleg er sekvensiell. Gje profilane namn slik at den aktive er openberr, fullfør alt kjenslevart før du byter, og vent eit kort vindauge der ingen av dei to vegane er fullt etablert. Å lukke ei nettlesarfane er ikkje det same som å avslutte ei økt: fana kan halde på kontotilstanden sin og berre sende den neste førespurnaden over nettet som nettopp vart valt, og det er nøyaktig lekkasjen folk legg merke til etterpå.

Det byttet ikkje kan gje deg, er ein maskin som er på begge netta samstundes. Viss ein app treng ei privat adresse frå kvar side, vil ingen klientdisiplin frambringe henne.

Skilje etter profil

Ein administrert jobbprofil er ein eigen brukar med eigne appar, eige nøkkellager og eigen nettverkspolicy. Ein jobb-e-postklient kan bruke tunnelen til organisasjonen medan ein personleg nettlesar brukar ein personleg, og begge kan vere tilkopla samstundes fordi dei ikkje er i same kontekst og konkurrerer om plassen.

Skiljet er også grensa. Den personlege nettlesaren låner ikkje jobbtunnelen, ser ikkje DNS-suffiksa til jobben og når ikkje jobbnettet berre fordi begge tenestene viser seg som tilkopla. Når nokon melder at ei lenkje ikkje opnar, sjekk kva kopi av appen som handterte henne og kva profil som eig den kontoen, før du rører nokon av dei to VPN-ane.

Behandle grensa som fast. Å opprette ein andre profil eller fjerne ein jobbprofil for å omgå ei rutingsavgjerd frå ein arbeidsgjevar øydelegg nettopp skiljet som gjorde oppsettet funksjonelt, og på ein administrert eining er det vanlegvis eit policybrot og ikkje ei konfigurasjonsendring.

Ei kjede, der rekkjefølgja er designet

Ei kjede er oppsettet folk vanlegvis meiner når dei seier begge samstundes: tunnelen til telefonen reiser inne i tunnelen til ruteren. Det kan fungere, og avgrensingane er konkrete. Den ytre leverandøren må tillate ein fungerande veg til VPN-endepunktet til telefonen, noko som for UDP-baserte protokollar betyr at den ytre tenesta ikkje må blokkere eller avgrense den trafikken.

Forstå kven som ser kva. Den ytre leverandøren ser ei tilkopling mot det indre endepunktet. Den indre leverandøren tek imot trafikken til telefonen frå den ytre utgangen og videresender han. Den endelege destinasjonen ser vanlegvis utgangen til den indre tenesta, og ingen leverandør langs kjeda er blind; appkontoar identifiserer framleis brukaren uansett rute.

Vent praktiske kostnader. Kvart lag legg til innkapsling, så den effektive MTU-en fell, og ein verdi som var fin for éin tunnel vert no fragmentert eller stoggar, til MTU-en til den indre tunnelen vert sett konservativt. To lag tyder også to feilavhengigheiter og to sett keepalive-meldingar, og ein TCP-basert indre tunnel over ei tapsutsett ytre lenkje kan stogge på måtar som ser ut som ein død tenar.

Viktigast: ei kjede smeltar ikkje saman to private nett. Ruter, overlappande prefiks, DNS-oppslag og tilgangsreglar er framleis separate avgjerder, og ein ruter som ber éin VPN medan ein telefon ber ein annan, gjev ikkje telefonen båe adresseromma.

Sjekk designet før du feilsøkjer det

Skriv oppsettet ned i éi setning og test det mot appen som feila. Sekvensiell tilgang bør vise éin tunnel om gongen; profildeling bør vise kvar app i sin eigen brukar; ei kjede bør vise den indre tunnelen etablere seg over eit ytre grensesnitt i staden for det fysiske.

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

Viss ruteoppslaget nemner det fysiske grensesnittet medan ein app ventar på tunnelen, er ikkje designet og appkonteksten samde, og ingen ekstra VPN-app vil forlike dei. Dokumentasjonen om administrerte profilar dekkjer delingsreglane viss du treng policydetaljen i staden for rutingsdetaljen.