RRAS niset përpara se tuneli OpenVPN të jetë gati në nisje

Serveri riniset, OpenVPN niset, dhe RRAS ngrihet ndërsa përshtatësi ose rruga nga e cila varet ende mungon. Rinisja manuale e RRAS një minutë më vonë e rregullon, gjë që e bën problemin të duket i zgjidhur dhe fsheh atë të vërtetë. Këtu ngatërrohen dy kushte të ndryshme: shërbimi parakusht është në punë, dhe burimi i rrjetit që RRAS i nevojitet vërtet është bërë i përdorshëm. Një varësi shërbimi Windows mund të shprehë kushtin e parë dhe kurrë të dytin, prandaj shtimi i një varësie pa përcaktuar burimin ju jep një nisje më të rregullt në pamje dhe të njëjtin dështim.

Si duket simptoma në një nisje të ftohtë

Treguesi është ndryshimi midis nisjes së ftohtë dhe rinisjes. Në nisje të ftohtë RRAS raporton se është në punë ndërsa përshtatësi i tunelit mungon, rruga ka humbur, ose adresa e palës nuk zgjidhet ende. Një rinisje manuale pastaj ka sukses sepse në atë moment burimi ekziston, dhe shërbimi thjesht rilexon një botë që nuk mund ta shihte një minutë më parë. Regjistri i shërbimit do të tregojë një nisje të pastër në të dyja rastet, dhe për këtë arsye shikuesi i ngjarjeve i vetëm rrallë e shpjegon këtë.

Regjistroni të dyja gjendjet përpara se të ndryshoni diçka: çfarë raporton RRAS në nisje, dhe çfarë ekziston në momentin kur rinisja manuale ka sukses. Nëse këto dy vëzhgime janë identike, rendi i nisjes nuk është shpjegimi juaj dhe një varësi nuk do të ndihmojë. Krahasimi kushton dhjetë minuta dhe kursen një javë hamendjesh.

Një varësi e shtuar mbi bazën „funksionon pas një rinisje“ vetëm e shtyn të njëjtin dështim për kohën që i duhet shërbimit parakusht për të raportuar RUNNING. Ajo gjithashtu e bën nisjen më të vështirë për t'u arsyetuar, sepse kufizimi i rendit tani duket si shpjegim. Pyetni cilin objekt garanton varësia dhe nëse ai objekt është ai që RRAS nuk mund ta shihte.

Emërtoni burimin, jo vetëm shërbimin

Shkruani gjënë konkrete që mungon. Mund të jetë një përshtatës tuneli me adresë, një rrugë drejt një nënrrjete pale, një përgjigje DNS, ose një certifikatë që ende po sigurohet. „Shërbimi VPN është në punë“ nuk është përshkrim burimi, dhe as një ikonë e gjelbër në një klient. Derisa të mund të emërtoni objektin dhe një komandë që e tregon, nuk e keni përcaktuar kushtin që po përpiqeni të prisni.

Përcaktoni gjithashtu si niset ky instancë OpenVPN. Një tunel i menaxhuar nga GUI dhe një tunel i menaxhuar nga shërbimi kanë cikle jete nisjeje të ndryshme, dhe emri i shërbimit duhet të vijë nga makina përpara jush, jo nga një shembull i shkruar për një instalues tjetër. Listoni kandidatët në vend që të mbështeteni në një emër të kujtuar.

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

Lexoni zinxhirin e varësive përpara se t'i shtoni diçka

Menaxheri i Kontrollit të Shërbimeve raporton gjendje si START_PENDING dhe RUNNING, dhe SERVICE_STATUS reference përcakton saktësisht çfarë do të thotë secila fushë. Asnjë prej këtyre gjendjeve nuk premton se një palë, një emër DNS ose një aplikacion në rrjedhën e poshtme janë të arritshëm. Kjo hendek është e gjithë arsyeja pse ky dështim i mbijeton një varësie të konfiguruar saktë.

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

Rreshti DEPENDENCIES nga sc.exe qc është lista që duhet të ruani, sepse sc.exe config RemoteAccess depend= zëvendëson të gjithë listën në vend që t'i shtojë asaj. Heqja e një parakushti të palidhur gjatë shtimit të një shërbimi VPN krijon një defekt të dytë që shfaqet në një nisje tjetër, dhe është shumë më e vështirë për t'u diagnostikuar sesa origjinali. Kopjoni listën ekzistuese në regjistrin tuaj të ndryshimeve përpara se ta prekni.

Varësitë ndryshojnë edhe sjelljen në fikje, sepse ndalimi i një parakushti ndalon shërbimet që varen prej tij. Kontrolloni çfarë ndodh gjatë mirëmbajtjes përpara se të lidhni RRAS me diçka që riniset shpesh.

Kushtëzoni rinisjen me një kusht, jo me një kohëmatës

Një pritje fikse supozon se tuneli do të jetë gjithmonë gati brenda atij dritareje, dhe pikërisht ky supozim dështon në nisjen kur një certifikatë është e ngadaltë ose një lidhje është jashtë. Kontrolloni vetë burimin, me një afat, dhe lëreni kontrollin të vendosë nëse një rinisje është fare e nevojshme.

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'

Një detyrë e planifikuar në nisje që kryen ato kontrolle dhe rinis RRAS vetëm kur përshtatësi ose rruga ende mungojnë është e kufizuar, e auditueshme dhe e lehtë për t'u hequr. Alternativa, rinisja e RRAS në çdo rilidhje, ndërpret sesione të shëndetshme dhe e kthen një lidhje të paqëndrueshme në një lak rinisjesh. Ai lak është më i keq se defekti origjinal, sepse tani prek përdorues që ishin mirë.

Jepini kontrollit një pritje maksimale që përputhet me kohën që tuneli merr në mënyrë të arsyeshme në harduerin tuaj, dhe bëni detyrën të dalë me një status jo zero kur dorëzohet. Një detyrë e heshtur që thjesht ndalon së provuari nuk dallohet nga një që pati sukses.

Regjistroni tranzicionin në mënyrë që nisja tjetër të shpjegohet vetë

Regjistroni tre vulë kohore në të njëjtin rresht: kur shërbimi i varësisë arriti RUNNING, kur u shfaq burimi i kërkuar, dhe kur RRAS më në fund e pranoi. Ai një rresht i vetëm i përgjigjet pyetjes që do të bëjë inxhinieri tjetër, dhe prodhimi i tij pothuajse nuk kushton asgjë. Pa të, hetimi tjetër nis nga të njëjtat hamendje si ky.

Ndaloni automatizimin pas një numri të caktuar tentativash dhe raportoni një dështim në vend që të riprovoni përgjithmonë. Një nisje që përfundon me një mesazh të qartë „burimi nuk u shfaq kurrë“ vlen më shumë se një që vazhdon të rinisë një shërbim në errësirë. Kur shfaqet ai mesazh, emri i burimit që shënuat në seksionin e dytë është ai që do të kërkojë personi tjetër.