¿Quién debería ser dueño de las rutas y el DNS cuando se conecta openfortivpn?

Cuatro etapas se apilan unas sobre otras en una sesión de openfortivpn que funciona. El cliente se autentica en la puerta de enlace e inicia una conexión TLS, luego ejecuta PPP dentro de esa conexión, después recibe una dirección e información DNS y, por último, aplica rutas de host y ajustes del resolutor. Cada etapa puede estar viva mientras la siguiente no lo está, y por eso “conectado” es una palabra tan resbaladiza en los hilos de soporte.

La decisión que elimina la mayor parte de la confusión es quién es dueño de la última etapa. O el cliente VPN aplica él mismo los cambios en el host, o los hace otro componente, y mezclar ambos a medias es como las rutas y los archivos del resolutor acaban describiendo sesiones distintas.

Cuatro etapas que parecen una sola conexión

La primera etapa es la admisión. un dominio de autenticación con nombre o un código de un solo uso, y recibe los parámetros que necesita para continuar. Cuando el cliente imprime que está conectado a la puerta de enlace, eso significa que el transporte TLS está activo. No significa que PPP haya negociado, y desde luego no significa que una aplicación interna sea accesible.

La segunda etapa es el enlace PPP. El cliente inicia un proceso PPP contra el dispositivo de túnel, y ambos lados negocian opciones de enlace y direcciones. Solo después de eso el host sabe qué direcciones locales y remotas usa la sesión, y solo entonces una ruta hacia el túnel puede tener sentido.

La tercera etapa es aplicar esa información al host, y aquí es donde importa la propiedad. El cliente puede añadir las rutas y reescribir la configuración del resolutor, o se le puede indicar que se retire y deje ambas cosas a lo que sea que gestione la red en esa máquina. El README del proyecto las describe como responsabilidades separadas en lugar de un solo comportamiento automático.

Quién edita la tabla de enrutamiento

Por defecto, el cliente es el propietario. Añade una ruta hacia la puerta de enlace por la interfaz física, una ruta para el par del túnel y rutas para las redes que la sesión puede usar, y luego las elimina cuando el proceso termina. Ese valor por defecto es cómodo en un portátil con un solo gestor de red y sin otro software VPN.

Elija la cesión solo cuando algo más sea realmente dueño del enrutamiento. Una integración con el gestor de red, un espacio de nombres de red de contenedor o un agente de enrutamiento de todo el sitio pueden saber ya cómo instalar y limpiar los mismos prefijos. Pasar la opción no-routes entonces evita que dos escritores se peleen por la misma tabla, que es una carrera que se manifiesta como pérdida intermitente de una subred en lugar de un fallo limpio.

El solapamiento es la segunda razón para ceder. Si las rutas empujadas incluyen un prefijo que la red local ya usa, el cliente no puede resolver el conflicto por usted. Alguien tiene que decidir si ese prefijo es alcanzable por el túnel, por el enlace físico o por una ruta más específica, y esa decisión pertenece a quien sea dueño de la topología.

La limpieza es la tercera. Un cliente que falla antes de quitar sus rutas deja un agujero negro que sobrevive a la sesión, y la siguiente conexión puede añadir un duplicado encima. Quien es dueño del enrutamiento también lo es de verificar que las entradas antiguas han desaparecido. Haga de esa comprobación parte del camino de inicio, no un paso de limpieza opcional.

Quién es dueño del DNS y del archivo del resolutor

El DNS es la misma decisión con bordes más afilados. El cliente puede aceptar los servidores DNS que informa la puerta de enlace o el par PPP y escribirlos en la configuración del resolutor del host. En una máquina sencilla eso es exactamente lo que quiere, porque los nombres internos entonces solo se resuelven mientras el túnel está activo.

En un host Linux moderno el resolutor puede estar gestionado por un stub local, y reescribir el archivo del resolutor a espaldas de ese stub produce una configuración que parece correcta y se comporta de forma inconsistente. Si el host ya ejecuta un gestor de resolutor, déjelo ser dueño del DNS y aliméntelo con los servidores del túnel a través de su interfaz compatible. La opción no-dns del cliente es la elección correcta ahí, no un apaño.

El DNS dividido es una cuestión aparte de quién escribe el archivo. Enviar cada consulta por el túnel es simple y lento; enviar solo zonas internas por él requiere configuración por dominio que la mayoría de los clientes simples no ofrecen. Decida qué comportamiento necesita el host antes de habilitar los cambios del resolutor del cliente. Una elección equivocada aquí parece una caída de resolución de nombres incluso cuando el túnel está bien.

Privilegios, disponibilidad y la cesión

Crear el dispositivo de túnel y editar rutas de host o el estado del resolutor requiere autoridad de red elevada. El error común es concluir que, por tanto, todo debe ejecutarse como root, incluido el navegador o la aplicación que usa el túnel. Mantenga pequeña la parte privilegiada: el cliente y su archivo de configuración, propiedad de un administrador, mientras las aplicaciones de usuario conservan su cuenta normal.

La disponibilidad debe definirse por consumidor. Un supervisor puede considerar el servicio iniciado cuando el proceso del cliente se ejecuta y el dispositivo de túnel existe. Un trabajo de copia de seguridad debería considerar la VPN utilizable solo cuando su punto de almacenamiento responde por el túnel. Son comprobaciones distintas, y usar la más débil para el propósito más fuerte produce trabajos que empiezan demasiado pronto y fallan de forma intermitente. Escriba la definición elegida, porque un supervisor y un trabajo que no coinciden sobre la disponibilidad son un ticket de soporte esperando a ocurrir.

Pruebe el contrato con cuatro observaciones: la fase de puerta de enlace se completa, PPP asigna direcciones, la ruta prevista está presente y una petición a un host interno tiene éxito. Luego detenga el cliente y confirme que cada una de esas cosas se ha eliminado o restaurado. Si el host sigue resolviendo nombres internos o sigue manteniendo una ruta después de cerrarse el túnel, la cesión de propiedad está incompleta.