VPN യൂണിറ്റ് നെറ്റ്‌വർക്കിന് മുമ്പ് എന്തുകൊണ്ട് ആരംഭിച്ച് പിന്നീട് മരിക്കുന്നു

മെഷീൻ ബൂട്ട് ചെയ്യുക, ലോഗിൻ ചെയ്യുക, ടണൽ ഉയർന്ന് കുറച്ച് സെക്കൻഡുകൾ കഴിഞ്ഞ് മരിച്ചതായി അറിയുക. പ്രൊഫൈൽ കുഴപ്പമില്ലായിരുന്നു, സർട്ടിഫിക്കറ്റും കുഴപ്പമില്ലായിരുന്നു, അവശേഷിക്കുന്ന ഒരേയൊരു അടയാളം ആ ബൂട്ടിന്റെ ജേണലാണ്. സാധാരണയായി സംഭവിച്ചത് ഒരു മത്സരമാണ്: യന്ത്രത്തിന് വിലാസം ലഭിക്കുന്നതിന് മുമ്പ് തന്നെ യൂണിറ്റ് ആരംഭിച്ചു, അത് പ്രഖ്യാപിച്ച ക്രമം കാണുന്നതുപോലെയുള്ള അർത്ഥം നൽകിയില്ല. താഴെയുള്ളതെല്ലാം ആ മത്സരം തെളിവുകളിൽ നിന്ന് തെളിയിക്കുന്നതിനെയും അത് ശരിയായി അടയ്ക്കുന്നതിനെയും കുറിച്ചാണ്.

ലക്ഷ്യം ഒരു സമ്മേളന സ്ഥലമാണ്, മാനേജർ അല്ല

network-online.target നെറ്റ്‌വർക്ക് എന്താണെന്ന് അറിയില്ല. ഇത് ഒരു ഏകോപന കേന്ദ്രമാണ്, ലിങ്ക് ഉപയോഗയോഗ്യമാകുന്നതുവരെ ആരംഭം വൈകിപ്പിക്കേണ്ട സേവനം ഇത് ശേഖരിക്കുന്നു, നിർവചനം യന്ത്രത്തിന്റെ ഉടമയായ നെറ്റ്‌വർക്ക് മാനേജർക്ക് കൈമാറുന്നു. മിക്ക ഡെസ്ക്ടോപ്പുകളിലും സെർവറുകളിലും ഇതിനർത്ഥം NetworkManager അല്ലെങ്കിൽ systemd-networkd നൽകുന്ന കാത്തിരിപ്പ് സേവനമാണ്. രണ്ടും സജീവമാക്കിയില്ലെങ്കിൽ ലക്ഷ്യത്തിന് കാത്തിരിക്കാൻ ഒന്നുമില്ല, അതിനാൽ എന്തെങ്കിലും അതിനെ വലിച്ചെടുക്കുന്ന നിമിഷത്തിൽ അത് പൂർത്തിയാകുന്നു, അത് DHCP ഉത്തരം നൽകുന്നതിന് വളരെ മുമ്പായിരിക്കാം. നിങ്ങളുടെ യൂണിറ്റിലെ ക്രമ വരി സത്യസന്ധമായിരുന്നു, എന്നിട്ടും ഉപയോഗശൂന്യം.

അതിനാൽ ആദ്യ ചോദ്യം നിങ്ങളുടെ യൂണിറ്റ് എന്ത് പ്രഖ്യാപിക്കുന്നു എന്നതല്ല. ഈ യന്ത്രത്തിൽ എന്തെങ്കിലും യഥാർത്ഥത്തിൽ കാത്തിരിപ്പ് ചെയ്യുന്നുണ്ടോ എന്നതാണ്.

യൂണിറ്റ് ഫയലിന് പകരം അവസാന ബൂട്ട് വായിക്കുക

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

ആശ്രിതത്വ കാഴ്ച ഇത് സ്ഥിരീകരിക്കുന്നു. ടണൽ യൂണിറ്റിനുള്ള നിർണായക ശൃംഖലയിൽ കാത്തിരിപ്പ് സേവനം ഇല്ലെങ്കിൽ, ആ പാതയിൽ ഒന്നും ആരംഭം വൈകിപ്പിച്ചിട്ടില്ല, ലക്ഷ്യം നിങ്ങൾ അനുമാനിച്ച ജോലി ചെയ്തിട്ടില്ല. രണ്ട് കാഴ്ചകൾ, ഒരു നിഗമനം.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

കാത്തിരിപ്പ് ചേർക്കുക, തുടർന്ന് വീണ്ടും ശ്രമം

പാക്കേജ് ചെയ്ത യൂണിറ്റ് എഡിറ്റ് ചെയ്യുന്നതിന് പകരം drop-in ഉപയോഗിക്കുക, പാക്കേജ് അപ്ഡേറ്റ് മാറ്റം നിശബ്ദമായി വലിച്ചെറിയാതിരിക്കാൻ. രണ്ട് നിർദ്ദേശങ്ങൾ പ്രധാനമാണ്: യൂണിറ്റ് ലക്ഷ്യത്തിന് ശേഷം ക്രമീകരിക്കണം, ലക്ഷ്യത്തെ അതേ ഇടപാടിലേക്ക് വലിച്ചിടണം. ക്രമം മാത്രം ലക്ഷ്യത്തെ വിളിക്കുന്നില്ല; ആഗ്രഹമാണ് അത് ചെയ്യുന്നത്.

OpenVPN ക്ലൈന്റിന്റെ പാക്കേജ് ചെയ്ത യൂണിറ്റ് ഇതിനകം രണ്ടും വഹിക്കുന്നു. കൈകൊണ്ട് എഴുതിയ യൂണിറ്റുകൾ സാധാരണയായി ഒന്നോ ഒന്നും വഹിക്കുന്നില്ല, എന്തെങ്കിലും ചേർക്കുന്നതിന് മുമ്പ് ഇത് പരിശോധിക്കേണ്ടതാണ്.

[Service]
Restart=on-failure
RestartSec=15

നിശ്ചിത ഉറക്കം എന്തുകൊണ്ട് കെണിയാണ്

ExecStartPre എന്നതിനുള്ളിൽ ഉറക്കം ക്രമ തിരുത്തലായി തോന്നുന്നു, അധിക ഘട്ടങ്ങളുള്ള കാലതാമസമായി പെരുമാറുന്നു. ആരോഗ്യകരമായിരുന്നവ ഉൾപ്പെടെ ഓരോ ബൂട്ടും ഇത് മന്ദഗതിയിലാക്കുന്നു, നിങ്ങൾ തിരഞ്ഞെടുത്ത സംഖ്യയേക്കാൾ ലിങ്ക് കൂടുതൽ സമയമെടുത്താൽ ഇത് ഇപ്പോഴും തോൽക്കുന്നു.

അതിനെക്കാൾ മോശം, കാത്തിരിപ്പ് സേവനം പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് ഇത് മറയ്ക്കുന്നു, അതിനാൽ അടുത്ത പരാജയം അതേ പ്രശ്നത്തിന്റെ മറ്റൊരു സമയമായല്ല, മറിച്ച് തികച്ചും പുതിയ പ്രശ്നമായി പ്രത്യക്ഷപ്പെടുന്നു. ചെറിയ റീസ്റ്റാർട്ട് കാലതാമസമാണ് മികച്ച ഉപകരണം: ആരോഗ്യകരമായ ബൂട്ടിൽ അതിന് ചെലവില്ല, തോറ്റ മത്സരത്തെ മറ്റൊരു ശ്രമമാക്കി മാറ്റുന്നു. ഇടവേള മിതമായി നിലനിർത്തുക, യൂണിറ്റ് വിജയിക്കാൻ അനുവദിക്കുക. എന്നെന്നേക്കുമായി റീസ്റ്റാർട്ട് ചെയ്യുന്നുവെങ്കിൽ പ്രൊഫൈൽ തകർന്നിരിക്കുന്നു, എത്ര വീണ്ടും ശ്രമിച്ചാലും അത് മാറില്ല, അതിനാൽ ഇടവേള കൂട്ടുന്നതിന് പകരം ലോഗ് വായിക്കുക.

ക്രമം ശരിയായിട്ടും പേരുകൾ പരാജയപ്പെടുമ്പോൾ

ടണൽ റൂട്ടുള്ള സജീവ യൂണിറ്റ് എന്നാൽ ക്രമം അതിന്റെ ജോലി ചെയ്തു, ബാക്കിയുള്ള തകരാർ ഒരു പാളി മുകളിലാണ്. സാധാരണ രൂപം ടണലിന്റെ up സ്ക്രിപ്റ്റ് പ്രയോഗിക്കുന്ന റിസോൾവർ ക്രമീകരണമാണ്, ലിങ്കോ റിസോൾവറോ അത് നിലനിർത്താൻ തയ്യാറാകുന്നതിന് മുമ്പ്. പരാജയ സമയത്തെ റിസോൾവർ അവസ്ഥയെ ടണൽ യൂണിറ്റ് റീസ്റ്റാർട്ട് ചെയ്തതിന് ശേഷമുള്ള അവസ്ഥയുമായി താരതമ്യം ചെയ്യുക.

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