To VPN’er på én telefon: vælg opstillingen, ikke antallet af apps

At bruge to VPN’er er ikke én anmodning. Det kan betyde at nå to organisationer den ene efter den anden, at holde arbejds- og personlige apps adskilt eller at køre én tunnel inde i en anden. Android håndterer de tre tilfælde på helt forskellige måder, og antallet af VPN-apps installeret på telefonen er ikke arkitekturen. Spørgsmålet, der skiller dem, er enkelt: skal to veje findes i samme øjeblik for den samme app?

Tre opstillinger, ét spørgsmål

Hvis svaret er nej, fordi de to netværk bruges på forskellige tidspunkter, vil du have et bevidst skift. Hvis svaret er nej, fordi appene selv er adskilte, vil du have profiladskillelse, hvor hver app sidder i den kontekst, der ejer dens tunnel. Hvis svaret er ja, og én vej fysisk skal bære den anden, vil du have en kæde, og det er den eneste af de tre, hvor rækkefølgen er en del af designet.

Alt andet følger af det valg. Skift har et overgangsvindue, adskillelse har en politikgrænse, og en kæde har en meromkostning og en afhængighedsomkostning. At vælge den forkerte fejler ikke rent; den producerer en telefon, der ser forbundet ud, og en app, der ikke kan nå noget.

Skift inden for én brugerkontekst

Android tillader én aktiv VPN-tjeneste for hver bruger. At starte en anden VPN-app i den samme kontekst erstatter den første eller afvises blankt; den sammensætter aldrig de to rutensæt og stabler bestemt ikke deres kryptering. Inden for én bruger er to tunneler en sekvens, ikke en sum.

Det er brugbart, når adgangen virkelig er sekventiel. Navngiv profilerne, så den aktive er indlysende, afslut alt følsomt, før du skifter, og forvent et kort vindue, hvor ingen af de to veje er fuldt etableret. At lukke en browservane er ikke det samme som at afslutte en session: fanen kan beholde sin kontotilstand og blot sende den næste anmodning over det netværk, der netop er valgt, og det er præcis den lækage, folk bemærker bagefter.

Det, skift ikke kan give dig, er en maskine, der er på begge netværk på én gang. Hvis en app har brug for en privat adresse fra hver side, vil ingen mængde klientdisciplin frembringe den.

Adskillelse efter profil

En administreret arbejdsprofil er en separat bruger med sine egne apps, sit eget nøglelager og sin egen netværkspolitik. En arbejdsmailklient kan bruge organisationens tunnel, mens en personlig browser bruger en personlig, og begge kan være forbundet på samme tid, fordi de ikke er i samme kontekst og konkurrerer om pladsen.

Adskillelsen er også grænsen. Den personlige browser låner ikke arbejdstunnelen, ser ikke arbejdets DNS-suffikser og når ikke arbejdsnetværket, blot fordi begge tjenester vises som forbundne. Når nogen rapporterer, at et link ikke åbner, så kontrollér, hvilken kopi af appen der håndterede det, og hvilken profil der ejer den konto, før du rører nogen af de to VPN’er.

Behandl grænsen som fast. At oprette en anden profil eller fjerne en arbejdsprofil for at omgå en arbejdsgivers rutebeslutning ødelægger netop den adskillelse, der fik opstillingen til at fungere, og på en administreret enhed er det normalt en politikovertrædelse snarere end en konfigurationsændring.

En kæde, hvor rækkefølgen er designet

En kæde er den opstilling, folk normalt mener, når de siger begge på én gang: telefonens tunnel rejser inde i routerens tunnel. Det kan fungere, og begrænsningerne er konkrete. Den ydre udbyder skal tillade en fungerende vej til telefonens VPN-endepunkt, hvilket for UDP-baserede protokoller betyder, at den ydre tjeneste ikke må blokere eller begrænse den trafik.

Forstå, hvem der ser hvad. Den ydre udbyder ser en forbindelse mod det indre endepunkt. Den indre udbyder modtager telefonens trafik fra den ydre udgang og videresender den. Den endelige destination ser normalt den indre tjenestes udgang, og ingen udbyder langs kæden er blind; applikationskonti identificerer stadig brugeren uanset ruten.

Forvent praktiske omkostninger. Hvert lag tilføjer indkapsling, så den effektive MTU falder, og en værdi, der var fin til én tunnel, fragmenterer eller går i stå nu, indtil den indre tunnels MTU sættes konservativt. To lag betyder også to fejlafhængigheder og to sæt keepalive-beskeder, og en TCP-baseret indre tunnel over et tabsgivende ydre link kan gå i stå på måder, der ligner en død server.

Vigtigst: en kæde smelter ikke to private netværk sammen. Ruter, overlappende præfikser, DNS-opløsning og adgangsregler forbliver separate beslutninger, og en router, der bærer ét VPN, mens en telefon bærer et andet, giver ikke telefonen begge adresserum.

Kontrollér designet, før du fejlretter det

Skriv opstillingen ned i én sætning, og test den mod den app, der fejlede. Sekventiel adgang bør vise én tunnel ad gangen; profiladskillelse bør vise hver app i sin egen bruger; en kæde bør vise den indre tunnel etablere sig over en ydre grænseflade i stedet for den fysiske.

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

Hvis ruteopslaget angiver den fysiske grænseflade, mens en app forventer tunnelen, er designet og appens kontekst uenige, og ingen ekstra VPN-app vil forlige dem. Dokumentationen om administrerede profiler dækker adskillelsesreglerne, hvis du har brug for politikdetaljen snarere end rutningsdetaljen.