To VPN-er på én telefon: velg oppsettet, ikke antall apper

Å bruke to VPN-er er ikke én forespørsel. Det kan bety å nå to organisasjoner etter hverandre, å holde jobb- og privatapper atskilt, eller å kjøre én tunnel inne i en annen. Android håndterer disse tre tilfellene på helt forskjellige måter, og antallet VPN-apper som er installert på telefonen er ikke arkitekturen. Spørsmålet som skiller dem er enkelt: må to veier finnes i samme øyeblikk for den samme appen?

Tre oppsett, ett spørsmål

Hvis svaret er nei, fordi de to nettene brukes på forskjellige tider, vil du ha et bevisst bytte. Hvis svaret er nei fordi appene selv er atskilt, vil du ha profildeling, der hver app sitter i konteksten som eier tunnelen sin. Hvis svaret er ja, og én vei fysisk må bære den andre, vil du ha en kjede, og det er den eneste av de tre der rekkefølgen er en del av designet.

Alt annet følger av det valget. Bytte har et overgangsvindu, deling har en policygrense, og en kjede har en meromkostning og en avhengighetskostnad. Å velge den gale feiler ikke rent; den produserer en telefon som ser tilkoblet ut og en app som ikke når noe.

Bytte innenfor én brukerkontekst

Android tillater én aktiv VPN-tjeneste per bruker. Å starte en andre VPN-app i samme kontekst erstatter den første eller avvises blankt; den setter aldri sammen de to rutessettene, og den stabler i hvert fall ikke krypteringen deres. Innenfor én bruker er to tunneler en sekvens, ikke en sum.

Det er gjennomførbart når tilgangen virkelig er sekvensiell. Gi profilene navn slik at den aktive er åpenbar, fullfør alt følsomt før du bytter, og forvent et kort vindu der ingen av de to veiene er fullt etablert. Å lukke en nettleserfane er ikke det samme som å avslutte en økt: fanen kan beholde kontotilstanden sin og bare sende den neste forespørselen over nettverket som nettopp ble valgt, og det er nøyaktig lekkasjen folk legger merke til etterpå.

Det bytte ikke kan gi deg, er en maskin som er på begge nettverkene samtidig. Hvis en app trenger en privat adresse fra hver side, vil ingen klientdisiplin frembringe den.

Skille etter profil

En administrert jobbprofil er en egen bruker med egne apper, eget nøkkellager og egen nettverkspolicy. En jobb-e-postklient kan bruke organisasjonens tunnel mens en personlig nettleser bruker en personlig, og begge kan være tilkoblet samtidig fordi de ikke er i samme kontekst og konkurrerer om plassen.

Skillet er også grensen. Den personlige nettleseren låner ikke jobbtunnelen, ser ikke jobbens DNS-suffikser og når ikke jobbnettverket bare fordi begge tjenestene vises som tilkoblet. Når noen melder at en lenke ikke åpnes, sjekk hvilken kopi av appen som håndterte den og hvilken profil som eier den kontoen, før du berører noen av de to VPN-ene.

Behandle grensen som fast. Å opprette en andre profil eller fjerne en jobbprofil for å omgå en arbeidsgivers rutingsbeslutning ødelegger nettopp skillet som gjorde oppsettet funksjonelt, og på en administrert enhet er det vanligvis et policybrudd og ikke en konfigurasjonsendring.

En kjede, der rekkefølgen er designet

En kjede er oppsettet folk vanligvis mener når de sier begge samtidig: telefonens tunnel reiser inne i ruternes tunnel. Det kan fungere, og begrensningene er konkrete. Den ytre leverandøren må tillate en fungerende vei til telefonens VPN-endepunkt, noe som for UDP-baserte protokoller betyr at den ytre tjenesten ikke må blokkere eller begrense den trafikken.

Forstå hvem som ser hva. Den ytre leverandøren ser en tilkobling mot det indre endepunktet. Den indre leverandøren mottar telefonens trafikk fra den ytre utgangen og videresender den. Den endelige destinasjonen ser vanligvis den indre tjenestens utgang, og ingen leverandør langs kjeden er blind; appkontoer identifiserer fortsatt brukeren uansett rute.

Forvent praktiske kostnader. Hvert lag legger til innkapsling, så den effektive MTU-en faller, og en verdi som var fin for én tunnel fragmenteres eller stopper nå, til MTU-en for den indre tunnelen settes konservativt. To lag betyr også to feilavhengigheter og to sett keepalive-meldinger, og en TCP-basert indre tunnel over en tapsutsatt ytre lenke kan stoppe på måter som ser ut som en død server.

Viktigst: en kjede smelter ikke sammen to private nettverk. Ruter, overlappende prefikser, DNS-oppslag og tilgangsregler forblir separate beslutninger, og en ruter som bærer én VPN mens en telefon bærer en annen, gir ikke telefonen begge adresserommene.

Sjekk designet før du feilsøker det

Skriv oppsettet ned i én setning og test det mot appen som feilet. Sekvensiell tilgang bør vise én tunnel om gangen; profildeling bør vise hver app i sin egen bruker; en kjede bør vise den indre tunnelen etablere seg over et ytre grensesnitt i stedet for det fysiske.

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

Hvis ruteoppslaget navngir det fysiske grensesnittet mens en app forventer tunnelen, er ikke designet og appkonteksten enige, og ingen ekstra VPN-app vil forlike dem. Dokumentasjonen om administrerte profiler dekker delingsreglene hvis du trenger policydetaljen i stedet for rutingsdetaljen.