റീബൂട്ടിന് ശേഷം SSH കേൾക്കുന്നില്ല: VPN വിലാസം വൈകി എത്തുന്നു

സെറ്റപ്പ് സമയത്ത് നിങ്ങൾ SSH-നെ ടണൽ വിലാസത്തിലേക്ക് ബന്ധിപ്പിക്കുന്നു, അത് പ്രവർത്തിക്കുന്നു, അടുത്ത റീബൂട്ടിന് ശേഷം ആരെങ്കിലും സേവനം സ്വമേധയാ പുനരാരംഭിക്കുന്നതുവരെ ആർക്കും ലോഗിൻ ചെയ്യാനാകില്ല. ക്രെഡൻഷ്യലുകൾ പ്രശ്നമല്ല. ഇതുവരെ നിലവിലില്ലാത്ത ഒരു വിലാസം ഡീമൺ കെർണലിനോട് ആവശ്യപ്പെട്ടു, ബൈൻഡ് പരാജയപ്പെട്ടു, സന്ദേശം ബൂട്ട് ലോഗിൽ കടന്നുപോയി. ഓതന്റിക്കേഷൻ പ്രശ്നമായി തോന്നുന്നത് യഥാർത്ഥത്തിൽ സ്റ്റാർട്ടപ്പ് ക്രമത്തിന്റെ പ്രശ്നമാണ്.

ബൈൻഡ് പിശക് യഥാർത്ഥത്തിൽ എന്ത് പറയുന്നു

കേൾക്കുന്ന സോക്കറ്റ് ആ നിമിഷത്തിൽ നിലവിലുള്ള ഒരു വിലാസത്തിൽ സൃഷ്ടിക്കണം. VPN ഇന്റർഫേസ് പിന്നീട് വരുമ്പോൾ, ടണൽ വിലാസത്തിലേക്ക് മാത്രം ബന്ധിപ്പിക്കാൻ ക്രമീകരിച്ച ഡീമണിന് പിടിക്കാൻ ഒന്നുമില്ല. കോൺഫിഗറേഷൻ വാക്യഘടനാപരമായി സാധുവായി തുടരുന്നു; പരിസ്ഥിതി തയ്യാറായിരുന്നില്ല എന്ന് മാത്രം. സ്വമേധയാ ആരംഭിച്ചതിന് ശേഷം പ്രവർത്തിക്കുന്ന സേവനം ഒരിക്കലും ബൂട്ട് പാതയിലൂടെ കടന്നുപോകുന്നില്ല, അതിനാലാണ് തകരാർ അടുത്ത റീസ്റ്റാർട്ടിൽ മാത്രം പ്രത്യക്ഷപ്പെടുന്നത്. പരാജയപ്പെട്ട ബൈൻഡിന്റെ ടൈംസ്റ്റാമ്പ് വിലാസം അനുവദിച്ച സമയവുമായി താരതമ്യം ചെയ്യുക, ക്രമം വ്യക്തമാകും.

കോൺഫിഗറേഷന്റെ സാധുതയും റൺടൈം സന്നദ്ധതയും വ്യത്യസ്ത സവിശേഷതകളാണ്. രണ്ടും പരിശോധിക്കുക, കാരണം അവയിലൊന്ന് ഒന്നും പറയാതെ പരാജയപ്പെടുന്നു.

ഏത് പ്രോസസ്സ് ആണ് പോർട്ട് ഉടമ

ഡീമൺ എപ്പോഴും ശ്രോതാവിനെ സൃഷ്ടിക്കുന്ന ഘടകമല്ല. സോക്കറ്റ് ആക്ടിവേഷൻ ആ ഉത്തരവാദിത്തം ഒരു യൂണിറ്റിലേക്ക് മാറ്റുന്നു, അപ്പോൾ ഡീമൺ പുനരാരംഭിക്കുന്നത് ഒന്നും മാറ്റുന്നില്ല.

ss -ltnp 'sport = :22'
systemctl cat ssh.socket

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

സന്നദ്ധത വ്യക്തമാക്കുക, ഉറക്കമല്ല

സ്ഥിരമായ കാലതാമസം വേഗതയേറിയ ഹാർഡ്വെയറും മന്ദഗതിയിലുള്ള നെറ്റ്വർക്കുകളും ഒരുപോലെ കൈകാര്യം ചെയ്യുന്ന ഒരു ഊഹമാണ്. പകരം ആശ്രിതത്വം പ്രകടിപ്പിക്കുക: വിലാസത്തിനായി കാത്തിരിക്കുക, പിന്നീട് ആരംഭിക്കുക.

ip -4 addr show dev tun0
systemctl edit ssh.service

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

വൃത്തിയുള്ള ബൂട്ടും വീണ്ടും ബന്ധിപ്പിക്കലും പരിശോധിക്കുക

എല്ലാം ഓൺലൈനായ ശേഷമുള്ള സ്വമേധയാ റീസ്റ്റാർട്ട് ബൂട്ട് ക്രമത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ടണൽ സ്വയമേവ ഉയരാൻ ക്രമീകരിച്ച അവസ്ഥയിൽ മെഷീൻ റീബൂട്ട് ചെയ്ത് ഇടപെടലില്ലാതെ ശ്രോതാവ് പ്രത്യക്ഷപ്പെടുന്നുണ്ടോ എന്ന് നിരീക്ഷിക്കുക.

systemctl status ssh.service
ss -ltnp 'sport = :22'

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

വിജയത്തിന്റെ മാനദണ്ഡം സ്വന്തം രേഖപ്പെടുത്തിയ ആശ്രിതത്വത്തിന് കീഴിൽ പ്രത്യക്ഷപ്പെടുന്ന ശ്രോതാവാണ്, ആരോ പുനരാരംഭിക്കാൻ ഓർത്ത ഒന്നല്ല.