Du VPN-oj en unu telefono: elektu la aranĝon, ne la nombron de aplikaĵoj

Uzi du VPN-ojn ne estas unu peto. Ĝi povas signifi atingi du organizaĵojn unu post la alia, teni laborajn kaj personajn aplikaĵojn aparte, aŭ ruli unu tunelon ene de alia. Android traktas tiujn tri kazojn tute malsame, kaj la nombro de instalitaj VPN-aplikaĵoj en la telefono ne estas la arkitekturo. La demando, kiu apartigas ilin, estas simpla: ĉu du vojoj devas ekzisti en la sama momento por la sama aplikaĵo?

Tri aranĝoj, unu demando

Se la respondo estas ne, ĉar la du retoj estas uzataj en malsamaj tempoj, vi volas intencan ŝaltadon. Se la respondo estas ne ĉar la aplikaĵoj mem estas apartaj, vi volas profilan apartigon, kie ĉiu aplikaĵo sidas en la kunteksto, kiu posedas sian tunelon. Se la respondo estas jes, kaj unu vojo devas fizike porti la alian, vi volas ĉenon, kaj tio estas la sola el la tri, kie la ordo estas parto de la dezajno.

Ĉio alia sekvas el tiu elekto. Ŝaltado havas transiran fenestron, apartigo havas politikan limon, kaj ĉeno havas superkostan kaj dependeckostan. Elekti la malĝustan ne malsukcesas pure; ĝi produktas telefonon, kiu aspektas konektita, kaj aplikaĵon, kiu povas atingi nenion.

Ŝaltado ene de unu uzanta kunteksto

Android permesas unu aktivan VPN-servon por uzanto. Lanĉi duan VPN-aplikaĵon en la sama kunteksto anstataŭigas la unuan aŭ estas tute rifuzata; ĝi neniam kunmetas la du itinarajn arojn, kaj certe ne stakigas ilian ĉifradon. Ene de unu uzanto, du tuneloj estas sinsekvo, ne sumo.

Tio estas farebla, kiam la aliro estas vere sinsekva. Nomu la profilojn tiel, ke la aktiva estu evidenta, finu ĉion senteman antaŭ ol ŝalti, kaj atendu mallongan fenestron, en kiu neniu el la du vojoj estas plene starigita. Fermi retuman langeton ne samas kiel fini seancon: la langeto povas konservi sian kontostaton kaj simple sendi la sekvan peton tra la ĵus elektita reto, kaj ĝuste tio estas la liko, kiun homoj rimarkas poste.

Kion ŝaltado ne povas doni al vi, estas maŝino, kiu estas en ambaŭ retoj samtempe. Se aplikaĵo bezonas privatan adreson de ĉiu flanko, neniu klienta disciplino produktos ĝin.

Apartigo laŭ profilo

Administrata labora profilo estas aparta uzanto kun siaj propraj aplikaĵoj, sia ŝlosilejo kaj sia reta politiko. Labora retpoŝta kliento povas uzi la tunelon de la organizaĵo, dum persona retumilo uzas personan, kaj ambaŭ povas esti konektitaj samtempe, ĉar ili ne estas en la sama kunteksto konkurencante pri la loko.

Apartigo ankaŭ estas la limo. La persona retumilo ne pruntas la laboran tunelon, ne vidas la laborajn DNS-sufiksojn kaj ne atingas la laboran reton nur ĉar ambaŭ servoj montriĝas konektitaj. Kiam iu raportas, ke ligilo ne malfermiĝas, kontrolu, kiu kopio de la aplikaĵo traktis ĝin kaj kiu profilo posedas tiun konton, antaŭ ol tuŝi iun el la du VPN-oj.

Traktu la limon kiel fiksan. Krei duan profilon aŭ forigi laboran profilon por ĉirkaŭiri la itineran decidon de dunganto detruas ĝuste tiun apartigon, kiu igis la aranĝon funkcii, kaj sur administrata aparato ĝi kutime estas politika malobservo, ne agorda ŝanĝo.

Ĉeno, kie la ordo estas la dezajno

Ĉeno estas la aranĝo, kiun homoj kutime celas, kiam ili diras ambaŭ samtempe: la tunelo de la telefono vojaĝas ene de la tunelo de la enkursigilo. Ĝi povas funkcii, kaj la limigoj estas konkretaj. La ekstera provizanto devas permesi funkciantan vojon al la VPN-finpunkto de la telefono, kio por UDP-bazitaj protokoloj signifas, ke la ekstera servo ne rajtas bloki aŭ limigi tiun trafikon.

Komprenu, kiu vidas kion. La ekstera provizanto vidas konekton al la interna finpunkto. La interna provizanto ricevas la trafikon de la telefono el la ekstera eliro kaj plusendas ĝin. La fina celo kutime vidas la eliron de la interna servo, kaj neniu provizanto laŭ la ĉeno estas blinda; aplikaĵaj kontoj ankoraŭ identigas la uzanton sendepende de la vojo.

Atendu praktikajn kostojn. Ĉiu tavolo aldonas enkapsuligon, do la efektiva MTU falas kaj valoro, kiu taŭgis por unu tunelo, nun fragmentiĝas aŭ haltas, ĝis la MTU de la interna tunelo estas agordita konserveme. Du tavoloj ankaŭ signifas du malsukcesajn dependecojn kaj du arojn de vivtenaj mesaĝoj, kaj TCP-bazita interna tunelo super perda ekstera ligilo povas halti tiel, ke ĝi aspektas kiel mortinta servilo.

Plej grave, ĉeno ne kunfandas du privatajn retojn. Itineroj, interkovrantaj prefiksoj, DNS-solvado kaj aliraj reguloj restas apartaj decidoj, kaj enkursigilo portanta unu VPN dum telefono portas alian ne donas al la telefono ambaŭ adresspacojn.

Kontrolu la dezajnon antaŭ ol sencimigi ĝin

Skribu la aranĝon en unu frazo kaj testu ĝin kontraŭ la aplikaĵo, kiu malsukcesis. Sinsekva aliro devus montri unu tunelon samtempe; profila apartigo devus montri ĉiun aplikaĵon en sia propra uzanto; ĉeno devus montri la internan tunelon starigante super ekstera interfaco, ne super la fizika.

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

Se la itinera serĉo nomas la fizikan interfacon, dum aplikaĵo atendas la tunelon, la dezajno kaj la aplikaĵa kunteksto malkongruas, kaj neniu plia VPN-aplikaĵo repacigos ilin. La dokumentaro pri administritaj profiloj kovras la apartigajn regulojn, se vi bezonas la politikan detalon, ne la itineran.