RRAS arrinca antes de que o túnel OpenVPN estea listo ao iniciar

O servidor reiníciase, OpenVPN arrinca e RRAS iníciase mentres o adaptador ou a ruta da que depende aínda non existe. Reiniciar RRAS á man un minuto despois soluciónao, o que fai que o problema pareza resolto e oculta o real. Aquí confúndense dúas condicións distintas: o servizo prerrequisito está en execución e o recurso de rede que RRAS realmente necesita volveuse utilizábel. Unha dependencia de servizo de Windows pode expresar a primeira condición e nunca a segunda, así que engadir unha sen definir o recurso dálle un arranque máis ordenado e o mesmo fallo.

Como se ve o síntoma nun arranque en frío

A pista é a diferenza entre un arranque en frío e un reinicio. Nun arranque en frío RRAS informa de que está en execución mentres o adaptador do túnel está ausente, falta a ruta ou o enderezo do par aínda non se resolve. Un reinicio manual entón ten éxito porque nese momento o recurso existe, e o servizo simplemente volve ler un mundo que non podía ver un minuto antes. O rexistro do servizo mostrará un inicio limpo en ambos os casos, e por iso o visor de eventos por si só raramente explica isto.

Capture ambos os estados antes de cambiar nada: que informa RRAS ao arrincar e que existe no momento en que o reinicio manual ten éxito. Se esas dúas observacións son idénticas, a orde de arranque non é a súa explicación e unha dependencia non axudará. A comparación custa dez minutos e aforra unha semana de conxecturas.

Unha dependencia engadida sobre a base de «funciona despois dun reinicio» só atrasa o mesmo fallo durante o tempo que tarda o servizo prerrequisito en informar RUNNING. Tamén fai que o arranque sexa máis difícil de razoar, porque a restrición de orde agora parece unha explicación. Pregunte que obxecto garante a dependencia e se ese obxecto é o que RRAS non podía ver.

Nomea o recurso, non só o servizo

Anota a cousa concreta que falta. Pode ser un adaptador de túnel cun enderezo, unha ruta a unha subrede par, unha resposta DNS ou un certificado que aínda se está aprovisionando. «O servizo VPN está en execución» non é unha descrición de recurso, e unha icona verde nun cliente tampouco. Ata que poida nomear o obxecto e un comando que o mostre, non definiu a condición que intenta agardar.

Estableza tamén como se lanza esta instancia de OpenVPN. Un túnel xestionado por GUI e un túnel xestionado por servizo teñen ciclos de vida de arranque distintos, e o nome do servizo debe vir da máquina que ten diante, non dun exemplo escrito para outro instalador. Enumere os candidatos en lugar de confiar nun nome recordado.

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

Lea a cadea de dependencias antes de engadir algo

O Administrador de control de servizos informa estados como START_PENDING e RUNNING, e a SERVICE_STATUS reference define exactamente que significa cada campo. Ningún deses estados promete que un par, un nome DNS ou unha aplicación posterior sexan accesíbeis. Esa fenda é a razón completa pola que este fallo sobrevive a unha dependencia configurada correctamente.

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

A liña DEPENDENCIES de sc.exe qc é a lista que debe conservar, porque sc.exe config RemoteAccess depend= substitúe toda a lista en lugar de engadir a ela. Deixar caer un prerrequisito non relacionado mentres engade un servizo VPN crea un segundo fallo que aparece noutro arranque, e é moito máis difícil de diagnosticar que o orixinal. Copie a lista existente no seu rexistro de cambios antes de tocarla.

As dependencias tamén cambian o comportamento de apagado, porque deter un prerrequisito detén os servizos que dependen del. Comprobe que ocorre durante o mantemento antes de conectar RRAS a algo que se reinicia a miúdo.

Condicione o reinicio a unha condición, non a un temporizador

Unha espera fixa supón que o túnel sempre estará listo dentro desa xanela, e esa é exactamente a suposición que falla no arranque no que un certificado é lento ou unha ligazón está caída. Comprobe o recurso mesmo, cun prazo, e deixe que a comprobación decida se fai 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'

Unha tarefa programada ao inicio que execute esas comprobacións e reinicie RRAS só cando o adaptador ou a ruta sigan ausentes está acoutada, é auditable e fácil de eliminar. A alternativa, reiniciar RRAS en cada reconexión, interrompe sesións sanas e converte unha ligazón inestábel nun bucle de reinicios. Ese bucle é peor que o fallo orixinal, porque agora afecta usuarios que estaban ben.

Dea á comprobación unha espera máxima que coincida co tempo que o túnel tarda razoablemente no seu hardware, e faga que a tarefa remate cun estado distinto de cero cando se renda. Unha tarefa silenciosa que simplemente deixa de intentarlo non se distingue dunha que tivo éxito.

Rexistre a transición para que o seguinte arranque se explique só

Rexistre tres marcas de tempo na mesma liña: cando o servizo de dependencia alcanzou RUNNING, cando apareceu o recurso requirido e cando RRAS finalmente o aceptou. Esa única liña responde a pregunta que fará o seguinte enxeñeiro, e producila case non custa nada. Sen ela, a seguinte investigación comeza coas mesmas conxecturas que esta.

Detéña a automatización tras un número definido de intentos e informe dun fallo en lugar de reintentar para sempre. Un arranque que remata cunha mensaxe clara «o recurso nunca apareceu» vale máis que un que segue reiniciando un servizo ás escuras. Cando esa mensaxe apareza, o nome do recurso que anotou na segunda sección é o que buscará a seguinte persoa.