Por qué el modo privilegiado es más amplio de lo que una VPN necesita

El contenedor no abría su túnel, así que se añadió la marca privilegiada y ahora funciona. Esa secuencia solo demostró que faltaba al menos un permiso, y no dice nada sobre cuál. El modo privilegiado concede un conjunto de capacidades y acceso a dispositivos mucho más amplio de lo que necesita una interfaz de túnel.

Qué cambia realmente la marca

Un contenedor privilegiado recibe capacidades amplias y acceso a los dispositivos del anfitrión, lo que es una concesión mucho mayor de lo que requiere la ruta de red. El conjunto exacto lo documenta el entorno de ejecución y no lo fija la tradición, y la documentación de Docker sobre la ejecución de contenedores describe las opciones de privilegio disponibles. Leerla una vez basta para ver que el túnel es una parte pequeña del total.

Dos requisitos más estrechos cubren la mayoría de los contenedores VPN. Configurar una interfaz necesita la capacidad de administración de red, y abrir el dispositivo de túnel necesita acceso a ese nodo de dispositivo concreto. Son concesiones separadas, y proporcionar ambas sigue siendo más estrecho que la opción global. El resto del conjunto privilegiado no tiene nada que ver con el túnel. Existe para cargas de trabajo que de verdad necesitan acceso a nivel de anfitrión, y un contenedor VPN normalmente no es una de ellas.

Empareje cada error con un requisito previo

El mensaje de error le dice qué requisito previo falta si lo lee antes de suprimirlo. Un mensaje sobre un nodo de dispositivo nombra el dispositivo, un mensaje sobre una operación no permitida nombra una capacidad, y un mensaje sobre un módulo o un sysctl nombra soporte del núcleo. Cada uno tiene una solución distinta, y solo uno de ellos es una capacidad.

Un archivo de configuración ausente sigue ausente después de conceder todas las capacidades, por eso el modo privilegiado a veces no cambia absolutamente nada. El contenedor arranca, el túnel sigue fallando, y el error real nunca tuvo que ver con permisos. El soporte del núcleo es el tercer caso y el más fácil de leer mal. Un módulo que no está cargado en el anfitrión no se puede cargar desde dentro de un contenedor sin privilegios, y conceder más capacidades dentro del contenedor no cambia el estado del anfitrión.

Compruebe el requisito, no el síntoma

Empiece por la invocación mínima que documenta la imagen, ejecútela y guarde el texto exacto del fallo. Después añada una concesión cada vez y anote qué adición cambió el resultado.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

Un contenedor que ve el dispositivo y tiene la capacidad pero aun así falla le está diciendo que el problema está en otro sitio. Ese es un resultado útil, y el modo privilegiado lo habría ocultado.

Compruebe también los permisos del dispositivo en el anfitrión, porque un nodo de dispositivo concedido correctamente con la propiedad de grupo equivocada produce el mismo error que una concesión ausente.

Anote la concesión más estrecha que funcione

Anote cada dispositivo y capacidad que necesita el despliegue, junto con el error que los justificó. Ese registro es lo que permite a la siguiente persona quitar algo con seguridad, y es lo que pedirá un auditor cuando se notifique un contenedor como privilegiado.

Revise también el contexto que lo rodea, porque la red del anfitrión, los montajes del anfitrión y las opciones del entorno de ejecución pueden ampliar cada uno el impacto de una concesión. Una invocación aislada de laboratorio que los combina todos no es una configuración de producción, por bien que haya funcionado. Pruebe la aplicación, su comportamiento en DNS y un fallo de túnel antes de dar el despliegue por terminado. El permiso para crear una interfaz no es una política de salida, y un contenedor que puede tunelizar perfectamente sigue enrutando todo lo que envía la aplicación.