Două VPN-uri pe un singur telefon: alegeți aranjamentul, nu numărul de aplicații

Folosirea a două VPN-uri nu este o singură cerere. Poate însemna să ajungi la două organizații una după alta, să ții separate aplicațiile de serviciu de cele personale sau să rulezi un tunel în interiorul altuia. Android tratează aceste trei cazuri în moduri complet diferite, iar numărul de aplicații VPN instalate pe telefon nu este arhitectura. Întrebarea care le separă este simplă: trebuie să existe două trasee în același moment pentru aceeași aplicație?

Trei aranjamente, o întrebare

Dacă răspunsul este nu, pentru că cele două rețele sunt folosite în momente diferite, doriți o comutare deliberată. Dacă răspunsul este nu pentru că aplicațiile însele sunt separate, doriți separarea profilurilor, în care fiecare aplicație stă în contextul care deține tunelul ei. Dacă răspunsul este da, iar un traseu trebuie să îl poarte fizic pe celălalt, doriți un lanț, și este singurul dintre cele trei în care ordinea face parte din proiect.

Tot restul decurge din această alegere. Comutarea are o fereastră de tranziție, separarea are o limită de politică, iar un lanț are un cost suplimentar și un cost de dependență. Alegerea celei greșite nu eșuează curat; produce un telefon care pare conectat și o aplicație care nu ajunge nicăieri.

Comutare într-un singur context de utilizator

Android permite un singur serviciu VPN activ per utilizator. Pornirea unei a doua aplicații VPN în același context o înlocuiește pe prima sau este refuzată direct; nu compune niciodată cele două seturi de rute și cu siguranță nu le stivuiește criptarea. În interiorul unui utilizator, două tuneluri sunt o succesiune, nu o sumă.

Acest lucru este practicabil când accesul este cu adevărat secvențial. Dați nume profilurilor astfel încât cel activ să fie evident, terminați orice lucru sensibil înainte de a comuta și așteptați-vă la o fereastră scurtă în care niciunul dintre cele două trasee nu este pe deplin stabilit. Închiderea unui tab de browser nu este același lucru cu încheierea unei sesiuni: tabul își poate păstra starea contului și pur și simplu trimite următoarea cerere prin rețeaua tocmai aleasă, și aceasta este exact scurgerea pe care oamenii o observă după aceea.

Ceea ce comutarea nu vă poate da este o mașină care se află în ambele rețele în același timp. Dacă o aplicație are nevoie de o adresă privată din fiecare parte, nicio disciplină a clientului nu o va produce.

Separare după profil

Un profil de serviciu gestionat este un utilizator separat cu aplicațiile, depozitul de chei și politica de rețea proprii. Un client de e-mail de serviciu poate folosi tunelul organizației în timp ce un browser personal folosește unul personal, iar ambele pot fi conectate în același timp pentru că nu sunt în același context concurând pentru loc.

Separarea este și limita. Browserul personal nu împrumută tunelul de serviciu, nu vede sufixele DNS de serviciu și nu ajunge în rețeaua de serviciu doar pentru că ambele servicii apar ca fiind conectate. Când cineva raportează că un link nu se deschide, verificați ce copie a aplicației l-a tratat și ce profil deține acel cont înainte de a atinge oricare dintre cele două VPN-uri.

Tratați granița ca fiind fixă. Crearea unui al doilea profil sau eliminarea unui profil de serviciu pentru a ocoli decizia de rutare a unui angajator distruge exact separarea care făcea aranjamentul să funcționeze, iar pe un dispozitiv gestionat aceasta este de obicei o încălcare a politicii, nu o modificare de configurare.

Un lanț, în care ordinea este proiectul

Un lanț este aranjamentul la care oamenii se gândesc de obicei când spun ambele deodată: tunelul telefonului călătorește în interiorul tunelului routerului. Poate funcționa, iar constrângerile sunt concrete. Furnizorul exterior trebuie să permită un traseu funcțional către punctul final VPN al telefonului, ceea ce, pentru protocoalele bazate pe UDP, înseamnă că serviciul exterior nu trebuie să blocheze sau să limiteze acel trafic.

Înțelegeți cine vede ce. Furnizorul exterior vede o conexiune către punctul final interior. Furnizorul interior primește traficul telefonului de la ieșirea exterioară și îl transmite mai departe. Destinația finală vede de obicei ieșirea serviciului interior, și niciun furnizor de-a lungul lanțului nu este orb; conturile aplicațiilor identifică în continuare utilizatorul indiferent de traseu.

Așteptați-vă la costuri practice. Fiecare strat adaugă încapsulare, deci MTU-ul efectiv scade și o valoare care era bună pentru un tunel acum se fragmentează sau se blochează până când MTU-ul tunelului interior este setat conservator. Două straturi înseamnă și două dependențe de defecțiune și două seturi de mesaje de menținere, iar un tunel interior bazat pe TCP peste o legătură exterioară cu pierderi se poate bloca în moduri care arată ca un server mort.

Cel mai important, un lanț nu fuzionează două rețele private. Rutele, prefixele suprapuse, rezolvarea DNS și regulile de acces rămân decizii separate, iar un router care poartă un VPN în timp ce un telefon poartă altul nu îi oferă telefonului ambele spații de adrese.

Verificați proiectul înainte de a-l depana

Scrieți aranjamentul într-o propoziție și testați-l pe aplicația care a eșuat. Accesul secvențial ar trebui să arate un singur tunel o dată; separarea profilurilor ar trebui să arate fiecare aplicație în propriul utilizator; un lanț ar trebui să arate tunelul interior stabilindu-se peste o interfață exterioară, nu peste cea fizică.

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

Dacă interogarea rutei numește interfața fizică în timp ce o aplicație așteaptă tunelul, proiectul și contextul aplicației nu sunt de acord, și nicio aplicație VPN suplimentară nu le va împăca. Documentația despre profilurile gestionate acoperă regulile de separare dacă aveți nevoie de detaliul de politică, nu de cel de rutare.