Dos VPN en un sol telèfon: trieu la disposició, no el nombre d’aplicacions

Fer servir dos VPN no és una sola petició. Pot voler dir arribar a dues organitzacions l’una després de l’altra, mantenir separades les aplicacions de feina i personals, o executar un túnel dins d’un altre. Android tracta aquests tres casos de maneres completament diferents, i el nombre d’aplicacions VPN instal·lades al telèfon no és l’arquitectura. La pregunta que els separa és simple: han d’existir dos camins en el mateix moment per a la mateixa aplicació?

Tres disposicions, una pregunta

Si la resposta és no, perquè les dues xarxes es fan servir en moments diferents, voleu un canvi deliberat. Si la resposta és no perquè les aplicacions mateixes són separades, voleu una separació de perfils, en què cada aplicació se situa en el context que posseeix el seu túnel. Si la resposta és sí i un camí ha de portar físicament l’altre, voleu una cadena, i és l’única de les tres en què l’ordre forma part del disseny.

La resta se segueix d’aquesta tria. El canvi té una finestra de transició, la separació té una frontera de política i una cadena té un cost d’encapsulament i de dependència. Triar la incorrecta no falla netament; produeix un telèfon que sembla connectat i una aplicació que no pot arribar enlloc.

Canviar dins d’un sol context d’usuari

Android permet un sol servei VPN actiu per usuari. Engegar una segona aplicació VPN en el mateix context substitueix la primera o es rebutja directament; mai no compon els dos conjunts de rutes i, sens dubte, no apila el xifratge d’ambdues. Dins d’un usuari, dos túnels són una seqüència, no una suma.

Això és viable quan l’accés és realment seqüencial. Poseu nom als perfils perquè l’actiu sigui evident, acabeu qualsevol cosa sensible abans de canviar i espereu una finestra curta en què cap dels dos camins no estigui plenament establert. Tancar una pestanya del navegador no és el mateix que acabar una sessió: la pestanya pot conservar l’estat del seu compte i simplement enviar la petició següent per la xarxa acabada de triar, i això és exactament la fuita que la gent nota després.

El que el canvi no us pot donar és una màquina que sigui a les dues xarxes alhora. Si una aplicació necessita una adreça privada de cada banda, cap disciplina del client no la produirà.

Separar per perfil

Un perfil de feina gestionat és un usuari separat amb les seves aplicacions, el seu magatzem de claus i la seva política de xarxa. Un client de correu de feina pot fer servir el túnel de l’organització mentre un navegador personal en fa servir un de personal, i tots dos poden estar connectats alhora perquè no són al mateix context competint per la plaça.

La separació és també el límit. El navegador personal no manlleva el túnel de feina, no veu els sufixos DNS de feina i no arriba a la xarxa de feina només perquè tots dos serveis es mostren connectats. Quan algú informa que un enllaç no s’obre, comproveu quina còpia de l’aplicació el va gestionar i quin perfil posseeix aquell compte abans de tocar cap dels dos VPN.

Tracteu la frontera com a fixa. Crear un segon perfil o eliminar un perfil de feina per esquivar la decisió d’encaminament d’un empleador destrueix precisament la separació que feia funcionar la disposició, i en un dispositiu gestionat normalment és una violació de política i no un retoc de configuració.

Una cadena, on l’ordre és el disseny

Una cadena és la disposició que la gent sol voler dir quan diu tots dos alhora: el túnel del telèfon viatja dins del túnel del router. Pot funcionar, i les restriccions són específiques. El proveïdor exterior ha de permetre un camí funcional fins al punt final VPN del telèfon, cosa que per als protocols basats en UDP vol dir que el servei exterior no ha de bloquejar ni limitar aquest trànsit.

Enteneu qui veu què. El proveïdor exterior veu una connexió cap al punt final interior. El proveïdor interior rep el trànsit del telèfon des de la sortida exterior i l’envia més enllà. La destinació final normalment veu la sortida del servei interior, i cap proveïdor de la cadena no és cec; els comptes de les aplicacions encara identifiquen l’usuari sigui quin sigui el camí.

Espereu costos pràctics. Cada capa afegeix encapsulament, de manera que l’MTU efectiva baixa i un valor que anava bé per a un túnel ara es fragmenta o s’encalla fins que l’MTU del túnel interior es fixa de manera conservadora. Dues capes també volen dir dues dependències de fallada i dos jocs de missatges de manteniment, i un túnel interior basat en TCP sobre un enllaç exterior amb pèrdues es pot encallar de maneres que semblen un servidor mort.

El més important: una cadena no fusiona dues xarxes privades. Les rutes, els prefixos solapats, la resolució DNS i les regles d’accés continuen sent decisions separades, i un router que porta un VPN mentre un telèfon en porta un altre no dona al telèfon els dos espais d’adreces.

Comproveu el disseny abans de depurar-lo

Escriviu la disposició en una frase i proveu-la contra l’aplicació que va fallar. L’accés seqüencial hauria de mostrar un túnel alhora; la separació de perfils hauria de mostrar cada aplicació en el seu usuari; una cadena hauria de mostrar el túnel interior establint-se sobre una interfície exterior i no sobre la física.

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

Si la consulta de ruta anomena la interfície física mentre una aplicació espera el túnel, el disseny i el context de l’aplicació no coincideixen, i cap aplicació VPN addicional els reconciliarà. La documentació sobre perfils gestionats cobreix les regles de separació si necessiteu el detall de política i no el d’encaminament.