VPN con chroot en Android: por que o túnel funciona e as aplicacións ignórano

Instalas unha distribución Linux dentro dun chroot no teléfono, colocas un cliente VPN e a shell anuncia un túnel completado. Despois abres o navegador e o tráfico sae por datos móbiles coma se nada pasase. Ou ao revés: todas as aplicacións perden a conexión porque o cliente engadiu unha ruta por defecto no espazo de nomes que Android usa de verdade. Ambos síntomas veñen da mesma peza ausente e ningún é un fallo do cliente VPN.

A shell di conectado, as aplicacións non están de acordo

O primeiro resultado é o habitual. Un túnel de espazo de usuario aberto desde un chroot pode completar o seu handshake, imprimir as súas estatísticas e levar o tráfico que xera a mesma shell, mentres as aplicacións de Android seguen usando a rede por defecto do teléfono. Nada as intercepta, porque nada lle dixo a Android que existe unha VPN.

O segundo resultado é o perigoso. Se o chroot comparte o espazo de nomes de rede de Android, que é o que pasa por defecto, un proceso con privilexios abondos pode engadir rutas e unha interface TUN que afectan a todo o teléfono. Entón o túnel funciona para todas as aplicacións, incluídas as que non querías encamiñar, e a conectividade depende agora dun demonio sen xestión do ciclo de vida, sen indicador de conexión e sen política de sempre activo.

Cal dos dous obtiveches respóndese cunha orde. Compara ip route dentro do chroot coa mesma orde desde unha shell de Android fóra. Unha saída idéntica significa que o chroot está no espazo de nomes do host: calquera cambio de rede que faga é para todo o teléfono. Unha saída distinta significa que o lanzador creou un espazo de nomes para el e o seu túnel é invisible para Android por construción.

Que cambiou o chroot e que non

A chamada ao sistema chroot fai unha cousa: cambia o directorio usado para resolver rutas. A páxina de manual di claramente que non é unha fronteira de seguridade e non di nada de interfaces, rutas nin estado de VPN. Todo o que a xente espera dun contedor Linux — unha pila de rede privada, un sistema de ficheiros filtrado, límites de recursos — vén doutros mecanismos que o lanzador pode ou non ter usado.

Por iso as afirmacións de que un chroot illa unha VPN adoitan responder á pregunta equivocada. A pregunta relevante é en que espazo de nomes corre o proceso e en que dominio SELinux está confinado, e ambas son propiedades de como se iniciou, non da palabra chroot.

TUN necesita tres cousas e o nodo de dispositivo é só unha

Un túnel tradicional de espazo de usuario necesita un dispositivo TUN que poida abrir, soporte do núcleo para ese dispositivo e permiso para configurar a interface e as rutas. Son requisitos separados e crear un nome de ruta baixo /dev non satisface ningún por si só:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

En Android o núcleo adoita levar o soporte TUN compilado, porque o usa o propio servizo VPN da plataforma, pero iso non significa que o teu proceso poida usalo. Configurar a interface require a capacidade de administración de rede e SELinux decide se o proceso pode chegar sequera ao nodo do dispositivo. Unha denegación parece un erro de permisos sen causa obvia e a resposta está no rexistro de auditoría:

dmesg | grep avc
logcat -d | grep "avc: denied"

Root non o resolve. SELinux restrinxe os procesos con uid 0 igual que os demais, así que un chroot iniciado desde unha shell root pode seguir recibindo unha denegación por un dispositivo que ve. Desactivar a aplicación forzosa para que funcione un instalador vello é unha decisión para todo o teléfono con consecuencias moito máis alá do túnel e non é a solución para un binario obsoleto.

Por que as aplicacións de Android ignoran o teu túnel

O modelo admitido de Android é unha aplicación VPN que se rexistra no servizo VPN da plataforma, pide consentimento unha vez e recibe un descriptor de ficheiro para o seu túnel. Logo a plataforma encamiña o tráfico a ese descriptor e aplica o ámbito de aplicacións que elixiu o usuario ou o administrador, por iso o mesmo mecanismo pode ser por aplicación, por perfil e combinarse con sempre activo e bloqueo sen VPN. A guía de desenvolvemento de VPN de Android describe ese handshake e a clave é que é un rexistro, non un truco de encamiñamento.

Un demonio dentro dun chroot nunca se rexistra. Non hai diálogo de consentimento, nin icona de chave na barra de estado, nin lista de inclusión ou exclusión por aplicación, nin participación na política de sempre activo. Por iso as aplicacións seguen usando a rede por defecto e o túnel só leva o que envía a propia shell.

A outra dirección tampouco axuda. Empurrar rutas ao espazo de nomes do host captúrao todo, incluído tráfico que a plataforma esperaba manter local, e faino sen control por aplicación e sen forma de que o usuario o vexa ou o revogue. Non hai axuste intermedio onde un demonio en chroot encamiñe o tráfico dunha soa aplicación.

A compatibilidade binaria é un muro aparte

Aínda que o lado de rede sexa interesante, o executable ten os seus requisitos: arquitectura de CPU, cargador dinámico, biblioteca C e as capacidades do núcleo que espera. Android usa bionic e non glibc, e un binario antigo compilado para unha distribución de escritorio pode necesitar bibliotecas que xa non existen no dispositivo.

Enlazar o nome dunha biblioteca a unha versión máis nova non crea compatibilidade ABI, e unha biblioteca criptográfica arquivada dun paquete de hai dez anos non é un compoñente mantido. Se o plan depende diso, o plan é executar código sen mantemento con privilexios de rede nun teléfono.

Demostrao no contexto de Android e limpa despois

Proba o que de verdade che importa, desde o lado que importa: abre a aplicación concreta, chega ao destino privado concreto, confirma que resolvedor respondeu, logo desconecta o túnel e confirma o comportamento documentado. Un resultado dun terminal dentro do chroot é evidencia sobre o contexto de execución dese terminal e nada máis.

Se cambiaches rutas do host durante o experimento, revérteas e anota que cambiaches. Logo comproba se o teléfono ten unha VPN de sempre activo configurada, porque un experimento antigo que deixou unha regra pode parecer un fallo da plataforma meses despois.

Para unha necesidade real de acceso remoto, usa o cliente admitido do servizo ou un deseño de pasarela aprobado. A pregunta que paga a pena non é se se pode facer funcionar un instalador con root, senón se unha implementación admitida leva as aplicacións que necesitas cruzar a fronteira que pretendías, sen deixar cambios privilexiados sen dono no dispositivo.