RRAS pornește înainte ca tunelul OpenVPN să fie gata la boot

Serverul repornește, OpenVPN pornește, iar RRAS urcă în timp ce adaptorul sau ruta de care depinde încă lipsește. Repornirea manuală a RRAS un minut mai târziu rezolvă problema, ceea ce face ca problema să pară rezolvată și o ascunde pe cea reală. Aici se confundă două condiții diferite: serviciul precondiție rulează și resursa de rețea de care RRAS are nevoie cu adevărat a devenit utilizabilă. O dependență de serviciu Windows poate exprima prima condiție și niciodată pe a doua, așa că adăugarea uneia fără definirea resursei vă oferă un boot mai ordonat și aceeași defecțiune.

Cum arată simptomul la un boot la rece

Indiciul este diferența dintre un start la rece și o repornire. La un start la rece RRAS raportează că rulează în timp ce adaptorul tunelului lipsește, ruta a dispărut sau adresa partenerului nu se rezolvă încă. O repornire manuală reușește apoi pentru că la acel moment resursa există, iar serviciul pur și simplu recitește o lume pe care nu o putea vedea cu un minut înainte. Jurnalul serviciului va arăta un start curat în ambele cazuri, motiv pentru care vizualizatorul de evenimente singur explică rareori acest lucru.

Înregistrați ambele stări înainte de a schimba ceva: ce raportează RRAS la boot și ce există în momentul în care repornirea manuală reușește. Dacă cele două observații sunt identice, ordinea de pornire nu este explicația dumneavoastră și o dependență nu va ajuta. Comparația costă zece minute și economisește o săptămână de presupuneri.

O dependență adăugată pe baza „funcționează după o repornire“ doar întârzie aceeași defecțiune cu timpul de care are nevoie serviciul precondiție ca să raporteze RUNNING. De asemenea, face bootul mai greu de raționat, pentru că restricția de ordine arată acum ca o explicație. Întrebați ce obiect garantează dependența și dacă acel obiect este cel pe care RRAS nu îl putea vedea.

Numiți resursa, nu doar serviciul

Notați lucrul concret care lipsește. Poate fi un adaptor de tunel cu o adresă, o rută către o subrețea partener, un răspuns DNS sau un certificat încă în curs de provisionare. „Serviciul VPN rulează“ nu este o descriere de resursă, iar o pictogramă verde într-un client nici atât. Până nu puteți numi obiectul și o comandă care îl arată, nu ați definit condiția pe care încercați să o așteptați.

Stabiliți și cum este lansată această instanță OpenVPN. Un tunel gestionat prin GUI și un tunel gestionat de serviciu au cicluri de viață de boot diferite, iar numele serviciului trebuie să vină de la mașina din fața dumneavoastră, nu dintr-un exemplu scris pentru alt instalator. Enumerați candidații în loc să vă bazați pe un nume memorat.

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

Citiți lanțul de dependențe înainte de a adăuga ceva

Managerul de control al serviciilor raportează stări precum START_PENDING și RUNNING, iar SERVICE_STATUS reference definește exact ce înseamnă fiecare câmp. Niciuna dintre aceste stări nu promite că un partener, un nume DNS sau o aplicație din aval este accesibilă. Această lacună este întregul motiv pentru care această defecțiune supraviețuiește unei dependențe configurate corect.

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

Linia DEPENDENCIES din sc.exe qc este lista pe care trebuie să o păstrați, deoarece sc.exe config RemoteAccess depend= înlocuiește întreaga listă în loc să adauge la ea. Eliminarea unei precondiții nelegate în timp ce adăugați un serviciu VPN creează o a doua defecțiune care apare la alt boot și este mult mai greu de diagnosticat decât cea originală. Copiați lista existentă în registrul de modificări înainte de a o atinge.

Dependențele schimbă și comportamentul la oprire, pentru că oprirea unei precondiții oprește serviciile care depind de ea. Verificați ce se întâmplă în timpul mentenanței înainte de a conecta RRAS la ceva care repornește des.

Condiționați repornirea de o condiție, nu de un temporizator

O așteptare fixă presupune că tunelul va fi întotdeauna gata în acea fereastră, iar aceasta este exact presupunerea care eșuează la bootul în care un certificat este lent sau o legătură este căzută. Verificați resursa în sine, cu un termen, și lăsați verificarea să decidă dacă este nevoie de o repornire.

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'

O sarcină programată la boot care rulează aceste verificări și repornește RRAS doar când adaptorul sau ruta încă lipsesc este limitată, auditabilă și ușor de eliminat. Alternativa, repornirea RRAS la fiecare reconectare, întrerupe sesiuni sănătoase și transformă o legătură instabilă într-o buclă de reporniri. Acea buclă este mai rea decât defecțiunea originală, pentru că acum afectează utilizatori care erau bine.

Dați verificării o așteptare maximă care corespunde timpului de care tunelul are nevoie în mod rezonabil pe hardware-ul dumneavoastră, și faceți sarcina să iasă cu un status diferit de zero când renunță. O sarcină silențioasă care pur și simplu renunță să mai încerce nu poate fi distinsă de una care a reușit.

Înregistrați tranziția astfel încât următorul boot să se explice singur

Înregistrați trei momente pe aceeași linie: când serviciul de dependență a atins RUNNING, când a apărut resursa necesară și când RRAS a acceptat-o în cele din urmă. Acea singură linie răspunde la întrebarea pe care o va pune următorul inginer, iar producerea ei nu costă aproape nimic. Fără ea, următoarea investigație începe de la aceleași presupuneri ca aceasta.

Opriți automatizarea după un număr definit de încercări și raportați o defecțiune în loc să reîncercați la nesfârșit. Un boot care se termină cu un mesaj clar „resursa nu a apărut niciodată“ valorează mai mult decât unul care continuă să repornească un serviciu pe întuneric. Când apare acel mesaj, numele resursei pe care l-ați notat în a doua secțiune este ceea ce va căuta următoarea persoană.