RRAS startē pirms OpenVPN tuneļa gatavības palaišanas laikā

Serveris pārstartējas, OpenVPN startē, un RRAS pieceļas, kamēr adapteris vai maršruts, no kā tas ir atkarīgs, vēl nav pieejams. RRAS manuāla pārstartēšana minūti vēlāk to salabo, kas liek problēmai izskatīties atrisinātai un paslēpj īsto. Šeit tiek sajaukti divi atšķirīgi nosacījumi: priekšnosacījuma pakalpojums darbojas, un tīkla resurss, kas RRAS patiešām nepieciešams, ir kļuvis lietojams. Windows pakalpojuma atkarība var izteikt pirmo nosacījumu un nekad otro, tāpēc atkarības pievienošana bez resursa definēšanas dod sakārtotāku startu un to pašu kļūdu.

Kā simptoms izskatās aukstā palaišanā

Pazīme ir atšķirība starp aukstu startu un restartu. Aukstā startā RRAS ziņo, ka darbojas, kamēr tuneļa adapteris nav pieejams, maršruts ir pazudis vai partnera adrese vēl netiek atrisināta. Manuāls restarts pēc tam izdodas, jo tad resurss jau eksistē, un pakalpojums vienkārši nolasa no jauna pasauli, ko minūti iepriekš nevarēja redzēt. Pakalpojuma žurnāls abos gadījumos rādīs tīru startu, tāpēc notikumu skatītājs viens pats to reti izskaidro.

Fiksējiet abus stāvokļus pirms kaut ko maināt: ko RRAS ziņo palaišanas laikā un kas pastāv brīdī, kad manuālais restarts izdodas. Ja šie divi novērojumi ir identiski, starta secība nav jūsu skaidrojums un atkarība nepalīdzēs. Salīdzinājums izmaksā desmit minūtes un ietaupa nedēļu minējumu.

Atkarība, kas pievienota, pamatojoties uz „tas strādā pēc restarta“, tikai aizkavē to pašu kļūdu par laiku, kas priekšnosacījuma pakalpojumam nepieciešams, lai ziņotu RUNNING. Tā arī padara startu grūtāk saprotamu, jo secības ierobežojums tagad izskatās kā skaidrojums. Jautājiet, kuru objektu atkarība garantē un vai tas objekts ir tas, ko RRAS nevarēja redzēt.

Nosauciet resursu, ne tikai pakalpojumu

Pierakstiet konkrēto lietu, kas trūkst. Tas var būt tuneļa adapteris ar adresi, maršruts uz partnera apakštīklu, DNS atbilde vai sertifikāts, kas vēl tiek izsniegts. „VPN pakalpojums darbojas“ nav resursa apraksts, un zaļa ikona klientā arī nav. Kamēr nevarat nosaukt objektu un komandu, kas to parāda, jūs neesat definējis nosacījumu, uz kuru mēģināt gaidīt.

Noskaidrojiet arī, kā tiek palaists šis OpenVPN eksemplārs. GUI pārvaldīts tunelis un pakalpojuma pārvaldīts tunelis ir ar atšķirīgiem palaišanas dzīves cikliem, un pakalpojuma nosaukumam jānāk no mašīnas jūsu priekšā, nevis no piemēra, kas rakstīts citam instalētājam. Uzskaitiet kandidātus, nevis paļaujieties uz atcerētu nosaukumu.

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

Izlasiet atkarību ķēdi pirms kaut ko pievienojat

Pakalpojumu vadības pārvaldnieks ziņo tādus stāvokļus kā START_PENDING un RUNNING, un SERVICE_STATUS reference precīzi definē, ko nozīmē katrs lauks. Neviens no šiem stāvokļiem negarantē, ka partneris, DNS nosaukums vai lejupstraumes lietojumprogramma ir sasniedzama. Tieši šī plaisa ir viss iemesls, kāpēc šī kļūda pārdzīvo pareizi konfigurētu atkarību.

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

Rinda DEPENDENCIES no sc.exe qc ir saraksts, kas jums jāsaglabā, jo sc.exe config RemoteAccess depend= aizstāj visu sarakstu, nevis pievieno tam. Nesaistīta priekšnosacījuma izlaišana, pievienojot VPN pakalpojumu, rada otru defektu, kas parādās citā palaišanā, un to ir daudz grūtāk diagnosticēt nekā sākotnējo. Nokopējiet esošo sarakstu savā izmaiņu ierakstā, pirms tam pieskaraties.

Atkarības maina arī izslēgšanas uzvedību, jo priekšnosacījuma apturēšana aptur pakalpojumus, kas no tā atkarīgi. Pārbaudiet, kas notiek apkopē, pirms pievienojat RRAS kaut kam, kas bieži restartējas.

Piesaistiet restartu nosacījumam, nevis taimerim

Fiksēta gaidīšana pieņem, ka tunelis vienmēr būs gatavs šajā logā, un tieši šis pieņēmums neizdodas palaišanā, kad sertifikāts ir lēns vai saite ir pazudusi. Pārbaudiet pašu resursu ar termiņu un ļaujiet pārbaudei izlemt, vai restarts vispār ir nepieciešams.

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'

Palaišanas laikā izpildīts plānots uzdevums, kas veic šīs pārbaudes un pārstartē RRAS tikai tad, kad adapteris vai maršruts vēl nav pieejams, ir ierobežots, auditējams un viegli noņemams. Alternatīva — pārstartēt RRAS pie katras atkārtotas savienošanas — pārtrauc veselīgas sesijas un nestabilu saiti pārvērš restartu cilpā. Šī cilpa ir sliktāka par sākotnējo defektu, jo tagad skar lietotājus, kuriem viss bija kārtībā.

Dodiet pārbaudei maksimālo gaidīšanu, kas atbilst laikam, kādu tunelis jūsu aparatūrā pamatoti aizņem, un ļaujiet uzdevumam beigties ar statusu, kas nav nulle, kad tas padodas. Kluss uzdevums, kas vienkārši pārstāj mēģināt, nav atšķirams no tā, kuram izdevās.

Reģistrējiet pāreju, lai nākamā palaišana sevi izskaidrotu

Ierakstiet trīs laika zīmes vienā rindā: kad atkarības pakalpojums sasniedza RUNNING, kad parādījās nepieciešamais resurss un kad RRAS to beidzot pieņēma. Šī viena rinda atbild uz jautājumu, ko uzdos nākamais inženieris, un tās izveide gandrīz neko nemaksā. Bez tās nākamā izmeklēšana sākas no tā paša minējuma kā šī.

Pārtrauciet automatizāciju pēc noteikta mēģinājumu skaita un ziņojiet par neveiksmi, nevis mēģiniet mūžīgi. Palaišana, kas beidzas ar skaidru ziņojumu „resurss tā arī neparādījās“, ir vērtīgāka par to, kas turpina tumsā pārstartēt pakalpojumu. Kad šis ziņojums parādās, resursa nosaukums, ko pierakstījāt otrajā sadaļā, ir tas, ko meklēs nākamā persona.