Az RRAS a rendszerindításkor az OpenVPN-alagút elkészülte előtt indul

A kiszolgáló újraindul, a OpenVPN elindul, és az RRAS feljön, miközben az adapter vagy az útvonal, amelytől függ, még hiányzik. Az RRAS egy perccel későbbi kézi újraindítása helyrehozza, amitől a probléma megoldottnak látszik, és elrejti az igazit. Itt két különböző feltétel keveredik: az előfeltétel-szolgáltatás fut, és az a hálózati erőforrás, amelyre az RRAS-nak valóban szüksége van, használhatóvá vált. A Windows szolgáltatásfüggősége az első feltételt ki tudja fejezni, a másodikat soha, ezért a függőség erőforrás nélküli hozzáadása rendezettebbnek látszó indítást és ugyanazt a hibát adja.

Hogyan néz ki a tünet hideg indításnál

A jel a hideg indítás és az újraindítás közötti különbség. Hideg indításnál az RRAS futó állapotot jelent, miközben az alagút-adapter hiányzik, az útvonal elveszett, vagy a partner címe még nem oldódik fel. A kézi újraindítás ezután sikerül, mert akkorra az erőforrás létezik, és a szolgáltatás egyszerűen újraolvas egy világot, amelyet egy perccel korábban nem láthatott. A szolgáltatásnapló mindkét esetben tiszta indítást mutat, ezért az eseménynapló önmagában ritkán magyarázza ezt.

Rögzítse mindkét állapotot, mielőtt bármit módosít: mit jelent az RRAS indításkor, és mi létezik abban a pillanatban, amikor a kézi újraindítás sikerül. Ha ez a két megfigyelés azonos, az indítási sorrend nem a magyarázat, és a függőség nem segít. Az összehasonlítás tíz percet vesz igénybe, és egy hét találgatást spórol meg.

A „újraindítás után működik” alapján hozzáadott függőség csak annyival késlelteti ugyanazt a hibát, amennyi idő alatt az előfeltétel-szolgáltatás jelenti a RUNNING állapotot. Az indítást is nehezebb megérteni, mert a sorrendi kényszer most magyarázatnak látszik. Kérdezze meg, melyik objektumot garantálja a függőség, és hogy az az objektum-e, amelyet az RRAS nem láthatott.

Az erőforrást nevezze meg, ne csak a szolgáltatást

Írja le a konkrét hiányzó dolgot. Lehet címmel rendelkező alagút-adapter, útvonal egy partner alhálózathoz, DNS-válasz vagy még kiadás alatt álló tanúsítvány. „A VPN-szolgáltatás fut” nem erőforrás-leírás, és egy zöld ikon egy kliensben sem az. Amíg nem tudja megnevezni az objektumot és egy parancsot, amely megmutatja, addig nem definiálta a feltételt, amelyre várni próbál.

Azt is állapítsa meg, hogyan indul ez az OpenVPN-példány. A GUI által kezelt alagút és a szolgáltatás által kezelt alagút indítási életciklusa eltér, és a szolgáltatás nevét az előtte álló gépről kell venni, nem egy másik telepítőhöz írt példából. Sorolja fel a jelölteket, ahelyett hogy egy emlékezett névben bízna.

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

Olvassa el a függőségi láncot, mielőtt bármit hozzáadna

A Szolgáltatásvezérlő START_PENDING és RUNNING állapotokat jelent, és a SERVICE_STATUS reference pontosan meghatározza, mit jelent az egyes mezők. Egyik állapot sem ígéri, hogy egy partner, egy DNS-név vagy egy alsóbb alkalmazás elérhető. Ez a rés az egész oka annak, hogy ez a hiba túlél egy helyesen beállított függőséget.

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

A DEPENDENCIES sor a sc.exe qc kimenetéből az a lista, amelyet meg kell őriznie, mert a sc.exe config RemoteAccess depend= a teljes listát lecseréli, nem hozzáfűz. Egy nem kapcsolódó előfeltétel kihagyása VPN-szolgáltatás hozzáadásakor egy második hibát hoz létre, amely egy másik indításnál jelenik meg, és sokkal nehezebb diagnosztizálni, mint az eredetit. Másolja a meglévő listát a változási nyilvántartásába, mielőtt hozzányúl.

A függőségek a leállítási viselkedést is megváltoztatják, mert egy előfeltétel leállítása leállítja a tőle függő szolgáltatásokat. Ellenőrizze, mi történik karbantartás közben, mielőtt az RRAS-t valamihez köti, ami gyakran újraindul.

Az újraindítást feltételhez kösse, ne időzítőhöz

A fix várakozás feltételezi, hogy az alagút mindig elkészül azon az ablakon belül, és pontosan ez a feltételezés bukik meg azon az indításon, amikor egy tanúsítvány lassú, vagy egy kapcsolat leesett. Ellenőrizze magát az erőforrást, határidővel, és hagyja, hogy az ellenőrzés döntse el, egyáltalán szükséges-e újraindítás.

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'

Egy indításkor futó ütemezett feladat, amely ezeket az ellenőrzéseket futtatja, és csak akkor indítja újra az RRAS-t, amikor az adapter vagy az útvonal még hiányzik, korlátozott, auditálható és könnyen eltávolítható. Az alternatíva, hogy minden újracsatlakozáskor újraindítják az RRAS-t, megszakítja az egészséges munkameneteket, és egy instabil kapcsolatból újraindítási hurkot csinál. Az a hurok rosszabb az eredeti hibánál, mert most olyan felhasználókat is érint, akiknél minden rendben volt.

Adjon az ellenőrzésnek olyan maximális várakozást, amely megfelel annak, mennyi idő alatt az alagút ésszerűen elkészül a hardverén, és a feladat adja fel nem nulla állapottal, amikor feladja. Egy csendes feladat, amely egyszerűen abbahagyja a próbálkozást, nem különböztethető meg egy sikeres feladattól.

Naplózza az átmenetet, hogy a következő indítás magát magyarázza

Rögzítsen három időbélyeget ugyanabban a sorban: mikor érte el a függőségi szolgáltatás a RUNNING állapotot, mikor jelent meg a szükséges erőforrás, és mikor fogadta el végül az RRAS. Az az egy sor válaszol arra a kérdésre, amelyet a következő mérnök fel fog tenni, és előállítása szinte semmibe sem kerül. Nélküle a következő vizsgálat ugyanabból a találgatásból indul, mint ez.

Állítsa le az automatizálást meghatározott számú kísérlet után, és jelentsen hibát a végtelen újrapróbálkozás helyett. Egy indítás, amely világos „az erőforrás soha nem jelent meg” üzenettel ér véget, többet ér, mint amely sötétben újraindít egy szolgáltatást. Amikor az az üzenet megjelenik, az erőforrásnév, amelyet a második szakaszban felírt, az lesz, amit a következő ember keresni fog.