RRAS käivitub enne, kui OpenVPN-tunnel on alglaadimisel valmis

Server taaskäivitub, OpenVPN käivitub ja RRAS tõuseb üles, samal ajal kui adapter või marsruut, millest see sõltub, on veel puudu. RRAS-i käsitsi minut hiljem taaskäivitamine parandab selle, mistõttu tundub probleem lahendatud ja peidab tegeliku. Siin aetakse segamini kaks erinevat tingimust: eeldusteenus töötab ja võrguresurss, mida RRAS tegelikult vajab, on muutunud kasutatavaks. Windowsi teenusesõltuvus suudab väljendada esimest tingimust ja mitte kunagi teist, seega sõltuvuse lisamine ilma ressurssi määratlemata annab korrektsema alglaadimise ja sama tõrke.

Kuidas sümptom külmal alglaadimisel välja näeb

Tunnus on erinevus külma käivituse ja taaskäivituse vahel. Külmal käivitusel teatab RRAS, et töötab, samal ajal kui tunneladapter puudub, marsruut on kadunud või vastaspoole aadress ei ole veel lahendatud. Käsitsi taaskäivitamine õnnestub siis, sest selleks ajaks on ressurss olemas ja teenus lihtsalt loeb uuesti maailma, mida see minut varem näha ei saanud. Teenuselogi näitab mõlemal juhul puhast käivitust, mistõttu sündmustevaataja üksi seda harva selgitab.

Fikseerige mõlemad olekud enne, kui midagi muudate: mida RRAS alglaadimisel teatab ja mis on olemas hetkel, mil käsitsi taaskäivitus õnnestub. Kui need kaks tähelepanekut on identsed, ei ole käivitumisjärjekord teie selgitus ja sõltuvus ei aita. Võrdlus võtab kümme minutit ja säästab nädala oletusi.

Sõltuvus, mis on lisatud põhjendusega „töötab pärast taaskäivitust“, lükkab sama tõrke edasi vaid nii kaua, kui eeldusteenusel kulub RUNNING-i teatamiseks. See teeb ka alglaadimise raskemini mõistetavaks, sest järjekorrapiirang näeb nüüd välja nagu selgitus. Küsige, millist objekti sõltuvus tagab ja kas see objekt on see, mida RRAS näha ei saanud.

Nimetage ressurss, mitte ainult teenus

Kirjutage üles konkreetne asi, mis puudub. See võib olla aadressiga tunneladapter, marsruut vastaspoole alavõrku, DNS-vastus või sertifikaat, mida alles väljastatakse. „VPN-teenus töötab“ ei ole ressursi kirjeldus, ja seda ei ole ka roheline ikoon kliendis. Kuni te ei suuda nimetada objekti ja käsku, mis seda näitab, ei ole te määratlenud tingimust, mida proovite oodata.

Tehke kindlaks ka see, kuidas seda OpenVPN-i eksemplari käivitatakse. GUI-hallataval tunnelil ja teenusehallataval tunnelil on erinevad alglaadimise elutsüklid ning teenuse nimi peab tulema teie ees olevast masinast, mitte teise paigaldaja jaoks kirjutatud näitest. Loetlege kandidaadid, selle asemel et usaldada meelespeetud nime.

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

Lugege sõltuvusahelat enne, kui midagi lisate

Teenuse juhtimise haldur teatab olekuid nagu START_PENDING ja RUNNING ning SERVICE_STATUS reference määratleb täpselt, mida iga väli tähendab. Ükski neist olekutest ei taga, et vastaspool, DNS-nimi või allavoolu rakendus on kättesaadav. See lünk on kogu põhjus, miks see tõrge elab üle korralikult konfigureeritud sõltuvuse.

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

Rida DEPENDENCIES väljundist sc.exe qc on nimekiri, mille peate säilitama, sest sc.exe config RemoteAccess depend= asendab kogu nimekirja, mitte ei lisa sellele. Sõltumatu eelduse väljajätmine VPN-teenuse lisamisel loob teise tõrke, mis ilmneb teisel alglaadimisel ja mida on palju raskem diagnoosida kui algset. Kopeerige olemasolev nimekiri oma muudatuste kirjesse enne, kui seda puudutate.

Sõltuvused muudavad ka väljalülitumise käitumist, sest eelduse peatamine peatab sellest sõltuvad teenused. Kontrollige, mis hoolduse ajal juhtub, enne kui ühendate RRAS-i millegi külge, mis käivitub sageli uuesti.

Siduge taaskäivitus tingimusega, mitte taimeriga

Fikseeritud ootamine eeldab, et tunnel on selles aknas alati valmis, ja just see eeldus ebaõnnestub alglaadimisel, kui sertifikaat on aeglane või link on maas. Kontrollige ressurssi ennast tähtajaga ja laske kontrollil otsustada, kas taaskäivitust on üldse vaja.

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'

Alglaadimisel käivitatav ajastatud ülesanne, mis neid kontrolle teeb ja taaskäivitab RRAS-i ainult siis, kui adapter või marsruut on endiselt puudu, on piiratud, auditeeritav ja lihtne eemaldada. Alternatiiv, RRAS-i taaskäivitamine igal taasühendusel, katkestab terved sessioonid ja muudab ebastabiilse lingi taaskäivituste ahelaks. See ahel on hullem kui algne tõrge, sest mõjutab nüüd kasutajaid, kellel oli kõik korras.

Andke kontrollile maksimaalne ootus, mis vastab ajale, mille tunnel teie riistvaral mõistlikult võtab, ja laske ülesandel loobuda mittetäisarvulise olekuga. Vaikne ülesanne, mis lihtsalt lõpetab proovimise, ei erine sellest, mis õnnestus.

Logige üleminek, et järgmine alglaadimine seletaks end ise

Kirjutage samale reale kolm ajatemplit: millal sõltuvusteenus jõudis RUNNING-i, millal ilmus nõutav ressurss ja millal RRAS selle lõpuks vastu võttis. See üks rida vastab küsimusele, mille järgmine insener küsib, ja selle tootmine ei maksa peaaegu midagi. Ilma selleta algab järgmine uurimine samast oletusest nagu see.

Peatage automatiseerimine pärast määratud arvu katseid ja teatage tõrkest, selle asemel et igavesti uuesti proovida. Alglaadimine, mis lõpeb selge teatega „ressurss ei ilmunud kunagi“, on väärtuslikum kui see, mis jätkab teenuse taaskäivitamist pimedas. Kui see teade ilmub, on ressurssi nimi, mille te teises jaotises üles kirjutasite, see, mida järgmine inimene otsib.