Por qué aparece el aviso de purga de rutas de vpnc en un contenedor
La purga de la caché de rutas es un resto de un núcleo que ya no mantiene esa caché; el error de solo lectura viene del montaje del contenedor, no del túnel.
Los registros nuevos de contenedores suelen terminar con una queja Read-only file system sobre /proc/sys/net/ipv4/route/flush, y esa línea carga con la culpa de un túnel que puede estar perfectamente sano. La escritura que hay detrás apunta a una entrada del núcleo que ya no hace nada útil ahora que la caché de rutas IPv4 ha desaparecido. Dentro de un contenedor /proc/sys se monta en solo lectura, así que la redirección se rechaza antes de que llegue ningún valor y el shell imprime ese rechazo. Un túnel que funciona puede imprimir este aviso mientras la línea antigua siga en el script, y --privileged nunca hace que la escritura tenga sentido.
Qué intentaba purgar el script
Los scripts de conexión antiguos terminaban con una limpieza de caché: escribir un valor en un archivo de control del núcleo y pedir a la pila IPv4 que descartara su caché de enrutamiento, para que se eligiera una ruta de túnel nueva sin esperar a que caducaran las entradas obsoletas. El archivo se direccionaba bajo /proc/sys/net/ipv4/, lo que convertía la operación en una redirección del shell y no en un comando de enrutamiento. El núcleo 3.6 eliminó esa caché, y con ella la razón de ser de la purga. Nada en la ruta de datos actual depende de esa escritura.
La entrada sobrevivió como archivo heredado de solo escritura, así que un script que aún escribe en ella llega a una ruta real y a una comprobación de permisos real. En un host la escritura devuelve éxito y no cambia nada. En un contenedor la misma redirección choca con un /proc/sys de solo lectura y falla con EROFS, que el shell imprime como el mensaje de sistema de archivos de solo lectura. En núcleos donde la ruta realmente falta, la redacción pasa a No such file or directory, y la conclusión no cambia.
Los dos errores dicen cosas distintas, y la diferencia merece mantenerse clara. Read-only file system significa que el núcleo llegó a una entrada y rechazó la escritura; No such file or directory significa que la entrada ha desaparecido. Ninguno de los mensajes informa sobre el dispositivo del túnel, las rutas ni la resolución de nombres, así que ninguno puede justificar más privilegios.
Es el orden lo que hace que el mensaje parezca causal. Un script de conexión instala rutas, cambia el estado de la interfaz y reescribe la resolución de nombres antes de llegar a la limpieza del final, así que la última línea impresa es la que la gente cita incluso cuando cada paso importante devolvió éxito. Un túnel que se establece y transporta tráfico mientras imprime este aviso encaja exactamente con el mecanismo anterior.
Compruebe el montaje y la ruta antes de añadir privilegios
Tres lecturas separan un aviso cosmético de un fallo real: si el script instalado aún lleva la línea, cómo se monta /proc/sys y adónde va realmente el tráfico de la aplicación. Ejecútelas en el mismo espacio de nombres del contenedor o en el host donde apareció el aviso, porque una comprobación en una máquina ajena responde a otra pregunta.
grep -n 'ipv4/route/flush' /usr/share/vpnc-scripts/vpnc-script
findmnt -no OPTIONS /proc/sys
ip -4 route get 10.20.5.10La respuesta de grep es más débil de lo que parece, porque un acierto demuestra que la línea está presente, no que se ejecute sin protección; un script mantenido puede llevar la escritura dentro de una guarda que la salta. findmnt -no OPTIONS /proc/sys resuelve el montaje directamente, y ro en esa salida significa que toda escritura por debajo de ese punto se rechaza haga lo que haga el script. Después, la consulta de ruta muestra si el destino que necesita la aplicación se resuelve por la interfaz del túnel o por la puerta de enlace predeterminada del contenedor. Una consulta que elige la puerta de enlace predeterminada significa que el túnel subió y nada enruta hacia él, lo que es un problema de enrutamiento y no de privilegios.
De dónde sale realmente la corrección
La corrección mantenida vive en el script y no en los indicadores del contenedor. El vpnc-script de origen ha cambiado cómo gestiona esta operación, así que compare la copia dentro de la imagen con el origen actual y actualice mediante el paquete o la compilación de imagen que lo proporciona. Un archivo editado a mano dentro de un contenedor en marcha no es revisable y no sobrevivirá a la siguiente compilación.
--privileged está documentado como concesión de todas las capacidades más acceso amplio a dispositivos, una concesión grande para un mensaje que no cambia nada, así que nombre la capacidad que falta si realmente falta alguna. Después de la actualización, repita la consulta de ruta y deje que una aplicación use el túnel, porque un registro silencioso y una conexión que funciona son resultados separados.