OpenVPN en Windows: arrancar el túnel automáticamente y conservar las rutas

Aquí se enredan dos requisitos: el túnel debe levantarse antes de que nadie inicie sesión, y el tráfico de un segundo sitio debe seguirlo. Son problemas separados con mecanismos separados. El arranque del servicio decide el primero, y la vida de la ruta decide el segundo. Resolver uno deja el otro exactamente donde estaba.

Primer paso: ponga el perfil donde lo busca el servicio

El servicio de Windows lee los perfiles de un directorio fijo, y la GUI lee del mismo lugar, así que un perfil que funciona al importarlo puede seguir siendo invisible en el arranque. Coloque los archivos .ovpn en el directorio config de la instalación, que normalmente está bajo Program Files. Un perfil dejado en la carpeta Downloads de un usuario no entra en absoluto en el ámbito del servicio.

Las indicaciones antiguas apuntan a una carpeta config-auto, que algunas compilaciones de la era 2.5 respetaban y las versiones posteriores no. Por eso una actualización puede convertir un arranque automático que funciona en silencio, sin nada en el registro sobre credenciales. Confirme qué directorio lee realmente la compilación instalada antes de mover ningún archivo.

Con varios perfiles en una máquina, dé a cada uno un adaptador con nombre mediante dev-node. Si no, compiten por la misma interfaz y el segundo falla de una forma que parece un problema de credenciales.

Segundo paso: inicie el servicio, no el icono de la bandeja

Poner el servicio OpenVPN en Automatic hace que se inicie al arrancar sin ningún inicio de sesión. Ese es el mecanismo, y el icono de la bandeja no forma parte de él. Cuando el servicio es dueño de la conexión, la GUI puede no mostrar icono ni estado, lo cual es lo esperado y no una avería.

La consecuencia es que desconectar significa detener el servicio, no hacer clic en Disconnect. Dígaselo a quien dé soporte a la máquina, o la primera llamada de soporte será por un icono que falta.

Compruebe que la cuenta del servicio puede leer el perfil y el material de clave. Un problema de permisos en el arranque parece en el registro exactamente una falla de autenticación.

Tercer paso: ate la ruta al túnel

Una entrada persistente es la herramienta equivocada aquí. Añadir una ruta con -P la hace sobrevivir a los reinicios y, peor aún, la hace sobrevivir al cierre del túnel. Con la VPN caída, el prefijo sigue apuntando a una puerta de enlace que ya no está, así que el host no puede alcanzar ese destino hasta que alguien borre la entrada.

Tres alternativas se comportan correctamente. Empuje la ruta desde el servidor, que la añade al conectar y la quita al desconectar. Añádala en un script route-up que lea route_vpn_gateway, para que el siguiente salto venga del túnel negociado. O use Add-VpnConnectionRoute con un perfil VPN nativo de Windows, que ata el prefijo a esa conexión.

Cuando el servidor ofrece más de lo que este sitio necesita, route-nopull rechaza las rutas empujadas y deja la tabla completamente local. Eso encaja con un perfil compartido cuyos usuarios no deben recibir una ruta predeterminada corporativa.

Cuarto paso: sobreviva a un arranque en frío

Iniciar el servicio antes de que exista la pila de red produce un intento fallido y ningún reintento. Ponerlo en Automatic (Delayed Start), o añadir una dependencia del servicio de red, elimina esa carrera. Luego repita la prueba de arranque y compruebe que ya no hace falta un segundo intento.

Los cambios de ruta y de adaptador necesitan derechos de administrador. Un acceso directo de inicio por usuario no los tiene, así que un script que funciona desde una consola elevada puede no hacer nada en silencio al iniciar sesión. Programe lo como tarea con los privilegios más altos, o deje que el servicio asuma el cambio. Luego pruébelo como el usuario que realmente iniciará sesión.

Pruebe la secuencia que realmente despliega, no la que puede desencadenar a mano. Un arranque en frío es la única prueba que ejercita el orden.

Quinto paso: verifique sin la GUI

Tras un reinicio y un inicio de sesión, compruebe tres cosas sin abrir la GUI. El adaptador debe tener una dirección,la tabla de rutas debe mostrar el prefijo del sitio con la puerta de enlace del túnel como siguiente salto, y un ping a una dirección del lado remoto debe responder. Cada comprobación corresponde a un mecanismo distinto de los pasos anteriores.

Cuando el adaptador nunca aparece, el sospechoso es el controlador y no el perfil. Esas dos fallas no se parecen en nada en el registro, y solo una de ellas responde a reinstalar el software.