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

Tenaren startar på nytt, OpenVPN startar, og RRAS kjem opp medan adapteren eller ruta han er avhengig av framleis manglar. Å starta RRAS manuelt eit minutt seinare rettar det, noko som får problemet til å sjå løyst ut og skjuler det verkelege. Her blir to ulike vilkår blanda saman: føresetnadstenesta køyrer, og nettverksressursen RRAS faktisk treng er blitt brukbar. Ei Windows-tenesteavhengnad kan uttrykkje det første vilkåret og aldri det andre, så å leggje til ei utan å definere ressursen gir ei penare oppstart og same feilen.

Korleis symptomet ser ut ved kaldstart

Teiknet er skilnaden mellom kaldstart og omstart. Ved kaldstart rapporterer RRAS at det køyrer medan tunneladapteren manglar, ruta er borte, eller peer-adressa enno ikkje blir løyst opp. Ein manuell omstart lukkast då fordi ressursen finst på det tidspunktet, og tenesta les berre ei verd på nytt som ho ikkje kunne sjå eit minutt tidlegare. Tenesteloggen viser ein rein start i begge tilfelle, og difor forklarer hendingsvisaren åleine dette sjeldan.

Registrer begge tilstandane før du endrar noko: kva RRAS rapporterer ved oppstart, og kva som finst i augneblinken den manuelle omstarten lukkast. Viss dei to observasjonane er identiske, er startrekkjefølgja ikkje forklaringa di, og ei avhengnad vil ikkje hjelpe. Samanlikninga kostar ti minutt og sparar ei veke med gissing.

Ei avhengnad som blir lagd til på grunnlag av «det verkar etter ein omstart», utset berre same feilen med tida føresetnadstenesta brukar på å rapportere RUNNING. Ho gjer òg oppstarten vanskelegare å resonnere om, fordi rekkjefølgjebegrensinga no ser ut som ei forklaring. Spør kva objekt avhengnaden garanterer, og om det objektet er det RRAS ikkje kunne sjå.

Namngje ressursen, ikkje berre tenesta

Skriv ned den konkrete tingen som manglar. Det kan vere ein tunneladapter med adresse, ei rute til eit peer-subnett, eit DNS-svar eller eit sertifikat som framleis blir klargjort. «VPN-tenesta køyrer» er ikkje ei ressursbeskriving, og eit grønt ikon i ein klient er det heller ikkje. Inntil du kan namngje objektet og ein kommando som viser det, har du ikkje definert vilkåret du prøver å vente på.

Fastset òg korleis denne OpenVPN-førekomsten blir starta. Ein GUI-styrt tunnel og ein tenestestyrt tunnel har ulike oppstartslivssyklusar, og tenestenamnet må kome frå maskinen framfor deg, ikkje frå eit døme skrive for ein annan installatør. List opp kandidatane i staden for å stole på eit hugsa namn.

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

Les avhengnadskjeda før du legg til noko

Tenestekontrolladministratoren rapporterer tilstandar som START_PENDING og RUNNING, og SERVICE_STATUS reference definerer nøyaktig kva kvart felt betyr. Ingen av desse tilstandane lovar at ein peer, eit DNS-namn eller ein nedstraums applikasjon er tilgjengeleg. Det gapet er heile grunnen til at denne feilen overlever ei rett konfigurert avhengnad.

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

Lina DEPENDENCIES frå sc.exe qc er lista du må ta vare på, fordi sc.exe config RemoteAccess depend= erstattar heile lista i staden for å leggje til i ho. Å droppe ein urelatert føresetnad medan du legg til ei VPN-teneste skaper ein andre feil som viser seg ved ein annan oppstart, og han er mykje vanskelegare å diagnostisere enn den opphavlege. Kopier den eksisterande lista til endringsloggen din før du rører ho.

Avhengnader endrar òg åtferda ved avstenging, fordi å stoppe ein føresetnad stoppar tenestene som er avhengige av han. Sjekk kva som skjer under vedlikehald før du koplar RRAS til noko som startar ofte på nytt.

Gjer omstarten avhengig av eit vilkår, ikkje av ein timer

Ei fast pause føreset at tunnelen alltid er klar innanfor det vindauget, og det er nettopp den føresetnaden som sviktar ved oppstarten der eit sertifikat er tregt eller ei lenkje er nede. Sjekk sjølve ressursen, med ein frist, og la sjekken avgjere om ein omstart i det heile er naudsynt.

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'

Ei planlagd oppgåve ved oppstart som køyrer desse sjekkane og berre startar RRAS på nytt når adapteren eller ruta framleis manglar, er avgrensa, reviderbar og lett å fjerne. Alternativet, å starta RRAS på nytt ved kvar gjenoppkopling, avbryt sunne sesjonar og gjer ei ustabil lenkje til ei omstartssløyfe. Den sløyfa er verre enn den opphavlege feilen, fordi ho no rammar brukarar som hadde det fint.

Gi sjekken ei maksimal ventetid som passar med kor lang tid tunnelen rimelegvis tek på maskinvara di, og la oppgåva avslutte med ein status som ikkje er null når ho gir opp. Ei stille oppgåve som berre sluttar å prøve, kan ikkje skiljast frå ei som lukkast.

Logg overgangen slik at neste oppstart forklarer seg sjølv

Registrer tre tidsstempel på same line: når avhengnadstenesta nådde RUNNING, når den naudsynte ressursen dukka opp, og når RRAS endeleg godtok han. Den eine line svarar på spørsmålet neste ingeniør vil stille, og det kostar nesten ingenting å lage ho. Utan ho startar neste undersøking frå same gissing som denne.

Stopp automatiseringa etter eit definert tal forsøk og rapporter feil i staden for å prøve evig. Ein oppstart som endar med ei klar melding «ressursen dukka aldri opp», er verdt meir enn ein som held fram med å starte ei teneste i mørkret. Når den meldinga dukkar opp, er ressursnamnet du skreiv ned i andre del, det neste person vil leite etter.