ബൂട്ടിൽ OpenVPN ടണൽ തയ്യാറാകുന്നതിന് മുൻപ് RRAS ആരംഭിക്കുന്നു

സെർവർ വീണ്ടും ബൂട്ട് ചെയ്യുന്നു, OpenVPN ആരംഭിക്കുന്നു, RRAS അത് ആശ്രയിക്കുന്ന അഡാപ്റ്ററോ റൂട്ടോ ഇപ്പോഴും ഇല്ലാതിരിക്കെ തന്നെ ഉയരുന്നു. ഒരു മിനിറ്റ് കഴിഞ്ഞ് RRAS കൈകൊണ്ട് പുനരാരംഭിച്ചാൽ അത് ശരിയാകുന്നു, ഇത് പ്രശ്നം പരിഹരിച്ചതായി തോന്നിപ്പിക്കുകയും യഥാർത്ഥത്തെ മറയ്ക്കുകയും ചെയ്യുന്നു. ഇവിടെ രണ്ട് വ്യത്യസ്ത വ്യവസ്ഥകൾ കൂട്ടിക്കലർത്തുന്നു: മുൻവ്യവസ്ഥാ സേവനം പ്രവർത്തിക്കുന്നു, എന്നും RRAS-ന് യഥാർത്ഥത്തിൽ ആവശ്യമായ നെറ്റ്വർക്ക് വിഭവം ഉപയോഗയോഗ്യമായി. Windows സേവന ആശ്രിതത്വത്തിന് ആദ്യ വ്യവസ്ഥ പ്രകടിപ്പിക്കാനാകും, രണ്ടാമത്തേത് ഒരിക്കലുമാകില്ല, അതിനാൽ വിഭവം നിർവചിക്കാതെ ആശ്രിതത്വം ചേർക്കുന്നത് കൂടുതൽ ചിട്ടയായ ബൂട്ടും അതേ പരാജയവും നൽകുന്നു.

തണുത്ത ബൂട്ടിൽ ലക്ഷണം എങ്ങനെ കാണാം

സൂചന തണുത്ത തുടക്കവും പുനരാരംഭവും തമ്മിലുള്ള വ്യത്യാസമാണ്. തണുത്ത തുടക്കത്തിൽ ടണൽ അഡാപ്റ്റർ ഇല്ലാതിരിക്കെ, റൂട്ട് കാണാതിരിക്കെ, അല്ലെങ്കിൽ പിയർ വിലാസം ഇപ്പോഴും പരിഹരിക്കാതിരിക്കെ RRAS താൻ പ്രവർത്തിക്കുന്നതായി റിപ്പോർട്ട് ചെയ്യുന്നു. കൈകൊണ്ടുള്ള പുനരാരംഭം പിന്നീട് വിജയിക്കുന്നത് അപ്പോഴേക്കും വിഭവം നിലവിലുള്ളതിനാലും സേവനം ഒരു മിനിറ്റ് മുൻപ് കാണാൻ കഴിയാതിരുന്ന ലോകം വീണ്ടും വായിക്കുന്നതിനാലുമാണ്. സേവന ലോഗ് രണ്ട് സന്ദർഭങ്ങളിലും വ്യക്തമായ തുടക്കം കാണിക്കും, അതിനാൽ ഇവന്റ് വ്യൂവർ മാത്രം ഇത് അപൂർവ്വമായി മാത്രം വിശദീകരിക്കുന്നു.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് രണ്ട് അവസ്ഥകളും രേഖപ്പെടുത്തുക: ബൂട്ടിൽ RRAS എന്ത് റിപ്പോർട്ട് ചെയ്യുന്നു, കൈകൊണ്ടുള്ള പുനരാരംഭം വിജയിക്കുന്ന നിമിഷത്തിൽ എന്ത് നിലവിലുണ്ട്. ഈ രണ്ട് നിരീക്ഷണങ്ങളും സമാനമാണെങ്കിൽ, തുടക്ക ക്രമം നിങ്ങളുടെ വിശദീകരണമല്ല, ആശ്രിതത്വം സഹായിക്കില്ല. ഈ താരതമ്യത്തിന് പത്ത് മിനിറ്റ് എടുക്കും, ഒരു ആഴ്ചയുടെ ഊഹം ലാഭിക്കും.

«പുനരാരംഭത്തിന് ശേഷം പ്രവർത്തിക്കുന്നു» എന്ന അടിസ്ഥാനത്തിൽ ചേർത്ത ആശ്രിതത്വം അതേ പരാജയത്തെ മുൻവ്യവസ്ഥാ സേവനം RUNNING റിപ്പോർട്ട് ചെയ്യാൻ എടുക്കുന്ന സമയത്തോളം മാത്രം നീട്ടിവെക്കുന്നു. ക്രമ നിയന്ത്രണം ഇപ്പോൾ വിശദീകരണം പോലെ തോന്നുന്നതിനാൽ അത് ബൂട്ട് മനസ്സിലാക്കാൻ കൂടുതൽ ബുദ്ധിമുട്ടാക്കുന്നു. ആശ്രിതത്വം ഏത് വസ്തുവിന് ഉറപ്പ് നൽകുന്നു, ആ വസ്തുവാണോ RRAS കാണാൻ കഴിയാതിരുന്നത് എന്ന് ചോദിക്കുക.

വിഭവത്തിന് പേരിടുക, സേവനത്തിന് മാത്രമല്ല

കാണാത്ത കൃത്യമായ കാര്യം എഴുതുക. വിലാസമുള്ള ടണൽ അഡാപ്റ്റർ, പിയർ സബ്നെറ്റിലേക്കുള്ള റൂട്ട്, DNS ഉത്തരം, അല്ലെങ്കിൽ ഇപ്പോഴും നൽകുന്ന സർട്ടിഫിക്കറ്റ് ആകാം. «VPN സേവനം പ്രവർത്തിക്കുന്നു» വിഭവ വിവരണമല്ല, ക്ലയന്റിലെ പച്ച ഐക്കണും അല്ല. വസ്തുവും അത് കാണിക്കുന്ന കമാൻഡും പേരിട്ട് പറയാൻ കഴിയുന്നതുവരെ, നിങ്ങൾ കാത്തിരിക്കാൻ ശ്രമിക്കുന്ന വ്യവസ്ഥ നിർവചിച്ചിട്ടില്ല.

ഈ OpenVPN ഇൻസ്റ്റൻസ് എങ്ങനെ ആരംഭിക്കുന്നു എന്നും നിർണ്ണയിക്കുക. GUI നിയന്ത്രിത ടണലിനും സേവന നിയന്ത്രിത ടണലിനും വ്യത്യസ്ത ബൂട്ട് ജീവിതചക്രങ്ങളുണ്ട്, സേവനത്തിന്റെ പേര് നിങ്ങളുടെ മുൻപിലുള്ള മെഷീനിൽ നിന്ന് വരണം, മറ്റൊരു ഇൻസ്റ്റാളറിനായി എഴുതിയ ഉദാഹരണത്തിൽ നിന്നല്ല. ഓർമ്മയിലുള്ള പേരിൽ വിശ്വസിക്കുന്നതിന് പകരം സ്ഥാനാർത്ഥികൾ പട്ടികപ്പെടുത്തുക.

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

ചേർക്കുന്നതിന് മുൻപ് ആശ്രിതത്വ ശൃംഖല വായിക്കുക

Service Control Manager START_PENDING, RUNNING തുടങ്ങിയ അവസ്ഥകൾ റിപ്പോർട്ട് ചെയ്യുന്നു, SERVICE_STATUS reference ഓരോ ഫീൽഡിന്റെയും അർത്ഥം കൃത്യമായി നിർവചിക്കുന്നു. ഈ അവസ്ഥകളൊന്നും പിയർ, DNS പേര്, അല്ലെങ്കിൽ താഴത്തെ അപ്ലിക്കേഷൻ എത്താവുന്നതാണെന്ന് ഉറപ്പ് നൽകുന്നില്ല. ആ വിടവാണ് ശരിയായി കോൺഫിഗർ ചെയ്ത ആശ്രിതത്വത്തിനും ഈ പരാജയം അതിജീവിക്കുന്നതിന്റെ മുഴുവൻ കാരണം.

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

sc.exe qc-ൽ നിന്നുള്ള DEPENDENCIES വരി നിങ്ങൾ സംരക്ഷിക്കേണ്ട പട്ടികയാണ്, കാരണം sc.exe config RemoteAccess depend= മുഴുവൻ പട്ടികയും മാറ്റിസ്ഥാപിക്കുന്നു, അതിൽ ചേർക്കുന്നില്ല. VPN സേവനം ചേർക്കുമ്പോൾ ബന്ധമില്ലാത്ത മുൻവ്യവസ്ഥ ഒഴിവാക്കുന്നത് മറ്റൊരു ബൂട്ടിൽ പ്രത്യക്ഷപ്പെടുന്ന രണ്ടാമത്തെ തകരാറുണ്ടാക്കുന്നു, അത് യഥാർത്ഥത്തേക്കാൾ വളരെ ബുദ്ധിമുട്ടുള്ളതാണ്. തൊടുന്നതിന് മുൻപ് നിലവിലുള്ള പട്ടിക നിങ്ങളുടെ മാറ്റരേഖയിലേക്ക് പകർത്തുക.

ആശ്രിതത്വങ്ങൾ ഷട്ട്ഡൗൺ സ്വഭാവവും മാറ്റുന്നു, കാരണം മുൻവ്യവസ്ഥ നിർത്തുന്നത് അതിനെ ആശ്രയിക്കുന്ന സേവനങ്ങളെ നിർത്തുന്നു. പതിവായി പുനരാരംഭിക്കുന്ന എന്തിലെങ്കിലും RRAS ബന്ധിപ്പിക്കുന്നതിന് മുൻപ് അറ്റകുറ്റപ്പണിയിൽ എന്ത് സംഭവിക്കുന്നു എന്ന് പരിശോധിക്കുക.

പുനരാരംഭം ടൈമറിനല്ല, ഒരു വ്യവസ്ഥയ്ക്ക് വിധേയമാക്കുക

സ്ഥിരമായ കാത്തിരിപ്പ് ടണൽ എപ്പോഴും ആ ജാലകത്തിനുള്ളിൽ തയ്യാറാകുമെന്ന് അനുമാനിക്കുന്നു, സർട്ടിഫിക്കറ്റ് മന്ദഗതിയിലുള്ളതോ ലിങ്ക് താഴെയുള്ളതോ ആയ ബൂട്ടിൽ പരാജയപ്പെടുന്നത് ആ അനുമാനമാണ്. വിഭവം തന്നെ സമയപരിധിയോടെ പരിശോധിക്കുക, പുനരാരംഭം ആവശ്യമുണ്ടോ എന്ന് പരിശോധന തീരുമാനിക്കട്ടെ.

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'

ബൂട്ടിൽ പ്രവർത്തിക്കുന്ന ഷെഡ്യൂൾ ചെയ്ത ടാസ്ക് ആ പരിശോധനകൾ നടത്തി, അഡാപ്റ്ററോ റൂട്ടോ ഇപ്പോഴും ഇല്ലാതിരിക്കുമ്പോൾ മാത്രം RRAS പുനരാരംഭിക്കുന്നത് പരിമിതവും ഓഡിറ്റ് ചെയ്യാവുന്നതും എളുപ്പത്തിൽ നീക്കാവുന്നതുമാണ്. ബദലായ ഓരോ പുനർബന്ധനത്തിലും RRAS പുനരാരംഭിക്കുന്നത് ആരോഗ്യകരമായ സെഷനുകളെ തടസ്സപ്പെടുത്തുകയും അസ്ഥിരമായ ലിങ്കിനെ പുനരാരംഭ ലൂപ്പാക്കുകയും ചെയ്യുന്നു. ആ ലൂപ്പ് യഥാർത്ഥ തകരാറിനേക്കാൾ മോശമാണ്, കാരണം ഇപ്പോൾ അത് കുഴപ്പമില്ലാതിരുന്ന ഉപയോക്താക്കളെയും ബാധിക്കുന്നു.

നിങ്ങളുടെ ഹാർഡ്വെയറിൽ ടണൽ ന്യായമായി എടുക്കുന്ന സമയവുമായി പൊരുത്തപ്പെടുന്ന പരമാവധി കാത്തിരിപ്പ് പരിശോധനയ്ക്ക് നൽകുക, കീഴടങ്ങുമ്പോൾ ടാസ്ക് പൂജ്യമല്ലാത്ത സ്ഥിതിയോടെ പുറത്തുപോകട്ടെ. ശ്രമിക്കുന്നത് നിർത്തുന്ന നിശ്ശബ്ദ ടാസ്കിനെ വിജയിച്ച ടാസ്കിൽ നിന്ന് വേർതിരിച്ചറിയാനാകില്ല.

സംക്രമണം ലോഗ് ചെയ്യുക, അടുത്ത ബൂട്ട് സ്വയം വിശദീകരിക്കട്ടെ

ഒരേ വരിയിൽ മൂന്ന് സമയമുദ്രകൾ രേഖപ്പെടുത്തുക: ആശ്രിത സേവനം RUNNING-ൽ എത്തിയപ്പോൾ, ആവശ്യമായ വിഭവം പ്രത്യക്ഷപ്പെട്ടപ്പോൾ, RRAS അത് അവസാനം സ്വീകരിച്ചപ്പോൾ. ആ ഒരു വരി അടുത്ത എൻജിനീയർ ചോദിക്കുന്ന ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, അത് നിർമ്മിക്കാൻ ഒന്നും തന്നെ ചെലവാകുന്നില്ല. അതില്ലാതെ അടുത്ത അന്വേഷണം ഈ അന്വേഷണത്തിന്റെ അതേ ഊഹത്തിൽ നിന്ന് തുടങ്ങുന്നു.

നിശ്ചിത എണ്ണം ശ്രമങ്ങൾക്ക് ശേഷം ഓട്ടോമേഷൻ നിർത്തുക, എന്നെന്നും വീണ്ടും ശ്രമിക്കുന്നതിന് പകരം പരാജയം റിപ്പോർട്ട് ചെയ്യുക. «വിഭവം ഒരിക്കലും പ്രത്യക്ഷപ്പെട്ടില്ല» എന്ന വ്യക്തമായ സന്ദേശത്തോടെ അവസാനിക്കുന്ന ബൂട്ട് ഇരുട്ടത്ത് സേവനം വീണ്ടും ആരംഭിക്കുന്ന ബൂട്ടിനേക്കാൾ മൂല്യമുള്ളതാണ്. ആ സന്ദേശം വരുമ്പോൾ, രണ്ടാം വിഭാഗത്തിൽ നിങ്ങൾ എഴുതിയ വിഭവത്തിന്റെ പേരാണ് അടുത്ത വ്യക്തി തിരയുക.