¿Quién posee la dirección, la ruta, el DNS y el cortafuegos en una VPN Linux?

Dos scripts que se pelean por la misma ruta es la forma habitual de un problema de VPN Linux que se archiva como un error de enrutamiento. Un componente crea el dispositivo de túnel, otro añade una ruta predeterminada, un tercero reescribe la configuración del resolutor y un cuarto recarga las reglas del cortafuegos. Cualquiera de ellos puede deshacer el trabajo de otro, y el ganador es simplemente quien se ejecutó al final. La pregunta que merece respuesta no es qué paquete instalar, sino qué componente tiene autoridad sobre cada pieza de estado.

Escriba ese mapa una vez, y la mayoría de los fallos de reconexión dejan de ser misteriosos. Cuatro objetos importan: el dispositivo y sus direcciones, las rutas y las reglas de política, la configuración de DNS y el cortafuegos.

El dispositivo y sus direcciones

Un dispositivo de túnel lo crea o bien un gestor que conoce el perfil, o bien un demonio que alguien inició a mano. Ambos arreglos funcionan por sí solos; mezclarlos no. Si NetworkManager posee el perfil, deje que también posea el dispositivo, y no inicie un OpenVPN sin gestionar contra el mismo nombre de túnel.

Anote quién elimina el dispositivo cuando termina la sesión. Un dispositivo que sobrevive a su sesión es la fuente más común de direcciones obsoletas y de la confusión que las sigue.

Rutas y reglas de política

Es en las rutas donde los conflictos de propiedad hacen daño visible. Un gestor de conexiones instala una ruta predeterminada para el túnel más una ruta más específica para la red remota; luego un script escrito a mano añade su propia ruta predeterminada con una métrica distinta y gana o pierde en silencio según el momento. Decida qué entradas dependen de la conexión, cuáles son política permanente y qué componente las refresca tras una reconexión. Después mantenga a los otros componentes fuera de esa tabla.

Las reglas de política merecen la misma claridad, porque una regla que apunta a una tabla que nadie llena produce un agujero negro que se parece exactamente a un túnel muerto. Si existe una regla para forzar el tráfico a algún sitio, la tabla que selecciona debe ser mantenida por el mismo propietario.

El DNS siempre es un propietario aparte

Un demonio resolutor se ejecuta como su propio proceso bajo su propia identidad, así que no hereda por accidente las decisiones de enrutamiento del túnel. Cuando la VPN empuja servidores DNS, algo debe traducirlo a una configuración por enlace que el resolutor respete, y algo debe retirarla después.

El mito aquí es que escribir un servidor de nombres en el perfil cambia adónde van las consultas. Cambia lo que se le dice al resolutor, no qué socket usa el resolutor aguas arriba. Pruebe con una consulta más una búsqueda de ruta en lugar de confiar en el archivo.

El estado del cortafuegos, y quién lo restaura

Las reglas del cortafuegos son el objeto que más se sobrescribe en un host de VPN. Un gestor puede añadir reglas NAT o de reenvío por conexión, mientras un servicio de cortafuegos al arranque recarga un conjunto de reglas guardado y las borra. Elija una sola autoridad para la política y haga que la otra sea consumidora de ella, o acepte que un reinicio cambia el comportamiento en silencio. Las excepciones ligadas a la conexión pertenecen a un archivo que carga el mismo propietario, no a un comando iptables escrito durante la resolución de problemas.

Si las reglas deben sobrevivir a una reconexión, dígalo explícitamente. Si no deben, dígalo también, porque el siguiente ingeniero asumirá la respuesta más cómoda.

Ciclo de vida: arranque, reconexión, desmontaje

Dé un propietario a cada uno de esos tres momentos. En el arranque, decida qué prepara los requisitos previos y en qué orden. En un reinicio suave, recuerde que el dispositivo puede sobrevivir mientras que el estado de la sesión no, así que debe ejecutarse un validador en lugar de un creador. En el desmontaje, retire solo lo que creó esta conexión, porque restablecer todas las rutas o vaciar todo el cortafuegos no es lo mismo que retirar un solo túnel.

Para la observación, ip monitor link address route muestra los cambios del núcleo a medida que ocurren, pero informa de eventos en lugar de intención: una ruta eliminada no dice nada sobre qué proceso la eliminó. Combínelo con el mapa de propiedad, y un apagado confuso se convierte en una breve lista de candidatos.

Las exclusiones también tienen un costo. Marcar toda una clase de dispositivos como no gestionada para escapar de un conflicto entrega ese estado a nadie, lo que es una decisión y no una corrección.