Una aplicación Linux corriente usa la VPN sin tocar TUN

Un navegador que usa una VPN Linux ya establecida no abre /dev/net/tun. Abre un socket, y el núcleo decide por qué interfaz salen los paquetes de ese socket. El proceso que creó el túnel hace un trabajo distinto del proceso cuyo tráfico transporta. Mantener esos dos roles separados responde la mayoría de las preguntas sobre permisos antes de que se formulen.

Sigue un paquete desde el socket hasta el túnel

Una aplicación corriente llama a connect o send, y el núcleo busca una ruta para el destino. Si la ruta elegida apunta a la interfaz del túnel, el paquete se encola en el dispositivo que lee el daemon de la VPN. El daemon lo cifra y lo envía por la interfaz física. Cada flecha de esa descripción es un lugar donde se puede responder una pregunta sobre permisos.

Nada en esa ruta exige que la aplicación conozca el dispositivo. El daemon conserva el descriptor de archivo y realiza las operaciones de interfaz, mientras la aplicación solo ve una API de red normal.

Dibuja las dos mitades una vez y las preguntas sobre permisos serán más fáciles de ubicar. La mitad superior es el mundo de las aplicaciones y la inferior pertenece al daemon.

Decide quién necesita el dispositivo y quién no

Crear o conectarse a una interfaz TUN requiere acceso al dispositivo y además la capacidad de configurarla, por lo que un servicio VPN compatible empieza con autoridad de administración de red o usa un ayudante privilegiado. Ese requisito pertenece al daemon. No dice nada sobre el navegador, el cliente de base de datos o la herramienta de transferencia de archivos. Un servicio que necesita la capacidad la necesita para su propio paso de configuración, no para sus clientes.

Una vez que la ruta y la política están en su sitio, un proceso corriente usa la ruta resultante mediante sus llamadas de socket habituales. No necesita el nodo del dispositivo ni necesita root.

Cambiar los permisos del dispositivo no es una forma de conceder a una aplicación acceso al destino. Solo traslada la frontera del dispositivo a otro lugar.

Comprueba el espacio de nombres en el que se ejecuta realmente la aplicación

Un contenedor, o un segundo espacio de nombres de red, da a sus procesos un conjunto de interfaces y una tabla de rutas separados. Un túnel en el host no aparece allí automáticamente, y ningún cambio de permisos del dispositivo lo consigue. La aplicación simplemente enrutará a través de lo que proporcione ese espacio de nombres. Por eso una imagen de contenedor no puede heredar por accidente un túnel del host.

Compruébalo con ip netns list y ip -n NAME route, o inspeccionando el enlace de espacio de nombres del proceso. La respuesta suele verse con un solo comando.

También se puede dar a dos usuarios del mismo host rutas distintas mediante políticas. Es una decisión de red y no una prueba sobre la propiedad del dispositivo.

Separa las capacidades de la política de red

Algunas herramientas necesitan más que un socket. Capturar paquetes necesita un socket sin procesar, y cambiar rutas necesita autoridad de administración. Son operaciones distintas con concesiones distintas, y conceder una no debe interpretarse como requisito general para usar la VPN.

Un programa que implementa su propio túnel es un tercer caso. Abre TUN de verdad porque asume el papel del daemon, y por eso necesita sus privilegios.

Nombra la operación antes de nombrar el privilegio. Lo normal es que los dos sean más fáciles de separar de lo que parecen.

Verifica la separación con dos cuentas

Conecta el túnel como el servicio y luego ejecuta la aplicación como un usuario corriente y confirma que llega al recurso privado. Comprueba ip route get del destino desde el shell de ese usuario para ver qué interfaz se eligió. Si la ruta es correcta y la conexión sigue fallando, el problema es la política y no el privilegio.

El diseño resultante es el mínimo privilegio con una frontera explícita: un componente posee la configuración y los recursos del túnel, las cargas de trabajo conservan sus cuentas normales y la política de red decide qué puede pasar. Ejecutar todo como root colapsa esos roles sin explicar nada.