RRAS s’inicia abans que el túnel OpenVPN estigui llest en arrencar

El servidor es reinicia, OpenVPN s’inicia i RRAS arrenca mentre l’adaptador o la ruta de què depèn encara no hi és. Reiniciar RRAS a mà un minut després ho arregla, cosa que fa que el problema sembli resolt i amaga el real. Aquí es confonen dues condicions diferents: el servei previ s’està executant i el recurs de xarxa que RRAS necessita realment ha esdevingut utilitzable. Una dependència de servei de Windows pot expressar la primera condició i mai la segona, així que afegir-ne una sense definir el recurs et dona una arrencada més polida i la mateixa fallada.

Com es veu el símptoma en una arrencada en fred

La pista és la diferència entre una arrencada en fred i un reinici. En una arrencada en fred, RRAS informa que s’executa mentre l’adaptador del túnel és absent, la ruta falta o l’adreça del parell encara no es resol. Un reinici manual després té èxit perquè en aquell moment el recurs existeix i el servei simplement rellegeix un món que no podia veure un minut abans. El registre del servei mostrarà una arrencada neta en tots dos casos, i per això el visor d’esdeveniments sol no ho explica.

Captura tots dos estats abans de canviar res: què informa RRAS en arrencar i què existeix en el moment en què el reinici manual té èxit. Si aquestes dues observacions són idèntiques, l’ordre d’arrencada no és la teva explicació i una dependència no ajudarà. La comparació costa deu minuts i estalvia una setmana d’especulació.

Una dependència afegida basant-se en «funciona després d’un reinici» només endarrereix la mateixa fallada tant com trigui el servei previ a informar RUNNING. També fa que l’arrencada sigui més difícil de raonar, perquè la restricció d’ordre ara sembla una explicació. Pregunta quin objecte garanteix la dependència i si aquest objecte és el que RRAS no podia veure.

Anomena el recurs, no només el servei

Anota la cosa concreta que falta. Pot ser un adaptador de túnel amb una adreça, una ruta cap a una subxarxa parell, una resposta DNS o un certificat que encara s’està provisionant. «El servei VPN s’executa» no és una descripció de recurs, i tampoc ho és una icona verda en un client. Fins que no puguis nomenar l’objecte i una ordre que el mostri, no has definit la condició que intentes esperar.

Estableix també com es llança aquesta instància d’OpenVPN. Un túnel gestionat per GUI i un túnel gestionat per servei tenen cicles de vida d’arrencada diferents, i el nom del servei ha de venir de la màquina que tens davant, no d’un exemple escrit per a un altre instal·lador. Enumera els candidats en lloc de confiar en un nom recordat.

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

Llegeix la cadena de dependències abans d’afegir-hi res

El Gestor de control de serveis informa estats com START_PENDING i RUNNING, i la SERVICE_STATUS reference defineix exactament què significa cada camp. Cap d’aquests estats promet que un parell, un nom DNS o una aplicació posterior siguin accessibles. Aquest buit és tota la raó per la qual aquesta fallada sobreviu a una dependència ben configurada.

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

La línia DEPENDENCIES de sc.exe qc és la llista que has de conservar, perquè sc.exe config RemoteAccess depend= substitueix tota la llista en lloc d’afegir-hi. Deixar caure un requisit previ no relacionat mentre afegeixes un servei VPN crea una segona fallada que apareix en una altra arrencada, i és molt més difícil de diagnosticar que l’original. Copia la llista existent al teu registre de canvis abans de tocar-la.

Les dependències també canvien el comportament d’aturada, perquè aturar un requisit previ atura els serveis que en depenen. Comprova què passa durant el manteniment abans de connectar RRAS a una cosa que es reinicia sovint.

Condiciona el reinici a una condició, no a un temporitzador

Una espera fixa assumeix que el túnel sempre estarà llest dins d’aquesta finestra, i aquesta és exactament l’assumpció que falla en l’arrencada en què un certificat és lent o un enllaç està caigut. Comprova el recurs mateix, amb un termini, i deixa que la comprovació decideixi si cal un reinici.

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 tasca programada en arrencar que executi aquestes comprovacions i reiniciï RRAS només quan l’adaptador o la ruta encara falten és limitada, auditable i fàcil de treure. L’alternativa, reiniciar RRAS a cada reconnexió, interromp sessions sanes i converteix un enllaç inestable en un bucle de reinicis. Aquest bucle és pitjor que la fallada original, perquè ara afecta usuaris que estaven bé.

Dona a la comprovació una espera màxima que coincideixi amb el temps que el túnel triga raonablement al teu maquinari, i fes que la tasca surti amb un estat diferent de zero quan es rendeixi. Una tasca silenciosa que simplement deixa de provar no es pot distingir d’una que ha tingut èxit.

Registra la transició perquè la propera arrencada s’expliqui sola

Registra tres marques de temps a la mateixa línia: quan el servei de dependència va arribar a RUNNING, quan va aparèixer el recurs requerit i quan RRAS finalment el va acceptar. Aquesta única línia respon la pregunta que farà el proper enginyer, i produir-la gairebé no costa res. Sense això, la propera investigació comença amb la mateixa especulació que aquesta.

Atura l’automatització després d’un nombre definit d’intents i informa d’una fallada en lloc de reintentar per sempre. Una arrencada que acaba amb un missatge clar «el recurs no va aparèixer mai» val més que una que segueix reiniciant un servei a les fosques. Quan aquest missatge aparegui, el nom del recurs que vas anotar a la segona secció és el que buscarà la propera persona.