VPN amb chroot a Android: per què el túnel funciona i les aplicacions l’ignoren
El chroot canvia la resolució de rutes, no el nucli, l’espai de noms de xarxa ni el registre de VPN d’Android. Se’n deriven dos resultats i tots dos sorprenen la gent.
Instal·leu una distribució Linux dins d’un chroot al telèfon, hi poseu un client VPN i l’intèrpret anuncia que el túnel s’ha completat. Després passeu al navegador i el trànsit surt per dades mòbils com si no hagués passat res. O el contrari: totes les aplicacions perden la connexió perquè el client ha afegit una ruta per defecte a l’espai de noms que Android fa servir de debò. Aquests dos símptomes vénen de la mateixa peça que falta i cap dels dos és un error del client VPN.
L’intèrpret diu connectat, les aplicacions no hi estan d’acord
El primer resultat és l’habitual. Un túnel d’espai d’usuari obert des d’un chroot pot completar l’apretada de mans, imprimir les seves estadístiques i transportar el trànsit que genera el mateix intèrpret, mentre les aplicacions d’Android segueixen usant la xarxa per defecte del telèfon. Res les intercepta, perquè res no ha dit a Android que existeixi una VPN.
El segon resultat és el perillós. Si el chroot comparteix l’espai de noms de xarxa d’Android, que és el que passa per defecte, un procés amb prou privilegis pot afegir rutes i una interfície TUN que afecten tot el telèfon. Llavors el túnel funciona per a totes les aplicacions, incloses les que no volíeu encaminar, i la connectivitat del telèfon depèn ara d’un dimoni sense gestió del cicle de vida, sense indicador de connexió i sense política d’activació permanent.
Quin dels dos resultats heu obtingut es pot respondre amb una ordre. Compareu ip route dins del chroot amb la mateixa ordre des d’un intèrpret d’Android a fora. Una sortida idèntica vol dir que el chroot és a l’espai de noms de l’amfitrió: qualsevol canvi de xarxa que faci afecta tot el telèfon. Una sortida diferent vol dir que el llançador li ha creat un espai de noms i que el seu túnel és invisible per a Android per construcció.
Què va canviar el chroot i què no
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
La crida de sistema chroot fa una sola cosa: canvia el directori emprat per resoldre rutes. La pàgina de manual diu explícitament que no és una frontera de seguretat i no diu res sobre interfícies, rutes ni estat de VPN. Tot el que la gent espera d’un contenidor Linux — una pila de xarxa privada, un sistema de fitxers filtrat, límits de recursos — ve d’altres mecanismes que el llançador pot haver fet servir o no.
Per això les afirmacions que un chroot aïlla una VPN solen respondre la pregunta equivocada. La pregunta rellevant és en quin espai de noms s’executa el procés i en quin domini SELinux està confinat, i tots dos són propietats de com s’ha iniciat, no de la paraula chroot.
TUN necessita tres coses i el node de dispositiu només és una
Un túnel tradicional d’espai d’usuari necessita un dispositiu TUN que pugui obrir, suport del nucli per a aquest dispositiu i permís per configurar la interfície i les rutes. Són requisits separats i crear un nom de ruta sota /dev no satisfà cap d’ells per si sol:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunA Android el nucli sol portar el suport TUN compilat, perquè el servei de VPN de la plataforma el fa servir, però això no vol dir que el vostre procés el pugui usar. Configurar la interfície requereix la capacitat d’administració de xarxa i SELinux decideix si el procés pot arribar al node del dispositiu. Una denegació sembla un error de permisos sense causa òbvia i la resposta és al registre d’auditoria:
dmesg | grep avc
logcat -d | grep "avc: denied"Root no ho resol. SELinux restringeix els processos amb uid 0 igual que els altres, així que un chroot iniciat des d’un intèrpret root pot rebre una denegació per a un dispositiu que veu. Desactivar l’aplicació forçosa per fer funcionar un instal·lador antic és una decisió per a tot el telèfon amb conseqüències molt més enllà del túnel i no és cap solució per a un binari obsolet.
Per què les aplicacions d’Android ignoren el vostre túnel
El model suportat d’Android és una aplicació VPN que es registra pel servei de VPN de la plataforma, demana consentiment a l’usuari una vegada i rep un descriptor de fitxer per al seu túnel. La plataforma encamina llavors el trànsit a aquest descriptor i aplica l’abast d’aplicacions que l’usuari o l’administrador ha triat, per això el mateix mecanisme pot ser per aplicació, per perfil i combinat amb ajustos d’activació permanent i bloqueig sense VPN. La guia de desenvolupament de VPN d’Android descriu aquesta apretada de mans i el punt clau és que és un registre, no un truc d’encaminament.
Un dimoni dins d’un chroot no es registra mai. No hi ha diàleg de consentiment, ni icona de clau a la barra d’estat, ni llista d’inclusió o exclusió per aplicació, ni participació en la política d’activació permanent. Per tant les aplicacions continuen usant la xarxa per defecte i el túnel només porta el que envia el mateix intèrpret.
L’altra direcció tampoc ajuda. Empenyer rutes a l’espai de noms de l’amfitrió ho captura tot, inclòs el trànsit que la plataforma esperava mantenir local, i ho fa sense control per aplicació i sense manera que l’usuari ho vegi o ho revoqui. No hi ha cap ajust intermedi on un dimoni dins d’un chroot encamini el trànsit d’una sola aplicació.
La compatibilitat binària és un mur a part
Fins i tot quan el costat de xarxa és interessant, l’executable té els seus requisits: arquitectura de CPU, carregador dinàmic, biblioteca C i les capacitats del nucli que espera. Android fa servir bionic i no glibc, i un binari antic compilat per a una distribució d’escriptori pot necessitar biblioteques que ja no existeixen al dispositiu.
Enllaçar el nom d’un fitxer de biblioteca a una versió més nova no crea compatibilitat ABI, i una biblioteca criptogràfica arxivada d’un paquet de fa deu anys no és un component mantingut. Si el pla depèn d’això, el pla és executar codi sense manteniment amb privilegis de xarxa en un telèfon.
Demostreu-ho en el context d’Android i netegeu després
Proveu el que realment us importa, des del costat que importa: obriu l’aplicació concreta, arribeu a la destinació privada concreta, confirmeu quin resolutor ha respost, després desconnecteu el túnel i confirmeu el comportament documentat. Un resultat d’un terminal dins del chroot és evidència sobre el context d’execució d’aquell terminal i res més.
Si heu canviat rutes de l’amfitrió durant l’experiment, revertiu-les i anoteu què heu canviat. Després comproveu si el telèfon té una VPN d’activació permanent configurada, perquè un experiment antic que va deixar una regla pot semblar una fallada de la plataforma mesos després.
Per a una necessitat real d’accés remot, feu servir el client suportat del servei o un disseny de passarel·la aprovat. La pregunta que val la pena no és si es pot fer funcionar un instal·lador amb root, sinó si una implementació suportada porta les aplicacions que necessiteu a través de la frontera que volíeu, sense deixar canvis privilegiats sense amo al dispositiu.