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

Serveren starter på nytt, OpenVPN starter, og RRAS kommer opp mens adapteren eller ruten den avhenger av fortsatt mangler. Å starte RRAS manuelt et minutt senere fikser det, noe som får problemet til å se løst ut og skjuler det virkelige. Her forveksles to forskjellige betingelser: forutsetningstjenesten kjører, og nettverksressursen RRAS faktisk trenger er blitt brukbar. En Windows-tjenesteavhengighet kan uttrykke den første betingelsen og aldri den andre, så å legge til en uten å definere ressursen gir en penere oppstart og samme feil.

Hvordan symptomet ser ut ved kaldstart

Tegnet er forskjellen mellom kaldstart og omstart. Ved kaldstart rapporterer RRAS at det kjører mens tunneladapteren mangler, ruten er borte, eller peer-adressen ennå ikke løses opp. En manuell omstart lykkes da fordi ressursen finnes på det tidspunktet, og tjenesten leser bare en verden på nytt som den ikke kunne se et minutt tidligere. Tjenesteloggen viser en ren start i begge tilfeller, og derfor forklarer hendelsesviseren alene sjelden dette.

Registrer begge tilstandene før du endrer noe: hva RRAS rapporterer ved oppstart, og hva som finnes i øyeblikket den manuelle omstarten lykkes. Hvis de to observasjonene er identiske, er oppstartsrekkefølgen ikke forklaringen din, og en avhengighet vil ikke hjelpe. Sammenligningen koster ti minutter og sparer en uke med gjetting.

En avhengighet som legges til på grunnlag av «det virker etter en omstart», utsetter bare samme feil med tiden forutsetningstjenesten bruker på å rapportere RUNNING. Den gjør også oppstarten vanskeligere å resonnere om, fordi rekkefølgebegrensningen nå ser ut som en forklaring. Spør hvilket objekt avhengigheten garanterer, og om det objektet er det RRAS ikke kunne se.

Navngi ressursen, ikke bare tjenesten

Skriv ned den konkrete tingen som mangler. Det kan være en tunneladapter med adresse, en rute til et peer-subnett, et DNS-svar eller et sertifikat som fortsatt klargjøres. «VPN-tjenesten kjører» er ikke en ressursbeskrivelse, og et grønt ikon i en klient er det heller ikke. Inntil du kan navngi objektet og en kommando som viser det, har du ikke definert betingelsen du prøver å vente på.

Fastslå også hvordan denne OpenVPN-forekomsten startes. En GUI-styrt tunnel og en tjenestestyrt tunnel har ulike oppstartslivssykluser, og tjenestenavnet må komme fra maskinen foran deg, ikke fra et eksempel skrevet for en annen installatør. List opp kandidatene i stedet for å stole på et husket navn.

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

Les avhengighetskjeden før du legger til noe

Tjenestekontrolladministratoren rapporterer tilstander som START_PENDING og RUNNING, og SERVICE_STATUS reference definerer nøyaktig hva hvert felt betyr. Ingen av disse tilstandene lover at en peer, et DNS-navn eller en nedstrøms applikasjon er tilgjengelig. Det gapet er hele grunnen til at denne feilen overlever en riktig konfigurert avhengighet.

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 listen du må bevare, fordi sc.exe config RemoteAccess depend= erstatter hele listen i stedet for å legge til i den. Å droppe en urelatert forutsetning mens du legger til en VPN-tjeneste skaper en andre feil som vises ved en annen oppstart, og den er mye vanskeligere å diagnostisere enn den opprinnelige. Kopier den eksisterende listen til endringsloggen din før du rører den.

Avhengigheter endrer også avstengningsatferden, fordi å stoppe en forutsetning stopper tjenestene som avhenger av den. Sjekk hva som skjer under vedlikehold før du kobler RRAS til noe som starter ofte på nytt.

Gjør omstarten betinget av en betingelse, ikke en timer

En fast pause antar at tunnelen alltid er klar innenfor det vinduet, og det er nettopp den antakelsen som svikter ved oppstarten der et sertifikat er tregt eller en lenke er nede. Sjekk selve ressursen, med en frist, og la sjekken avgjøre om en omstart i det hele tatt 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 oppgave ved oppstart som kjører disse sjekkene og bare starter RRAS på nytt når adapteren eller ruten fortsatt mangler, er avgrenset, reviderbar og lett å fjerne. Alternativet, å starte RRAS på nytt ved hver gjenoppkobling, avbryter sunne sesjoner og gjør en ustabil lenke til en omstartsløkke. Den løkken er verre enn den opprinnelige feilen, fordi den nå rammer brukere som hadde det fint.

Gi sjekken en maksimal ventetid som passer med hvor lang tid tunnelen rimeligvis tar på maskinvaren din, og la oppgaven avslutte med en status som ikke er null når den gir opp. En stille oppgave som bare slutter å prøve, kan ikke skilles fra en som lyktes.

Logg overgangen slik at neste oppstart forklarer seg selv

Registrer tre tidsstempler på samme linje: når avhengighetstjenesten nådde RUNNING, når den nødvendige ressursen dukket opp, og når RRAS endelig godtok den. Den ene linjen svarer på spørsmålet neste ingeniør vil stille, og det koster nesten ingenting å lage den. Uten den starter neste undersøkelse fra samme gjetting som denne.

Stopp automatiseringen etter et definert antall forsøk og rapporter feil i stedet for å prøve evig. En oppstart som ender med en klar melding «ressursen dukket aldri opp», er verdt mer enn en som fortsetter å starte en tjeneste i mørket. Når den meldingen dukker opp, er ressursnavnet du skrev ned i andre del, det neste person vil lete etter.