Espacios de nombres de red de Linux para una VPN: qué no aíslan
Un espacio de nombres mueve interfaces, rutas y sockets, no archivos ni cuentas. Aquí ves qué cubre una VPN en su propio netns y por dónde sigue escapándose el tráfico.
Inicie la VPN dentro de su propio espacio de nombres, ejecute allí una aplicación y el tráfico sigue saliendo por la ruta del host. Nada está roto: el espacio de nombres solo gobierna los procesos que entran en él, y la fuga vino de uno que nunca lo hizo. Interfaces, direcciones, rutas, reglas de cortafuegos y sockets son lo que posee el espacio de nombres. Los archivos, las cuentas y los servicios ya en marcha no lo son, y de ahí vienen la mayoría de las sorpresas.
Qué posee el espacio de nombres y dónde nace el socket
Mueva una interfaz a un espacio de nombres y el host la pierde; construya un túnel dentro y el host no puede verlo. Ese es el mecanismo de una VPN limitada a un espacio de nombres: el dispositivo y las rutas que apuntan a él viven en un contexto al que solo llegan los procesos elegidos. El host conserva su ruta predeterminada, así que todo lo de fuera queda intacto.
En WireGuard, el contexto de creación importa tanto como la ubicación actual: el socket UDP se liga al espacio de nombres donde se creó la interfaz, incluso después de que el dispositivo se mueva a otro sitio. De qué tabla de enrutamiento dependen los paquetes cifrados depende de ese lugar de nacimiento. Cuando el socket se queda en un contexto sin ruta hacia el par, la interfaz consulta y el saludo nunca sale. Compruebe su lugar de nacimiento y luego su ubicación actual.
Qué no aísla un espacio de nombres
Nada de esto separa sistemas de archivos, cuentas ni secretos, y ninguna de esas fronteras aparece porque haya creado un espacio de nombres. La configuración del resolutor es un archivo, así que un proceso de dentro todavía puede leer un ajuste que apunta al resolutor del host y enviar su consulta por la ruta que eso implique. Una aplicación que entrega la petición a un intermediario o servicio del sistema ya en marcha involucra un proceso en un contexto completamente distinto. Ambas son peticiones que la frontera nunca debió responder.
La solución es un archivo por espacio de nombres en /etc/netns/<name>/resolv.conf, o un bind mount de un archivo preparado, apuntado a un resolutor accesible desde dentro. Editar /etc/resolv.conf en el host no cambia nada de lo que ve el espacio de nombres.
La colocación de los procesos es el control
El aislamiento que obtiene es exactamente el aislamiento de los procesos que inicia dentro. Un shell iniciado mediante el ayudante exec del espacio de nombres, y todo lo que genera, se queda dentro; una aplicación de escritorio lanzada desde la sesión del host, no. Cree el contexto, mueva el dispositivo y luego demuestre ambos lados:
ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show
Lea el primer wg show desde dentro del espacio de nombres y el segundo desde el host, y espere que solo uno de ellos liste al par. Si ambos lo hacen, el dispositivo nunca se movió; si ninguno, se fue a otro sitio. Cuando el lanzador es un gestor de servicios, el archivo de unidad es lo que hay que editar, no el acceso directo del escritorio. Una unidad sin el ajuste de espacio de nombres inicia el demonio en el contexto del host y deshace el diseño en silencio.
Pruebe desde el contexto de la aplicación
Ejecute la comprobación con el mismo binario y el mismo usuario que usa la aplicación, dentro del espacio de nombres. Incluya DNS y ambas familias de direcciones, porque una ruta IPv6 que nunca consideró es una salida habitual. Una prueba desde su propio shell solo demuestra que su shell está aislado.
Después ejecute la comprobación idéntica en el host y confirme que las respuestas difieren: dirección del túnel y salida prevista dentro, ruta del host y salida de la oficina fuera, y el resolutor por nombre. Nome los espacios de nombres por el despliegue y no por el protocolo, para que un script de limpieza no confunda dos de ellos.
Reenvío, política de fallo y limpieza
Para una puerta de enlace, active el reenvío a propósito y decida qué debe ocurrir cuando caiga el túnel. Un espacio de nombres no bloquea las rutas que instale dentro, así que se usará una ruta de reserva hacia el host si crea una. Es una decisión de política y debería escribirse antes de que una caída la ponga a prueba.
Anote los nombres de los espacios de nombres, las interfaces y quién posee la configuración, para que la limpieza elimine solo lo que creó el despliegue. Restablecer la red del host durante una reversión convierte una limpieza en una caída. La página network_namespaces(7) es corta y merece leerse antes de diseñar ese camino.