Twee VPN’s op een foon: kies die rangskikking, nie die aantal programme nie

Om twee VPN’s te gebruik is nie een versoek nie. Dit kan beteken om twee organisasies ná mekaar te bereik, om werk- en persoonlike programme apart te hou, of om een tonnel binne-in ’n ander te laat loop. Android hanteer daardie drie gevalle op heeltemal verskillende maniere, en die aantal VPN-programme wat op die foon geïnstalleer is, is nie die argitektuur nie. Die vraag wat hulle skei is eenvoudig: moet twee paaie op dieselfde oomblik vir dieselfde program bestaan?

Drie rangskikkings, een vraag

As die antwoord nee is, omdat die twee netwerke op verskillende tye gebruik word, wil jy ’n doelbewuste oorskakeling hê. As die antwoord nee is omdat die programme self apart is, wil jy profielskeiding hê, waar elke program in die konteks sit wat sy eie tonnel besit. As die antwoord ja is, en een pad die ander fisies moet dra, wil jy ’n ketting hê, en dit is die enigste van die drie waar die volgorde deel van die ontwerp is.

Alles anders volg uit daardie keuse. Oorskakeling het ’n oorgangsvenster, skeiding het ’n beleidsgrens, en ’n ketting het ’n oorhoofse koste en afhanklikheidskoste. Om die verkeerde een te kies misluk nie skoon nie; dit lewer ’n foon wat gekoppel lyk en ’n program wat niks kan bereik nie.

Oorskakeling binne een gebruikerkonteks

Android laat een aktiewe VPN-diens per gebruiker toe. Om ’n tweede VPN-program in dieselfde konteks te begin, vervang die eerste of word heeltemal geweier; dit stel nooit die twee stelle roetes saam nie, en dit stapel sekerlik nie hul enkripsie nie. Binne een gebruiker is twee tonnels ’n volgorde, nie ’n som nie.

Dit is werkbaar wanneer toegang werklik opeenvolgend is. Gee die profiele name sodat die aktiewe een duidelik is, maak enigiets sensitiefs klaar voordat jy oorskakel, en verwag ’n kort venster waarin geen van die twee paaie heeltemal gevestig is nie. Om ’n bladsy-oortjie toe te maak is nie dieselfde as om ’n sessie te beëindig nie: die oortjie kan sy rekeningtoestand hou en bloot die volgende versoek oor die nuutgekose netwerk stuur, en dit is presies die lek wat mense daarna opmerk.

Wat oorskakeling nie vir jou kan gee nie, is ’n masjien wat op albei netwerke gelyktydig is. As ’n program ’n private adres van elke kant nodig het, sal geen mate van kliëntdissipline dit lewer nie.

Skeiding volgens profiel

’n Bestuurde werkprofiel is ’n aparte gebruiker met sy eie programme, keystoor en netwerkbeleid. ’n Werk-e-poskliënt kan die organisasie se tonnel gebruik terwyl ’n persoonlike blaaier ’n persoonlike een gebruik, en albei kan op dieselfde tyd gekoppel wees omdat hulle nie in dieselfde konteks is en om die slot meeding nie.

Die skeiding is ook die beperking. Die persoonlike blaaier leen nie die werktonnel nie, sien nie die werk se DNS-agtervoegsels nie en bereik nie die werksnetwerk net omdat albei dienste as gekoppel wys nie. Wanneer iemand rapporteer dat ’n skakel nie oopgaan nie, kyk watter kopie van die program dit hanteer het en watter profiel daardie rekening besit voordat jy enige van die twee VPN’s aanraak.

Behandel die grens as vas. Om ’n tweede profiel te skep of ’n werkprofiel te verwyder om ’n werkgewer se roetebesluit te omseil, vernietig juis die skeiding wat die rangskikking laat werk het, en op ’n bestuurde toestel is dit gewoonlik ’n beleidsoortreding eerder as ’n konfigurasieverstelling.

’n Ketting, waar volgorde die ontwerp is

’n Ketting is die rangskikking wat mense gewoonlik bedoel wanneer hulle sê albei gelyktydig: die foon se tonnel reis binne-in die roeteerder se tonnel. Dit kan werk, en die beperkings is spesifiek. Die buitenste verskaffer moet ’n werkende pad na die foon se VPN-eindpunt toelaat, wat vir UDP-gebaseerde protokolle beteken die buitenste diens mag daardie verkeer nie blokkeer of beperk nie.

Verstaan wie wat sien. Die buitenste verskaffer sien ’n verbinding na die binneste eindpunt. Die binneste verskaffer ontvang die foon se verkeer van die buitenste uitgang en stuur dit verder. Die finale bestemming sien gewoonlik die binneste diens se uitgang, en geen verskaffer langs die ketting is blind nie; programrekeninge identifiseer steeds die gebruiker ongeag die pad.

Verwag praktiese koste. Elke laag voeg inkapseling by, so die effektiewe MTU daal en ’n waarde wat vir een tonnel goed was, fragmenteer of stagneer nou totdat die binneste tonnel se MTU konserwatief gestel word. Twee lae beteken ook twee foutafhanklikhede en twee stelle lewendhouboodskappe, en ’n TCP-gebaseerde binneste tonnel oor ’n verliesryke buitenste skakel kan stagneer op maniere wat soos ’n dooie bediener lyk.

Die belangrikste: ’n ketting smelt nie twee private netwerke saam nie. Roetes, oorvleuelende voorvoegsels, DNS-resolusie en toegangsreëls bly aparte besluite, en ’n roeteerder wat een VPN dra terwyl ’n foon ’n ander dra, gee nie die foon albei adresruimtes nie.

Kontroleer die ontwerp voordat jy dit ontfout

Skryf die rangskikking in een sin neer en toets dit teen die program wat gefaal het. Opeenvolgende toegang behoort een tonnel op ’n slag te wys; profielskeiding behoort elke program in sy eie gebruiker te wys; ’n ketting behoort te wys dat die binneste tonnel oor ’n buitenste koppelvlak vestig eerder as oor die fisiese een.

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

As die roetesoektog die fisiese koppelvlak noem terwyl ’n program die tonnel verwag, stem die ontwerp en die programkonteks nie ooreen nie, en geen bykomende VPN-program sal hulle versoen nie. Die dokumentasie oor bestuurde profiele dek die skeidingsreëls as jy die beleidsbesonderhede eerder as die roetebesonderhede nodig het.