RRAS paleidžiamas prieš tai, kai paleidimo metu OpenVPN tunelis būna paruoštas

Serveris paleidžiamas iš naujo, OpenVPN paleidžiamas, o RRAS pakyla, kol adapterio ar maršruto, nuo kurių jis priklauso, dar nėra. Rankinis RRAS paleidimas iš naujo po minutės tai ištaiso, todėl problema atrodo išspręsta, o tikroji paslėpta. Čia painiojamos dvi skirtingos sąlygos: išankstinė paslauga veikia, ir tinklo išteklius, kurio RRAS iš tikrųjų reikia, tapo tinkamas naudoti. Windows paslaugos priklausomybė gali išreikšti pirmąją sąlygą ir niekada antrosios, todėl priklausomybės pridėjimas neapibrėžus ištekliaus duoda tvarkingesnį paleidimą ir tą pačią klaidą.

Kaip simptomas atrodo šaltuoju paleidimu

Požymis yra skirtumas tarp šaltojo paleidimo ir paleidimo iš naujo. Šaltojo paleidimo metu RRAS praneša, kad veikia, nors tunelio adapterio nėra, maršrutas dingo arba partnerio adresas dar neišsprendžiamas. Rankinis paleidimas iš naujo tada pavyksta, nes tuo metu išteklius jau egzistuoja, o paslauga tiesiog iš naujo perskaito pasaulį, kurio prieš minutę negalėjo matyti. Paslaugos žurnalas abiem atvejais parodys švarų paleidimą, todėl vien įvykių peržiūra retai tai paaiškina.

Užfiksuokite abi būsenas prieš ką nors keisdami: ką RRAS praneša paleidimo metu ir kas egzistuoja tuo metu, kai rankinis paleidimas iš naujo pavyksta. Jei šie du stebėjimai identiški, paleidimo tvarka nėra jūsų paaiškinimas ir priklausomybė nepadės. Palyginimas kainuoja dešimt minučių ir sutaupo savaitę spėliojimų.

Priklausomybė, pridėta remiantis „veikia po paleidimo iš naujo“, tik atitolina tą pačią klaidą tiek, kiek išankstinei paslaugai reikia pranešti RUNNING. Ji taip pat apsunkina paleidimo supratimą, nes tvarkos apribojimas dabar atrodo kaip paaiškinimas. Paklauskite, kokį objektą garantuoja priklausomybė ir ar tas objektas yra tas, kurio RRAS negalėjo matyti.

Įvardykite išteklių, o ne vien paslaugą

Užrašykite konkretų trūkstamą dalyką. Tai gali būti tunelio adapteris su adresu, maršrutas į partnerio potinklį, DNS atsakymas ar dar teikiamas sertifikatas. „VPN paslauga veikia“ nėra ištekliaus aprašymas, ir žalia piktograma kliente taip pat ne. Kol negalite įvardyti objekto ir komandos, kuri jį parodo, neapibrėžėte sąlygos, kurios bandote laukti.

Nustatykite ir tai, kaip paleidžiama ši OpenVPN kopija. GUI valdomas tunelis ir paslaugos valdomas tunelis turi skirtingus paleidimo gyvavimo ciklus, o paslaugos pavadinimas turi ateiti iš mašinos priešais jus, o ne iš pavyzdžio, rašyto kitam diegėjui. Išvardykite kandidatus, o ne pasikliaukite prisimintu pavadinimu.

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

Prieš ką nors pridėdami perskaitykite priklausomybių grandinę

Paslaugų valdymo tvarkyklė praneša būsenas, tokias kaip START_PENDING ir RUNNING, o SERVICE_STATUS reference tiksliai apibrėžia, ką reiškia kiekvienas laukas. Nė viena iš šių būsenų nežada, kad partneris, DNS vardas ar tolesnė programa yra pasiekiami. Būtent šis tarpas yra visa priežastis, kodėl ši klaida išgyvena teisingai sukonfigūruotą priklausomybę.

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

Eilutė DEPENDENCIES iš sc.exe qc yra sąrašas, kurį turite išsaugoti, nes sc.exe config RemoteAccess depend= pakeičia visą sąrašą, o ne prideda prie jo. Nesusijusios išankstinės sąlygos praleidimas pridedant VPN paslaugą sukuria antrą defektą, kuris pasirodo kitame paleidime, ir jį diagnozuoti daug sunkiau nei pirminį. Nukopijuokite esamą sąrašą į savo pakeitimų įrašą prieš jį liesdami.

Priklausomybės keičia ir išjungimo elgseną, nes sustabdžius išankstinę sąlygą sustabdomos nuo jos priklausančios paslaugos. Patikrinkite, kas vyksta techninės priežiūros metu, prieš prijungdami RRAS prie kažko, kas dažnai paleidžiama iš naujo.

Susiekite paleidimą iš naujo su sąlyga, o ne su laikmačiu

Fiksuotas laukimas daro prielaidą, kad tunelis visada bus paruoštas tame lange, ir būtent ši prielaida žlunga tame paleidime, kai sertifikatas lėtas arba ryšys nutrūkęs. Patikrinkite patį išteklių su terminu ir leiskite patikrinimui nuspręsti, ar paleidimo iš naujo apskritai reikia.

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'

Paleidimo metu vykdoma suplanuota užduotis, kuri atlieka šiuos patikrinimus ir paleidžia RRAS iš naujo tik tada, kai adapterio ar maršruto dar nėra, yra ribota, audituojama ir lengvai pašalinama. Alternatyva – paleisti RRAS iš naujo po kiekvieno prisijungimo – pertraukia sveikas sesijas ir nestabilią jungtį paverčia paleidimų ciklu. Tas ciklas blogesnis už pradinį defektą, nes dabar paliečia naudotojus, kuriems viskas buvo gerai.

Suteikite patikrinimui maksimalų laukimą, atitinkantį laiką, kurio tunelis pagrįstai užima jūsų aparatinėje įrangoje, ir leiskite užduočiai pasibaigti ne nuline būsena, kai ji pasiduoda. Tyliai užduočiai, kuri tiesiog nustoja bandyti, neįmanoma atskirti nuo sėkmingos.

Užregistruokite perėjimą, kad kitas paleidimas paaiškintų save

Įrašykite tris laiko žymes toje pačioje eilutėje: kada priklausomybės paslauga pasiekė RUNNING, kada pasirodė reikalingas išteklius ir kada RRAS galiausiai jį priėmė. Ta viena eilutė atsako į klausimą, kurį užduos kitas inžinierius, ir ją sukurti beveik nieko nekainuoja. Be jos kitas tyrimas prasideda nuo tų pačių spėlionių, kaip ir šis.

Sustabdykite automatizavimą po nustatyto bandymų skaičiaus ir praneškite apie nesėkmę, o ne bandykite amžinai. Paleidimas, kuris baigiasi aiškiu pranešimu „išteklius taip ir nepasirodė“, vertas daugiau nei tas, kuris toliau tamsoje paleidinėja paslaugą. Kai tas pranešimas pasirodys, ištekliaus pavadinimas, kurį užrašėte antrame skyriuje, yra tai, ko ieškos kitas žmogus.