OpenVPN: ബൂട്ടിൽ ലോക്കൽ ബൈൻഡ് പരാജയപ്പെടുന്നു — കാത്തിരിക്കണോ വീണ്ടും ശ്രമിക്കണോ
ലോക്കൽ വിലാസം ഇപ്പോഴും ഉയർന്നിട്ടില്ലെങ്കിൽ OpenVPN-ന് ബൈൻഡ് ചെയ്യാനാകില്ല. പരിമിതമായ കാത്തിരിപ്പിനെ റീസ്റ്റാർട്ട് നയവുമായി താരതമ്യം ചെയ്യുക, network-online.target എന്തുകൊണ്ട് ഉറപ്പല്ലെന്ന് കാണുക.
ബൂട്ടിൽ ആരംഭിക്കാത്ത OpenVPN സെർവറിന് രണ്ട് പരിഹാരങ്ങൾ നിർദ്ദേശിക്കപ്പെടുന്നു: വിലാസത്തിനായി കാത്തിരിക്കുക, അല്ലെങ്കിൽ ബൈൻഡ് വിജയിക്കുന്നതുവരെ സേവനം വീണ്ടും ശ്രമിക്കാൻ അനുവദിക്കുക. രണ്ടും ഒരേ ലക്ഷണത്തെ വ്യത്യസ്ത പരാജയ സ്വഭാവത്തോടെ കൈകാര്യം ചെയ്യുന്നു. കാത്തിരിപ്പ് ഒരു നിർദ്ദിഷ്ട മുൻവ്യവസ്ഥ എൻകോഡ് ചെയ്യുന്നു, അത് ഇല്ലാത്തപ്പോൾ ഉച്ചത്തിൽ പരാജയപ്പെടുന്നു; വീണ്ടും ശ്രമിക്കൽ മുൻവ്യവസ്ഥ മറച്ചുവച്ച് ശ്രമം തുടരുന്നു. ഏതാണ് നിങ്ങളുടെ യൂണിറ്റിൽ വേണ്ടത് എന്നത് ആ വിലാസം രൂപകൽപ്പന ചെയ്ത ആശ്രിതത്വമാണോ സമയത്തിന്റെ യാദൃച്ഛികതയാണോ എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
രണ്ടും ഒരു നിശ്ചിത സ്ലീപ്പിനേക്കാൾ നല്ലതാണ്, അത് ഒന്നിനുമായി കാത്തിരിക്കുന്നില്ല, എന്തിനായി കാത്തിരുന്നു എന്ന് റിപ്പോർട്ടും ചെയ്യുന്നില്ല.
local ഓപ്ഷൻ യഥാർത്ഥത്തിൽ ആവശ്യപ്പെടുന്നത്
local ഡീമൺ തന്റെ socket ബൈൻഡ് ചെയ്യുന്ന വിലാസത്തെ പേരിടുന്നു, ഇപ്പോഴും നിലവിലില്ലാത്ത ഒരു വിലാസത്തിലേക്ക് ബൈൻഡ് ചെയ്യുന്നത് ആവശ്യപ്പെട്ട വിലാസത്തെക്കുറിച്ചുള്ള പിശകോടെ ഉടൻ പരാജയപ്പെടുന്നു. ഓപ്ഷൻ ഇല്ലാത്തപ്പോൾ ഡീമൺ എല്ലാ വിലാസങ്ങളിലും കേൾക്കുന്നു, അതുകൊണ്ടാണ് ഇന്റർഫേസ് ഇപ്പോഴും ഉയർന്നിട്ടില്ലാത്ത യന്ത്രത്തിൽ അതേ പ്രൊഫൈൽ പ്രവർത്തിക്കുന്നത്: നിങ്ങൾ പേരിട്ട ഒരു വിലാസത്തിനുപകരം അത് എല്ലായിടത്തും കേൾക്കുന്നു. ആ വ്യത്യാസമാണ് മുഴുവൻ പരാജയവും, റീബൂട്ട് വരെ അത് അദൃശ്യമായി തുടരുന്നു.
ഇന്റർഫേസ് പൊതുവായ അർത്ഥത്തിൽ ഉയർന്നിരിക്കണം എന്നല്ല ആവശ്യകത. ബൈൻഡിന്റെ നിമിഷത്തിൽ വിലാസം ശരിയായ ഇന്റർഫേസിന് അനുവദിച്ചിരിക്കണം, അത് അതേ ഡീമൺ പിന്നീട് സൃഷ്ടിക്കുന്ന ടണലല്ല, അടിസ്ഥാന ഇന്റർഫേസ് ആയിരിക്കണം. ലോഗിൻ കഴിഞ്ഞ് കുറച്ച് മിനിറ്റുകൾക്ക് ശേഷം നടത്തുന്ന പരിശോധന ബൂട്ട് ക്രമത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.
വിലാസത്തിനായി കാത്തിരിക്കുക അല്ലെങ്കിൽ ബൈൻഡ് വീണ്ടും ശ്രമിക്കുക
കാത്തിരിപ്പ് എന്നാൽ വിലാസം പ്രത്യക്ഷപ്പെടുന്നതുവരെ അന്വേഷിക്കുന്ന ExecStartPre ആണ്, പരിമിതമായ ശ്രമങ്ങളും സമയം തീരുമ്പോൾ പൂജ്യമല്ലാത്ത എക്സിറ്റും ഉള്ളത്. വീണ്ടും ശ്രമിക്കൽ എന്നാൽ പ്രധാന പ്രക്രിയ പരാജയപ്പെടാൻ അനുവദിച്ച് സേവന മാനേജരോട് അത് വീണ്ടും ആരംഭിക്കാൻ ആവശ്യപ്പെടുന്നത്, ഉദാഹരണത്തിന് Restart=on-failure RestartSec=5-മായി. ആദ്യത്തേത് കാണാത്ത മുൻവ്യവസ്ഥയെ പരാജയപ്പെട്ട യൂണിറ്റായി റിപ്പോർട്ട് ചെയ്യുന്നു, രണ്ടാമത്തേത് അതിനെ ഒടുവിൽ നിലയ്ക്കുന്ന റീസ്റ്റാർട്ടുകളുടെ പരമ്പരയായി റിപ്പോർട്ട് ചെയ്യുന്നു; ഇത് ജേണലിൽ കൂടുതൽ ബഹളമാണ്, പക്ഷേ നിങ്ങൾക്ക് പ്രവചിക്കാനാകാത്ത കാരണങ്ങളാൽ വൈകി എത്തുന്ന വിലാസത്തെ അതിജീവിക്കുന്നു.
വിലാസം രൂപകൽപ്പന ചെയ്ത ആശ്രിതത്വമാണെങ്കിൽ കാത്തിരിപ്പിന് മുൻഗണന നൽകുക, വിലാസം സാധാരണയായി പ്രത്യക്ഷപ്പെടുന്നതും എന്നാൽ സമയം മാറുന്നതുമാണെങ്കിൽ വീണ്ടും ശ്രമിക്കലിന്. രണ്ടും കൂട്ടിച്ചേർക്കുന്നത് ന്യായമാണ്: പരിമിതമായ കാത്തിരിപ്പ് സാധാരണ കേസും റീസ്റ്റാർട്ട് നയം അപവാദവും ഉൾക്കൊള്ളുന്നു. രണ്ടും ചെയ്യാൻ പാടില്ലാത്തത് എന്നെന്നും പ്രവർത്തിക്കുക എന്നതാണ്, കാരണം അനിശ്ചിതമായി വീണ്ടും ശ്രമിക്കുന്ന യൂണിറ്റ് തെറ്റായ കോൺഫിഗറേഷൻ റിപ്പോർട്ട് ചെയ്യുന്നതിനുപകരം മറയ്ക്കുന്നു.
network-online.target മതിയാകാത്തത് എന്തുകൊണ്ട്
network-online.target സജീവ നെറ്റ്വർക്ക് നടപ്പാക്കൽ online എന്ന് അർത്ഥമാക്കുന്നത് വാഗ്ദാനം ചെയ്യുന്നു, അതിൽ കൂടുതലില്ല. systemd-networkd-നൊപ്പം systemd-networkd-wait-online ആ ലക്ഷ്യം എപ്പോൾ എത്തുന്നു എന്ന് തീരുമാനിക്കുന്നു, അതിന്റെ സ്ഥിരസ്ഥിതി online ധാരണ നിങ്ങളുടെ നിർദ്ദിഷ്ട വിലാസം നിലവിൽ വരുന്നതിന് മുമ്പ് തൃപ്തിപ്പെടുത്താം. NetworkManager-ന് കീഴിൽ wait-online സേവനം സ്വന്തം നിയമങ്ങൾ പ്രയോഗിക്കുന്നു. ലക്ഷ്യത്തിന് ശേഷം ക്രമീകരിക്കുന്നത് ആരോഗ്യകരമായ അടിസ്ഥാനരേഖയാണ്, ഒരു വിലാസമോ DNS ഉത്തരമോ ദൂരസ്ഥ പങ്കാളിയോ തയ്യാറാണെന്ന ഉറപ്പല്ല.
അതേ യുക്തി സാധാരണ ബദലുകളെ ഒഴിവാക്കുന്നു. ഡെസ്ക്ടോപ്പ് ഓട്ടോസ്റ്റാർട്ട് എൻട്രി സെർവറിൽ ഒരിക്കലും തുറക്കാനിടയില്ലാത്ത ഒരു ഉപയോക്തൃ സെഷനായി കാത്തിരിക്കുന്നു, കാലതാമസമുള്ള cron കമാൻഡ് പ്രത്യക്ഷപ്പെടുമെന്ന് പ്രതീക്ഷിച്ച വിഭവത്തിന്റെ പേര് പറയാതെ കഴിഞ്ഞ സമയം കൂട്ടിച്ചേർക്കുന്നു. രണ്ടും മാസങ്ങളോളം വിജയകരമായി തോന്നി പിന്നീട് പ്രധാനമായ ഒരേയൊരു ബൂട്ടിൽ പരാജയപ്പെടാം.
തണുത്ത ബൂട്ടിന് ശേഷം ബൈൻഡിംഗ് പരിശോധിക്കുക
സേവന റീസ്റ്റാർട്ടിന് പകരം യഥാർത്ഥ തണുത്ത ബൂട്ട് ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക, കാരണം റീസ്റ്റാർട്ട് ബൂട്ട് ക്രമം സൃഷ്ടിക്കേണ്ടിയിരുന്ന വിലാസം പിന്തുടരുന്നു. ബൂട്ടിന് ശേഷം ss -lntp അല്ലെങ്കിൽ ss -lunp ഓരോ ലിസണറും യഥാർത്ഥത്തിൽ ബൈൻഡ് ചെയ്ത ലോക്കൽ വിലാസം കാണിക്കുന്നു, journalctl -b -u openvpn-server@server ആദ്യ ശ്രമം പരാജയപ്പെട്ടോ എന്ന് കാണിക്കുന്നു. ബൈൻഡ് ചെയ്ത വിലാസം പ്രൊഫൈലിലേതുമായി താരതമ്യം ചെയ്യുക, തുടർന്ന് നെറ്റ്വർക്ക് വീണ്ടും കണക്റ്റ് ചെയ്ത ശേഷം താരതമ്യം ആവർത്തിക്കുക.
പ്രൊഫൈലിന് ഒരിക്കലും സ്ഥിരമായ വിലാസം ആവശ്യമില്ലായിരുന്നെങ്കിൽ, local നീക്കം ചെയ്യുന്നത് സാധുവായ ലളിതവൽക്കരണമാണ്, പക്ഷേ അത് ട്രബിൾഷൂട്ടിംഗ് ശീലമല്ലാതെ സുരക്ഷാ തീരുമാനമാക്കുക.
ലിസണർ വിപുലീകരിക്കുന്നത് ആർക്ക് അതിൽ എത്താനാകും എന്നത് മാറ്റുന്നു, അതിനാൽ ആ മാറ്റം അതിനെ നിയന്ത്രിക്കേണ്ടിയിരുന്ന ഫയർവാൾ നയവുമായി ചേർക്കുക. ഓരോ ഇന്റർഫേസിലും വിശ്വസനീയമായി ആരംഭിക്കുന്ന സേവനം യഥാർത്ഥ പ്രശ്നം പരിഹരിച്ചിട്ടില്ല; അത് പ്രശ്നത്തെ നെറ്റ്വർക്കിന്റെ അരികിലേക്ക് മാറ്റി.