RRAS starter før OpenVPN-tunnelen er klar ved opstart

Serveren genstarter, OpenVPN starter, og RRAS kommer op, mens den adapter eller rute, den afhænger af, stadig mangler. At genstarte RRAS manuelt et minut senere løser det, hvilket får problemet til at se løst ud og skjuler det rigtige. Der forveksles to forskellige betingelser: den forudsatte tjeneste kører, og den netværksressource, RRAS faktisk har brug for, er blevet brugbar. En Windows-tjenestafhængighed kan udtrykke den første betingelse og aldrig den anden, så en afhængighed uden en defineret ressource giver en pænere opstart og samme fejl.

Sådan ser symptomet ud ved en kold opstart

Tegnet er forskellen mellem en kold start og en genstart. Ved en kold start rapporterer RRAS, at den kører, mens tunneladapteren mangler, ruten er væk, eller peer-adressen endnu ikke kan slås op. En manuel genstart lykkes så, fordi ressourcen findes på det tidspunkt, og tjenesten læser blot en verden igen, som den ikke kunne se et minut tidligere. Tjenesteloggen viser en ren start i begge tilfælde, og derfor forklarer hændelsesviseren sjældent dette alene.

Registrér begge tilstande, før du ændrer noget: hvad RRAS rapporterer ved opstart, og hvad der findes i det øjeblik, den manuelle genstart lykkes. Hvis de to observationer er identiske, er opstartsrækkefølgen ikke din forklaring, og en afhængighed hjælper ikke. Sammenligningen koster ti minutter og sparer en uges gætteri.

En afhængighed, der tilføjes på grundlag af »det virker efter en genstart«, udskyder kun den samme fejl med den tid, den forudsatte tjeneste bruger på at rapportere RUNNING. Den gør også opstarten sværere at gennemskue, fordi rækkefølgebegrænsningen nu ligner en forklaring. Spørg, hvilket objekt afhængigheden garanterer, og om det objekt er det, RRAS ikke kunne se.

Navngiv ressourcen, ikke bare tjenesten

Skriv den konkrete ting ned, som mangler. Det kan være en tunneladapter med en adresse, en rute til et peer-subnet, et DNS-svar eller et certifikat, der stadig udstedes. »VPN-tjenesten kører« er ikke en ressourcebeskrivelse, og et grønt ikon i en klient er det heller ikke. Indtil du kan navngive objektet og en kommando, der viser det, har du ikke defineret den betingelse, du forsøger at vente på.

Fastlæg også, hvordan denne OpenVPN-instans startes. En GUI-styret tunnel og en tjenestestyret tunnel har forskellige opstartslivscyklusser, og tjenestenavnet skal komme fra maskinen foran dig, ikke fra et eksempel skrevet til en anden installer. Angiv kandidaterne i stedet for at stole på et husket navn.

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

Læs afhængighedskæden, før du tilføjer til den

Service Control Manager rapporterer tilstande som START_PENDING og RUNNING, og SERVICE_STATUS reference definerer præcis, hvad hvert felt betyder. Ingen af disse tilstande lover, at en peer, et DNS-navn eller et nedstrømsprogram kan nås. Det hul er hele grunden til, at denne fejl overlever en korrekt konfigureret afhængighed.

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

Linjen DEPENDENCIES fra sc.exe qc er den liste, du skal bevare, fordi sc.exe config RemoteAccess depend= erstatter hele listen i stedet for at tilføje til den. At fjerne en urelateret forudsætning, mens du tilføjer en VPN-tjeneste, skaber en anden fejl, der viser sig ved en anden opstart, og den er langt sværere at diagnosticere end den oprindelige. Kopiér den eksisterende liste til din ændringsjournal, før du rører ved den.

Afhængigheder ændrer også nedlukningsadfærden, fordi stop af en forudsætning stopper de tjenester, der afhænger af den. Undersøg, hvad der sker under vedligeholdelse, før du kobler RRAS til noget, der genstarter ofte.

Gør genstarten betinget af en betingelse, ikke en timer

En fast pause antager, at tunnelen altid er klar inden for det vindue, og det er netop den antagelse, der svigter ved den opstart, hvor et certifikat er langsomt, eller et link er nede. Kontrollér selve ressourcen med en frist, og lad kontrollen afgøre, om en genstart overhovedet er nødvendig.

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'

En planlagt opgave ved opstart, der kører disse kontroller og kun genstarter RRAS, når adapteren eller ruten stadig mangler, er afgrænset, reviderbar og let at fjerne. Alternativet, at genstarte RRAS ved hver genopkobling, afbryder sunde sessioner og gør et ustabilt link til en genstartsloop. Den loop er værre end den oprindelige fejl, fordi den nu rammer brugere, der havde det fint.

Giv kontrollen en maksimal ventetid, der svarer til, hvor lang tid tunnelen rimeligt tager på dit hardware, og lad opgaven afslutte med en status, der ikke er nul, når den giver op. En tavs opgave, der bare holder op med at prøve, kan ikke skelnes fra en, der lykkedes.

Log overgangen, så den næste opstart forklarer sig selv

Registrér tre tidsstempler på samme linje: hvornår afhængighedstjenesten nåede RUNNING, hvornår den krævede ressource dukkede op, og hvornår RRAS endelig accepterede den. Den ene linje besvarer det spørgsmål, den næste ingeniør vil stille, og det koster næsten intet at producere den. Uden den starter den næste undersøgelse fra samme gætteri som denne.

Stop automatiseringen efter et defineret antal forsøg, og rapportér fejl i stedet for at prøve for evigt. En opstart, der ender med en klar besked »ressourcen dukkede aldrig op«, er mere værd end en, der bliver ved med at genstarte en tjeneste i mørke. Når den besked dukker op, er det ressourcenavn, du skrev ned i andet afsnit, det, den næste person vil søge efter.