RRAS sa spustí skôr, než je tunel OpenVPN pri štarte pripravený

Server sa reštartuje, OpenVPN sa spustí a RRAS nabehne, zatiaľ čo adaptér alebo trasa, od ktorých závisí, ešte chýbajú. Ručný reštart RRAS o minútu to opraví, čo problém vyzerá vyriešený a ten skutočný skryje. Miešajú sa tu dve rôzne podmienky: predpokladaná služba beží a sieťový prostriedok, ktorý RRAS skutočne potrebuje, sa stal použiteľným. Závislosť služby Windows dokáže vyjadriť prvú podmienku a nikdy druhú, takže pridanie závislosti bez definovania prostriedku vám kúpi úhľadnejšie vyzerajúci štart a rovnakú poruchu.

Ako vyzerá príznak pri studenom štarte

Príznakom je rozdiel medzi studeným štartom a reštartom. Pri studenom štarte RRAS hlási, že beží, zatiaľ čo adaptér tunela chýba, trasa chýba alebo sa adresa partnera ešte neprekladá. Ručný reštart potom uspeje, pretože v tom čase prostriedok existuje a služba jednoducho znovu číta svet, ktorý o minútu skôr nevidela. Protokol služby v oboch prípadoch ukáže čistý štart, a preto to prehliadač udalostí sám málokedy vysvetlí.

Zachyťte oba stavy, než čokoľvek zmeníte: čo RRAS hlási pri štarte a čo existuje v okamihu, keď ručný reštart uspeje. Ak sú tieto dve pozorovania totožné, poradie štartu nie je vaše vysvetlenie a závislosť nepomôže. Porovnanie stojí desať minút a ušetrí týždeň hádania.

Závislosť pridaná na základe „funguje to po reštarte“ len odloží rovnakú poruchu o čas, ktorý predpokladaná služba potrebuje na nahlásenie RUNNING. Tiež robí štart ťažšie pochopiteľným, pretože obmedzenie poradia teraz vyzerá ako vysvetlenie. Pýtajte sa, aký objekt závislosť zaručuje a či je to práve ten objekt, ktorý RRAS nemohol vidieť.

Pomenujte prostriedok, nie len službu

Zapíšte konkrétnu vec, ktorá chýba. Môže to byť adaptér tunela s adresou, trasa do podsiete partnera, odpoveď DNS alebo certifikát, ktorý sa ešte zriaďuje. „Služba VPN beží“ nie je opis prostriedku, rovnako ako zelená ikona v klientovi. Kým neviete pomenovať objekt a príkaz, ktorý ho ukáže, nedefinovali ste podmienku, na ktorú sa snažíte čakať.

Zistite tiež, ako sa spúšťa táto inštancia OpenVPN. Tunel spravovaný GUI a tunel spravovaný službou majú rôzne životné cykly štartu a názov služby musí pochádzať zo stroja pred vami, nie z príkladu napísaného pre iný inštalátor. Vymenujte kandidátov, namiesto toho aby ste verili zapamätanému názvu.

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

Prečítajte si reťazec závislostí, než doň niečo pridáte

Správca riadenia služieb hlási stavy ako START_PENDING a RUNNING a SERVICE_STATUS reference presne definuje, čo každé pole znamená. Žiadny z týchto stavov nesľubuje, že partner, meno DNS alebo naväzujúca aplikácia sú dostupné. Táto medzera je celý dôvod, prečo táto porucha prežije správne nakonfigurovanú závislosť.

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

Riadok DEPENDENCIES z sc.exe qc je zoznam, ktorý musíte zachovať, pretože sc.exe config RemoteAccess depend= nahrádza celý zoznam, namiesto toho aby doň pridával. Vynechanie nesúvisiaceho predpokladu pri pridávaní služby VPN vytvorí druhú poruchu, ktorá sa objaví pri inom štarte, a je oveľa ťažšie ju diagnostikovať ako pôvodnú. Skopírujte existujúci zoznam do záznamu o zmenách, než naň siahnate.

Závislosti menia aj správanie pri vypnutí, pretože zastavenie predpokladu zastaví služby, ktoré od neho závisia. Skontrolujte, čo sa deje počas údržby, než RRAS prepojíte s niečím, čo sa často reštartuje.

Podmieňte reštart podmienkou, nie časovačom

Pevné čakanie predpokladá, že tunel bude vždy v rámci toho okna pripravený, a to je práve predpoklad, ktorý zlyhá pri štarte, keď je certifikát pomalý alebo je spojenie prerušené. Skontrolujte samotný prostriedok s lehotou a nechajte kontrolu rozhodnúť, či je reštart vôbec potrebný.

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'

Naplánovaná úloha pri štarte, ktorá vykonáva tieto kontroly a reštartuje RRAS len vtedy, keď adaptér alebo trasa stále chýbajú, je obmedzená, auditovateľná a ľahko odstrániteľná. Alternatíva, reštartovať RRAS pri každom opätovnom pripojení, prerušuje zdravé relácie a mení nestabilné spojenie na slučku reštartov. Tá slučka je horšia ako pôvodná porucha, pretože teraz postihuje používateľov, ktorým bolo dobre.

Dajte kontrole maximálne čakanie zodpovedajúce času, ktorý tunel na vašom hardvéri rozumne potrebuje, a nechajte úlohu skončiť s nenulovým stavom, keď to vzdá. Tichá úloha, ktorá jednoducho prestane skúšať, je nerozoznateľná od tej, ktorá uspela.

Zaznamenajte prechod, aby sa budúci štart vysvetlil sám

Zaznamenajte tri časové značky na ten istý riadok: kedy závislá služba dosiahla RUNNING, kedy sa objavil požadovaný prostriedok a kedy ho RRAS konečne prijal. Ten jediný riadok odpovedá na otázku, ktorú položí budúci inžinier, a jeho vytvorenie takmer nič nestojí. Bez neho budúce vyšetrovanie začína pri rovnakom hádaní ako toto.

Zastavte automatizáciu po definovanom počte pokusov a nahláste zlyhanie, namiesto toho aby ste skúšali donekonečna. Štart, ktorý sa skončí jasnou správou „prostriedok sa nikdy neobjavil“, má väčšiu cenu než ten, ktorý ďalej reštartuje službu potme. Keď sa tá správa objaví, názov prostriedku, ktorý ste zapísali v druhej časti, je to, čo bude hľadať budúci človek.