RRAS se zažene, preden je tunel OpenVPN ob zagonu pripravljen

Strežnik se znova zažene, OpenVPN se zažene in RRAS se dvigne, medtem ko vmesnik ali pot, od katerih je odvisen, še manjkata. Ročni ponovni zagon RRAS čez minuto to popravi, zato je videti, da je težava rešena, resnična pa se skrije. Tu se mešata dva različna pogoja: predhodna storitev teče in omrežni vir, ki ga RRAS dejansko potrebuje, je postal uporaben. Odvisnost storitve Windows lahko izrazi prvi pogoj in nikoli drugega, zato dodajanje odvisnosti brez opredelitve vira prinese bolj urejen videz zagona in isto napako.

Kako je videti simptom pri hladnem zagonu

Namig je razlika med hladnim zagonom in ponovnim zagonom. Pri hladnem zagonu RRAS poroča, da teče, medtem ko vmesnika tunela ni, pot manjka ali naslov partnerja še ni razrešen. Ročni ponovni zagon nato uspe, ker vir v tistem trenutku obstaja in storitev preprosto znova prebere svet, ki ga minuto prej ni mogla videti. Dnevnik storitve bo v obeh primerih pokazal čist zagon, zato pregledovalnik dogodkov sam to redko pojasni.

Zabeležite obe stanji, preden karkoli spremenite: kaj RRAS poroča ob zagonu in kaj obstaja v trenutku, ko ročni ponovni zagon uspe. Če sta ti dve opažanji enaki, vrstni red zagona ni vaša razlaga in odvisnost ne bo pomagala. Primerjava stane deset minut in prihrani teden ugibanja.

Odvisnost, dodana na podlagi »deluje po ponovnem zagonu«, le odloži isto napako za čas, ki ga predhodna storitev potrebuje za poročanje RUNNING. Zagon tudi oteži razumevanje, ker je omejitev vrstnega reda zdaj videti kot razlaga. Vprašajte, kateri objekt odvisnost zagotavlja in ali je ta objekt tisti, ki ga RRAS ni mogel videti.

Poimenujte vir, ne le storitve

Zapišite konkretno stvar, ki manjka. To je lahko vmesnik tunela z naslovom, pot v podomrežje partnerja, odgovor DNS ali potrdilo, ki se še izdaja. »Storitev VPN teče« ni opis vira, in zelena ikona v odjemalcu tudi ne. Dokler ne morete poimenovati objekta in ukaza, ki ga pokaže, niste opredelili pogoja, na katerega poskušate čakati.

Ugotovite tudi, kako se zažene ta primerek OpenVPN. Tunel, ki ga upravlja GUI, in tunel, ki ga upravlja storitev, imata različna življenjska cikla zagona, ime storitve pa mora priti s stroja pred vami, ne iz primera, napisanega za drug nameščevalnik. Naštejte kandidate, namesto da zaupate zapomnjenemu imenu.

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

Preberite verigo odvisnosti, preden ji kaj dodate

Upravitelj za nadzor storitev poroča stanja, kot sta START_PENDING in RUNNING, SERVICE_STATUS reference pa natančno opredeljuje, kaj pomeni vsako polje. Nobeno od teh stanj ne obljublja, da so partner, ime DNS ali nižja aplikacija dosegljivi. Ta vrzel je ves razlog, da ta napaka preživi pravilno konfigurirano odvisnost.

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

Vrstica DEPENDENCIES iz sc.exe qc je seznam, ki ga morate ohraniti, ker sc.exe config RemoteAccess depend= zamenja celoten seznam, namesto da bi mu dodajal. Če med dodajanjem storitve VPN izpustite nepovezan predpogoj, nastane druga napaka, ki se pojavi ob drugem zagonu, in to je veliko težje diagnosticirati kot prvotno. Kopirajte obstoječi seznam v svoj dnevnik sprememb, preden se ga dotaknete.

Odvisnosti spremenijo tudi vedenje ob izklopu, ker zaustavitev predpogoja zaustavi storitve, ki so od njega odvisne. Preverite, kaj se zgodi med vzdrževanjem, preden RRAS povežete z nečim, kar se pogosto znova zažene.

Ponovni zagon pogojite s pogojem, ne s časovnikom

Fiksno čakanje predpostavlja, da bo tunel vedno pripravljen v tem oknu, in prav ta predpostavka odpove pri zagonu, ko je potrdilo počasno ali je povezava prekinjena. Preverite vir sam, z rokom, in pustite preverjanju, da odloči, ali je ponovni zagon sploh potreben.

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'

Načrtovano opravilo ob zagonu, ki izvede ta preverjanja in znova zažene RRAS le, ko vmesnika ali poti še ni, je omejeno, revidirljivo in enostavno odstranljivo. Alternativa, ponovni zagon RRAS ob vsaki ponovni povezavi, prekine zdrave seje in nestabilno povezavo spremeni v zanko ponovnih zagonov. Ta zanka je slabša od prvotne napake, ker zdaj prizadene uporabnike, ki jim je bilo dobro.

Preverjanju dajte najdaljše čakanje, ki ustreza času, ki ga tunel na vaši strojni opremi razumno potrebuje, in naj se opravilo konča s stanjem, ki ni nič, ko obupa. Tihega opravila, ki preprosto preneha poskušati, ni mogoče ločiti od uspešnega.

Zabeležite prehod, da se bo naslednji zagon pojasnil sam

Zabeležite tri časovne žige v isti vrstici: kdaj je odvisnostna storitev dosegla RUNNING, kdaj se je pojavil zahtevani vir in kdaj ga je RRAS končno sprejel. Ta ena vrstica odgovori na vprašanje, ki ga bo postavil naslednji inženir, in njeno ustvarjanje skoraj nič ne stane. Brez nje se naslednja preiskava začne pri enakem ugibanju kot ta.

Ustavite avtomatizacijo po določenem številu poskusov in sporočite napako, namesto da poskušate večno. Zagon, ki se konča z jasnim sporočilom »vir se ni nikoli pojavil«, je vreden več kot tisti, ki še naprej v temi znova zažene storitev. Ko se to sporočilo pojavi, je ime vira, ki ste ga zapisali v drugem razdelku, tisto, kar bo iskala naslednja oseba.