RRAS arranca antes de que el túnel de OpenVPN esté listo al iniciar

El servidor se reinicia, OpenVPN arranca y RRAS se inicia mientras el adaptador o la ruta de la que depende todavía no existe. Reiniciar RRAS a mano un minuto después lo arregla, lo que hace que el problema parezca resuelto y oculta el real. Aquí se confunden dos condiciones distintas: el servicio prerrequisito está en ejecución y el recurso de red que RRAS realmente necesita se ha vuelto utilizable. Una dependencia de servicio de Windows puede expresar la primera condición y nunca la segunda, así que añadir una sin definir el recurso le compra un arranque más ordenado y el mismo fallo.

Cómo se ve el síntoma en un arranque en frío

La señal es la diferencia entre un arranque en frío y un reinicio. En un arranque en frío RRAS informa que se está ejecutando mientras el adaptador del túnel está ausente, falta la ruta o la dirección del par todavía no se resuelve. Un reinicio manual entonces tiene éxito porque para ese momento el recurso existe, y el servicio simplemente relee un mundo que no podía ver un minuto antes. El registro del servicio mostrará un inicio limpio en ambos casos, y por eso el visor de eventos por sí solo rara vez explica esto.

Capture ambos estados antes de cambiar nada: qué informa RRAS al arrancar y qué existe en el momento en que el reinicio manual tiene éxito. Si esas dos observaciones son idénticas, el orden de arranque no es su explicación y una dependencia no ayudará. La comparación cuesta diez minutos y ahorra una semana de conjeturas.

Una dependencia añadida sobre la base de «funciona después de un reinicio» solo retrasa el mismo fallo durante el tiempo que tarda el servicio prerrequisito en informar RUNNING. También hace que el arranque sea más difícil de razonar, porque la restricción de orden ahora parece una explicación. Pregunte qué objeto garantiza la dependencia y si ese objeto es el que RRAS no podía ver.

Nombre el recurso, no solo el servicio

Anote la cosa concreta que falta. Puede ser un adaptador de túnel con una dirección, una ruta a una subred par, una respuesta DNS o un certificado que aún se está aprovisionando. «El servicio VPN está en ejecución» no es una descripción de recurso, y un icono verde en un cliente tampoco. Hasta que pueda nombrar el objeto y un comando que lo muestre, no ha definido la condición que intenta esperar.

Establezca también cómo se lanza esta instancia de OpenVPN. Un túnel gestionado por GUI y un túnel gestionado por servicio tienen ciclos de vida de arranque distintos, y el nombre del servicio debe venir de la máquina que tiene delante, no de un ejemplo escrito para otro instalador. Enumere los candidatos en lugar de confiar en un nombre recordado.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

Lea la cadena de dependencias antes de añadir algo

El Administrador de control de servicios informa estados como START_PENDING y RUNNING, y la SERVICE_STATUS reference define exactamente qué significa cada campo. Ninguno de esos estados promete que un par, un nombre DNS o una aplicación posterior sean accesibles. Esa brecha es la razón completa por la que este fallo sobrevive a una dependencia configurada correctamente.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

La línea DEPENDENCIES de sc.exe qc es la lista que debe conservar, porque sc.exe config RemoteAccess depend= reemplaza toda la lista en lugar de añadir a ella. Dejar caer un prerrequisito no relacionado mientras añade un servicio VPN crea un segundo fallo que aparece en otro arranque, y es mucho más difícil de diagnosticar que el original. Copie la lista existente en su registro de cambios antes de tocarla.

Las dependencias también cambian el comportamiento de apagado, porque detener un prerrequisito detiene los servicios que dependen de él. Compruebe qué ocurre durante el mantenimiento antes de conectar RRAS a algo que se reinicia a menudo.

Condicione el reinicio a una condición, no a un temporizador

Una espera fija supone que el túnel siempre estará listo dentro de esa ventana, y esa es exactamente la suposición que falla en el arranque en el que un certificado es lento o un enlace está caído. Compruebe el recurso mismo, con un plazo, y deje que la comprobación decida si hace falta un reinicio.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

Una tarea programada al inicio que ejecute esas comprobaciones y reinicie RRAS solo cuando el adaptador o la ruta sigan ausentes está acotada, es auditable y fácil de eliminar. La alternativa, reiniciar RRAS en cada reconexión, interrumpe sesiones sanas y convierte un enlace inestable en un bucle de reinicios. Ese bucle es peor que el fallo original, porque ahora afecta a usuarios que estaban bien.

Dé a la comprobación una espera máxima que coincida con el tiempo que el túnel tarda razonablemente en su hardware, y haga que la tarea termine con un estado distinto de cero cuando se rinda. Una tarea silenciosa que simplemente deja de intentarlo no se distingue de una que tuvo éxito.

Registre la transición para que el siguiente arranque se explique solo

Registre tres marcas de tiempo en la misma línea: cuándo el servicio de dependencia alcanzó RUNNING, cuándo apareció el recurso requerido y cuándo RRAS finalmente lo aceptó. Esa única línea responde la pregunta que hará el siguiente ingeniero, y producirla casi no cuesta nada. Sin ella, la siguiente investigación empieza con las mismas conjeturas que esta.

Detenga la automatización tras un número definido de intentos e informe de un fallo en lugar de reintentar para siempre. Un arranque que termina con un mensaje claro «el recurso nunca apareció» vale más que uno que sigue reiniciando un servicio a oscuras. Cuando ese mensaje aparezca, el nombre del recurso que anotó en la segunda sección es lo que buscará la siguiente persona.