RRAS käynnistyy ennen kuin OpenVPN-tunneli on valmis käynnistyksen yhteydessä

Palvelin käynnistyy uudelleen, OpenVPN käynnistyy ja RRAS nousee pystyyn, kun taas sovitin tai reitti, josta se riippuu, puuttuu vielä. RRAS:n uudelleenkäynnistys käsin minuuttia myöhemmin korjaa sen, mikä saa ongelman näyttämään ratkaistulta ja kätkee todellisen. Tässä sekoitetaan kaksi eri ehtoa: edellytyspalvelu on käynnissä, ja verkkoresurssi, jota RRAS todella tarvitsee, on tullut käyttökelpoiseksi. Windowsin palveluriippuvuus voi ilmaista ensimmäisen ehdon eikä koskaan toista, joten riippuvuuden lisääminen määrittelemättä resurssia antaa siistimmän käynnistyksen ja saman vian.

Miltä oire näyttää kylmäkäynnistyksessä

Tuntomerkki on ero kylmäkäynnistyksen ja uudelleenkäynnistyksen välillä. Kylmäkäynnistyksessä RRAS ilmoittaa olevansa käynnissä, vaikka tunnelisovitin puuttuu, reitti on kadonnut tai vastapuolen osoite ei vielä ratkea. Käsinkäynnistys onnistuu sitten, koska siihen mennessä resurssi on olemassa ja palvelu yksinkertaisesti lukee uudelleen maailman, jota se ei voinut nähdä minuuttia aiemmin. Palveluloki näyttää molemmissa tapauksissa puhtaan käynnistyksen, minkä vuoksi tapahtumien katseluohjelma yksin harvoin selittää tätä.

Tallenna molemmat tilat ennen kuin muutat mitään: mitä RRAS ilmoittaa käynnistyksessä ja mitä on olemassa hetkellä, jolloin käsinkäynnistys onnistuu. Jos nämä kaksi havaintoa ovat identtiset, käynnistysjärjestys ei ole selityksesi eikä riippuvuus auta. Vertailu maksaa kymmenen minuuttia ja säästää viikon arvailua.

Riippuvuus, joka lisätään perusteella ”toimii uudelleenkäynnistyksen jälkeen”, vain lykkää samaa vikaa niin kauan kuin edellytyspalvelulla kestää ilmoittaa RUNNING. Se tekee käynnistyksestä myös vaikeammin ymmärrettävän, koska järjestysrajoitus näyttää nyt selitykseltä. Kysy, minkä objektin riippuvuus takaa ja onko tuo objekti se, jota RRAS ei voinut nähdä.

Nimeä resurssi, älä vain palvelua

Kirjoita ylös konkreettinen asia, joka puuttuu. Se voi olla tunnelisovitin, jolla on osoite, reitti vastapuolen aliverkkoon, DNS-vastaus tai sertifikaatti, jota vielä myönnetään. ”VPN-palvelu on käynnissä” ei ole resurssin kuvaus, eikä asiakasohjelman vihreä kuvake ole sitä. Ennen kuin pystyt nimeämään objektin ja komennon, joka näyttää sen, et ole määritellyt ehtoa, jota yrität odottaa.

Selvitä myös, miten tämä OpenVPN-esiintymä käynnistetään. GUI:n hallitsemalla tunnelilla ja palvelun hallitsemalla tunnelilla on erilaiset käynnistyksen elinkaaret, ja palvelun nimen on tultava edessäsi olevasta koneesta, ei toiselle asentajalle kirjoitetusta esimerkistä. Luettele ehdokkaat sen sijaan, että luottaisit muistettuun nimeen.

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

Lue riippuvuusketju ennen kuin lisäät siihen

Palvelunhallinta ilmoittaa tiloja kuten START_PENDING ja RUNNING, ja SERVICE_STATUS reference määrittelee tarkalleen, mitä kukin kenttä tarkoittaa. Mikään näistä tiloista ei lupaa, että vastapuoli, DNS-nimi tai alavirran sovellus on tavoitettavissa. Tämä aukko on koko syy siihen, miksi tämä vika selviää oikein määritetystä riippuvuudesta.

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

Rivi DEPENDENCIES komennosta sc.exe qc on luettelo, joka sinun on säilytettävä, koska sc.exe config RemoteAccess depend= korvaa koko luettelon sen sijaan, että lisäisi siihen. Asiankuulumattoman edellytyksen pudottaminen VPN-palvelua lisättäessä luo toisen vian, joka ilmenee toisella käynnistyskerralla, ja sitä on paljon vaikeampi diagnosoida kuin alkuperäistä. Kopioi olemassa oleva luettelo muutoskirjaasi ennen kuin kosket siihen.

Riippuvuudet muuttavat myös sammutuskäyttäytymistä, koska edellytyksen pysäyttäminen pysäyttää siitä riippuvat palvelut. Tarkista, mitä huollon aikana tapahtuu, ennen kuin kytket RRAS:n johonkin, joka käynnistyy usein uudelleen.

Sido uudelleenkäynnistys ehtoon, älä ajastimeen

Kiinteä odotus olettaa, että tunneli on aina valmis kyseisessä ikkunassa, ja juuri se oletus pettää käynnistyksessä, jossa sertifikaatti on hidas tai linkki on alhaalla. Tarkista itse resurssi määräajalla ja anna tarkistuksen päättää, tarvitaanko uudelleenkäynnistystä lainkaan.

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'

Käynnistyksen yhteydessä ajettava ajastettu tehtävä, joka suorittaa nämä tarkistukset ja käynnistää RRAS:n uudelleen vain, kun sovitin tai reitti yhä puuttuu, on rajattu, auditoitava ja helppo poistaa. Vaihtoehto, RRAS:n uudelleenkäynnistys jokaisella uudelleenyhdistämisellä, keskeyttää terveet istunnot ja muuttaa epävakaan linkin uudelleenkäynnistyssilmukaksi. Se silmukka on pahempi kuin alkuperäinen vika, koska se osuu nyt käyttäjiin, joilla kaikki oli hyvin.

Anna tarkistukselle enimmäisodotus, joka vastaa aikaa, jonka tunneli kohtuudella tarvitsee laitteistollasi, ja anna tehtävän päättyä nollasta poikkeavaan tilaan, kun se luovuttaa. Hiljainen tehtävä, joka yksinkertaisesti lopettaa yrittämisen, on mahdotonta erottaa onnistuneesta.

Kirjaa siirtymä, jotta seuraava käynnistys selittää itsensä

Kirjaa kolme aikaleimaa samalle riville: milloin riippuvuuspalvelu saavutti RUNNING-tilan, milloin tarvittava resurssi ilmestyi ja milloin RRAS lopulta hyväksyi sen. Se yksi rivi vastaa kysymykseen, jonka seuraava insinööri esittää, ja sen tuottaminen ei maksa juuri mitään. Ilman sitä seuraava tutkinta alkaa samasta arvailusta kuin tämä.

Pysäytä automaatio määritellyn yritysmäärän jälkeen ja ilmoita epäonnistumisesta sen sijaan, että yrittäisit ikuisesti uudelleen. Käynnistys, joka päättyy selkeään viestiin ”resurssi ei koskaan ilmestynyt”, on arvokkaampi kuin se, joka jatkaa palvelun uudelleenkäynnistämistä pimeässä. Kun tuo viesti ilmestyy, toisessa osiossa kirjoittamasi resurssin nimi on se, mitä seuraava henkilö etsii.