RRAS startas antaŭ ol la OpenVPN-tunelo pretas ĉe lanĉo

La servilo restartas, OpenVPN startas, kaj RRAS ekfunkcias dum la adaptilo aŭ itinero, de kiu ĝi dependas, ankoraŭ mankas. Restartigi RRAS permane unu minuton poste riparas tion, kio igas la problemon ŝajni solvita kaj kaŝas la realan. Ĉi tie konfuziĝas du malsamaj kondiĉoj: la antaŭkondiĉa servo funkcias, kaj la reta rimedo, kiun RRAS efektive bezonas, fariĝis uzebla. Windows-servodependeco povas esprimi la unuan kondiĉon kaj neniam la duan, do aldoni dependencon sen difini la rimedon donas al vi pli ordeman lanĉon kaj la saman fiaskon.

Kiel la simptomo aspektas ĉe malvarma lanĉo

La signo estas la diferenco inter malvarma starto kaj restartigo. Ĉe malvarma starto RRAS raportas sin funkcianta dum la tunela adaptilo forestas, la itinero mankas, aŭ la samtavola adreso ankoraŭ ne solviĝas. Permanenta restartigo tiam sukcesas ĉar je tiu tempo la rimedo ekzistas, kaj la servo simple relegas mondon, kiun ĝi ne povis vidi minuton pli frue. La serva protokolo montros puran starton en ambaŭ kazoj, kaj tial la eventa rigardilo sola malofte klarigas tion.

Kaptu ambaŭ statojn antaŭ ol ŝanĝi ion ajn: kion RRAS raportas ĉe lanĉo, kaj kio ekzistas en la momento, kiam la permana restartigo sukcesas. Se tiuj du observoj identas, la lanĉa ordo ne estas via klarigo kaj dependeco ne helpos. La komparo kostas dek minutojn kaj ŝparas semajnon da konjektado.

Dependeco aldonita surbaze de „ĝi funkcias post restartigo“ nur prokrastas la saman fiaskon je tiom, kiom la antaŭkondiĉa servo bezonas por raporti RUNNING. Ĝi ankaŭ malfaciligas la komprenon de la lanĉo, ĉar la ordigaj limoj nun aspektas kiel klarigo. Demandu, kiun objekton la dependeco garantias kaj ĉu tiu objekto estas la ĝusta, kiun RRAS ne povis vidi.

Nomu la rimedon, ne nur la servon

Skribu la konkretan aferon, kiu mankas. Ĝi povas esti tunela adaptilo kun adreso, itinero al samtavola reto, DNS-respondo, aŭ atestilo ankoraŭ provizata. „La VPN-servo funkcias“ ne estas rimeda priskribo, kaj nek verdan ikonon en kliento. Ĝis vi povos nomi la objekton kaj komandon, kiu montras ĝin, vi ne difinis la kondiĉon, kiun vi provas atendi.

Determinu ankaŭ, kiel ĉi tiu OpenVPN-kazo lanĉiĝas. GUI-administrata tunelo kaj servoadministrata tunelo havas malsamajn lanĉajn vivciklojn, kaj la serva nomo devas veni de la maŝino antaŭ vi, ne de ekzemplo skribita por alia instalilo. Listigu la kandidatojn anstataŭ fidi memoritan nomon.

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

Legu la dependeĉenon antaŭ ol aldoni al ĝi

La Servokontrola Administranto raportas statojn kiel START_PENDING kaj RUNNING, kaj la SERVICE_STATUS reference difinas precize, kion signifas ĉiu kampo. Neniu el tiuj statoj promesas, ke samtavolo, DNS-nomo aŭ malsupra aplikaĵo estas atingeblaj. Tiu breĉo estas la tuta kialo, ke ĉi tiu fiasko postvivas ĝuste agorditan dependecon.

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

La linio DEPENDENCIES el sc.exe qc estas la listo, kiun vi devas konservi, ĉar sc.exe config RemoteAccess depend= anstataŭigas la tutan liston anstataŭ aldoni al ĝi. Forlasi nerilatan antaŭkondiĉon dum aldono de VPN-servo kreas duan difekton, kiu aperas ĉe alia lanĉo, kaj ĝi estas multe pli malfacile diagnozebla ol la originala. Kopiu la ekzistantan liston en vian ŝanĝprotokolon antaŭ ol tuŝi ĝin.

Dependecoj ankaŭ ŝanĝas la malŝaltan konduton, ĉar haltigi antaŭkondiĉon haltigas la servojn dependajn de ĝi. Kontrolu, kio okazas dum prizorgado antaŭ ol ligi RRAS al io, kio ofte restartas.

Kondiĉigu la restartigon per kondiĉo, ne per tempigilo

Fiksa atendo supozas, ke la tunelo ĉiam pretos ene de tiu fenestro, kaj ĝuste tiu supozo fiaskas ĉe la lanĉo, kiam atestilo estas malrapida aŭ ligilo estas malaktiva. Kontrolu la rimedon mem, kun templimo, kaj lasu la kontrolon decidi, ĉu restartigo entute necesas.

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'

Planita tasko ĉe lanĉo, kiu plenumas tiujn kontrolojn kaj restartigas RRAS nur kiam la adaptilo aŭ itinero ankoraŭ mankas, estas limigita, auditebla kaj facile forigebla. La alternativo, restartigi RRAS ĉe ĉiu rekonekto, interrompas sanajn sesiojn kaj transformas malstabilan ligilon en restartigbuklon. Tiu buklo estas pli malbona ol la originala difekto, ĉar ĝi nun efikas al uzantoj, kiuj estis bone.

Donu al la kontrolo maksimuman atendon, kiu kongruas kun la tempo, kiun la tunelo racie bezonas sur via aparataro, kaj igi la taskon finiĝi per ne-nula statuso, kiam ĝi rezignas. Silenta tasko, kiu simple ĉesas provi, ne estas distingebla de tiu, kiu sukcesis.

Registru la transiron, por ke la sekva lanĉo klarigu sin mem

Registru tri tempomarkojn en la sama linio: kiam la dependa servo atingis RUNNING, kiam aperis la bezonata rimedo, kaj kiam RRAS finfine akceptis ĝin. Tiu unu linio respondas la demandon, kiun la sekva inĝeniero starigos, kaj produkti ĝin kostas preskaŭ nenion. Sen ĝi la sekva esploro komenciĝas de la sama konjektado kiel ĉi tiu.

Haltigu la aŭtomatigon post difinita nombro da provoj kaj raportu fiaskon anstataŭ reprovi eterne. Lanĉo, kiu finiĝas per klara mesaĝo „la rimedo neniam aperis“, valoras pli ol tiu, kiu daŭre restartigas servon en la mallumo. Kiam tiu mesaĝo aperos, la rimeda nomo, kiun vi skribis en la dua sekcio, estas tio, kion la sekva persono serĉos.