Nagsisimula ang RRAS bago maging handa ang OpenVPN tunnel sa boot

Nag-reboot ang server, nagsisimula ang OpenVPN, at bumabangon ang RRAS habang wala pa ang adapter o ruta na dinependiyahan nito. Inaayos ng manuwal na pag-restart ng RRAS makalipas ang isang minuto, kaya mukhang nalutas ang problema at natatakpan ang tunay. Dalawang magkaibang kondisyon ang napagkakamalang isa: tumatakbo ang prerequisite na serbisyo, at naging magagamit ang network resource na talagang kailangan ng RRAS. Ang dependency ng serbisyo sa Windows ay makapagpapahayag ng unang kondisyon at hindi kailanman ang pangalawa, kaya ang pagdaragdag ng isa nang hindi tinukoy ang resource ay nagbibigay ng mas maayos na boot at parehong failure.

Itsura ng sintomas sa malamig na boot

Ang palatandaan ay ang pagkakaiba ng malamig na pagsisimula at restart. Sa malamig na pagsisimula, iniuulat ng RRAS na tumatakbo ito habang wala ang tunnel adapter, nawawala ang ruta, o hindi pa nareresolba ang address ng peer. Nagtatagumpay ang manuwal na restart dahil sa oras na iyon may resource na, at binabasa lamang muli ng serbisyo ang mundong hindi nito nakita isang minuto ang nakalipas. Magpapakita ang log ng serbisyo ng malinis na pagsisimula sa dalawang kaso, kaya ang event viewer lamang ay bihirang magpaliwanag nito.

Itala ang dalawang estado bago magbago ng anuman: ano ang iniuulat ng RRAS sa boot, at ano ang umiiral sa sandaling nagtagumpay ang manuwal na restart. Kung magkapareho ang dalawang obserbasyong iyon, hindi ang boot order ang paliwanag mo at hindi makakatulong ang dependency. Ang paghahambing ay tumatagal ng sampung minuto at nakakatipid ng isang linggong hula.

Ang dependency na idinagdag batay sa «gumagana pagkatapos ng restart» ay hinihintay lamang ang parehong failure hanggang sa oras na kailangan ng prerequisite na serbisyo para mag-ulat ng RUNNING. Pinapahirap din nito ang pag-unawa sa boot, dahil ang order constraint ay mukhang paliwanag na ngayon. Itanong kung aling object ang ginagarantiyahan ng dependency at kung ang object na iyon ang hindi nakita ng RRAS.

Pangalanan ang resource, hindi lang ang serbisyo

Isulat ang konkretong bagay na kulang. Maaaring ito ay tunnel adapter na may address, ruta patungo sa peer subnet, sagot ng DNS, o certificate na ibinibigay pa lamang. Ang «tumatakbo ang VPN service» ay hindi paglalarawan ng resource, at ang berdeng icon sa client ay hindi rin. Hanggang hindi mo mapangalanan ang object at ang command na nagpapakita nito, hindi mo pa natukoy ang kondisyong sinusubukan mong hintayin.

Alamin din kung paano inilulunsad ang OpenVPN instance na ito. Ang tunnel na pinamamahalaan ng GUI at ang tunnel na pinamamahalaan ng serbisyo ay may magkaibang boot life cycle, at ang pangalan ng serbisyo ay dapat galing sa makina sa harap mo, hindi sa halimbawang isinulat para sa ibang installer. Ilista ang mga kandidato sa halip na magtiwala sa natatandaang pangalan.

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

Basahin ang dependency chain bago magdagdag

Iniuulat ng Service Control Manager ang mga estado gaya ng START_PENDING at RUNNING, at tinutukoy ng SERVICE_STATUS reference nang eksakto ang kahulugan ng bawat field. Wala sa mga estadong iyon ang nangangako na maabot ang peer, DNS name, o downstream application. Ang puwang na iyon ang buong dahilan kung bakit nakakaligtas ang failure na ito sa tamang naka-configure na dependency.

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

Ang linyang DEPENDENCIES mula sa sc.exe qc ang listahang dapat mong pangalagaan, dahil pinapalitan ng sc.exe config RemoteAccess depend= ang buong listahan sa halip na magdagdag dito. Ang pagtanggal ng walang kaugnayang prerequisite habang nagdadagdag ng VPN service ay lumilikha ng pangalawang depekto na lumilitaw sa ibang boot, at mas mahirap itong i-diagnose kaysa sa orihinal. Kopyahin ang umiiral na listahan sa iyong change record bago ito hawakan.

Binabago rin ng dependencies ang pag-uugali sa shutdown, dahil ang paghinto ng prerequisite ay humihinto sa mga serbisyong umaasa rito. Tingnan kung ano ang nangyayari sa maintenance bago ikonekta ang RRAS sa isang bagay na madalas mag-restart.

Ipako ang restart sa isang kondisyon, hindi sa timer

Ipinapalagay ng fixed wait na laging handa ang tunnel sa loob ng window na iyon, at iyon mismo ang palagay na nabigo sa boot kung saan mabagal ang certificate o down ang link. Suriin ang resource mismo, may deadline, at hayaang ang pagsusuri ang magpasya kung kailangan pa ng restart.

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'

Ang naka-iskedyul na gawain sa boot na nagsasagawa ng mga pagsusuring iyon at nagre-restart ng RRAS kapag wala pa ang adapter o ruta ay limitado, maaaring i-audit, at madaling alisin. Ang alternatibo, ang pag-restart ng RRAS sa bawat muling pagkonekta, ay nakakagambala sa malusog na session at ginagawang restart loop ang hindi matatag na link. Mas malala ang loop na iyon kaysa sa orihinal na depekto, dahil ngayon ay naaapektuhan ang mga user na maayos naman.

Bigyan ang pagsusuri ng pinakamataas na paghihintay na tumutugma sa panahong makatwirang ginugugol ng tunnel sa hardware mo, at hayaang maglabas ang gawain ng di-sero na status kapag sumuko ito. Ang tahimik na gawaing tumitigil na lamang sa pagsubok ay hindi makikilala sa isang nagtagumpay.

I-log ang transisyon upang ang susunod na boot ay magpaliwanag sa sarili nito

Itala ang tatlong timestamp sa isang linya: kung kailan naabot ng dependency service ang RUNNING, kung kailan lumitaw ang kinakailangang resource, at kung kailan ito tinanggap ng RRAS sa wakas. Ang isang linyang iyon ang sumasagot sa tanong ng susunod na engineer, at halos walang gastos ang paggawa nito. Kung wala ito, magsisimula ang susunod na imbestigasyon sa parehong hula na ito.

Itigil ang automation pagkatapos ng tinukoy na bilang ng pagtatangka at iulat ang failure sa halip na walang hanggang pagsubok. Ang boot na nagtatapos sa malinaw na mensaheng «hindi kailanman lumitaw ang resource» ay mas mahalaga kaysa sa patuloy na nagre-restart ng serbisyo sa dilim. Kapag lumitaw ang mensaheng iyon, ang pangalan ng resource na isinulat mo sa ikalawang seksyon ang hahanapin ng susunod na tao.