RRAS se spustí dřív, než je tunel OpenVPN při startu připraven

Závislost určuje pořadí spouštění služby; tunel tím použitelným neudělá. Pojmenujte prostředek, který RRAS potřebuje, a restart podmiňte jím, ne čekáním.

Server se restartuje, OpenVPN se spustí a RRAS naběhne, zatímco adaptér nebo trasa, na kterých závisí, ještě chybí. Ruční restart RRAS o minutu později to opraví, což problém vypadá vyřešený a skutečný skryje. Míchají se tu dvě různé podmínky: předpokládaná služba běží a síťový prostředek, který RRAS skutečně potřebuje, se stal použitelným. Závislost služby Windows umí vyjádřit první podmínku a nikdy druhou, takže přidání závislosti bez definice prostředku vám koupí úhledněji vypadající start a stejnou závadu.

Jak symptom vypadá při studeném startu

Příznakem je rozdíl mezi studeným startem a restartem. Při studeném startu RRAS hlásí, že běží, zatímco adaptér tunelu chybí, trasa chybí nebo se adresa protistrany ještě nepřekládá. Ruční restart pak uspěje, protože v tu dobu už prostředek existuje a služba prostě znovu čte svět, který o minutu dřív neviděla. Protokol služby v obou případech ukáže čistý start, a proto to prohlížeč událostí sám málokdy vysvětlí.

Zachyťte oba stavy, než cokoli změníte: co RRAS hlásí při startu a co existuje v okamžiku, kdy ruční restart uspěje. Pokud jsou tato dvě pozorování totožná, pořadí startu není vaše vysvětlení a závislost nepomůže. Srovnání stojí deset minut a ušetří týden hádání.

Závislost přidaná na základě „funguje to po restartu“ jen odloží stejnou závadu o dobu, kterou předpokládaná služba potřebuje k nahlášení RUNNING. Také dělá start hůř pochopitelným, protože omezení pořadí teď vypadá jako vysvětlení. Ptejte se, jaký objekt závislost zaručuje a zda je to právě ten objekt, který RRAS nemohl vidět.

Pojmenujte prostředek, ne jen službu

Zapište konkrétní věc, která chybí. Může to být adaptér tunelu s adresou, trasa do podsítě protistrany, odpověď DNS nebo certifikát, který se ještě zřizuje. „Služba VPN běží“ není popis prostředku, stejně jako zelená ikona v klientovi. Dokud neumíte pojmenovat objekt a příkaz, který ho ukáže, nedefinovali jste podmínku, na kterou se snažíte čekat.

Zjistěte také, jak se tato instance OpenVPN spouští. Tunel spravovaný GUI a tunel spravovaný službou mají různé životní cykly startu a název služby musí pocházet ze stroje před vámi, ne z příkladu napsaného pro jiný instalátor. Vyjmenujte kandidáty, místo abyste věřili zapamatovanému názvu.

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

Přečtěte si řetězec závislostí, než do něj něco přidáte

Správce řízení služeb hlásí stavy jako START_PENDING a RUNNING a SERVICE_STATUS reference přesně definuje, co každé pole znamená. Žádný z těchto stavů neslibuje, že protistrana, jméno DNS nebo navazující aplikace jsou dostupné. Tato mezera je celý důvod, proč tato závada přežije správně nakonfigurovanou závislost.

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

Řádek DEPENDENCIES z sc.exe qc je seznam, který musíte zachovat, protože sc.exe config RemoteAccess depend= nahrazuje celý seznam, místo aby k němu přidával. Vynechání nesouvisejícího předpokladu při přidávání služby VPN vytvoří druhou závadu, která se objeví při jiném startu, a je mnohem těžší ji diagnostikovat než původní. Zkopírujte existující seznam do záznamu o změnách, než na něj sáhnete.

Závislosti mění i chování při vypnutí, protože zastavení předpokladu zastaví služby, které na něm závisí. Zkontrolujte, co se děje během údržby, než RRAS propojíte s něčím, co se často restartuje.

Podmiňte restart podmínkou, ne časovačem

Pevné čekání předpokládá, že tunel bude vždy během toho okna připraven, a to je právě předpoklad, který selže při startu, kdy je certifikát pomalý nebo je spojení přerušené. Zkontrolujte samotný prostředek s lhůtou a nechte kontrolu rozhodnout, zda je restart vůbec potřeba.

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 při startu, která tyto kontroly provádí a restartuje RRAS jen tehdy, když adaptér nebo trasa stále chybí, je omezená, auditovatelná a snadno odstranitelná. Alternativa, restartovat RRAS při každém opětovném připojení, přerušuje zdravé relace a mění nestabilní spojení ve smyčku restartů. Ta smyčka je horší než původní závada, protože teď postihuje uživatele, kterým bylo dobře.

Dejte kontrole maximální čekání odpovídající době, kterou tunel na vašem hardwaru rozumně potřebuje, a nechte úlohu skončit s nenulovým stavem, když to vzdá. Tichá úloha, která prostě přestane zkoušet, je nerozeznatelná od té, která uspěla.

Zaznamenejte přechod, aby se příští start vysvětlil sám

Zaznamenejte tři časové značky na stejný řádek: kdy závislá služba dosáhla RUNNING, kdy se objevil požadovaný prostředek a kdy jej RRAS konečně přijal. Ten jediný řádek odpovídá na otázku, kterou položí příští inženýr, a jeho vytvoření téměř nic nestojí. Bez něj příští vyšetřování začíná u stejného hádání jako toto.

Zastavte automatizaci po definovaném počtu pokusů a nahlaste selhání, místo abyste zkoušeli donekonečna. Start, který skončí jasnou zprávou „prostředek se nikdy neobjevil“, má větší cenu než ten, který dál restartuje službu potmě. Když se ta zpráva objeví, název prostředku, který jste zapsali ve druhé části, je to, co bude hledat příští člověk.

Související články