റീബൂട്ടിന് ശേഷം VPN സർവറിന്റെ വീണ്ടെടുപ്പ് പരിശോധിക്കുക: ആദ്യം എന്ത് നോക്കണം

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

നാല് ഉടമകൾ, നാല് വ്യത്യസ്ത പരിശോധനകൾ

റീസ്റ്റാർട്ടിന് മുൻപ്, ടണലിനെ തിരികെ കൊണ്ടുവരേണ്ടത് എന്താണെന്ന് പേരിടുക. നിങ്ങൾ നടത്തുന്ന പരിശോധനയും പ്രയോഗിക്കുന്ന തിരുത്തലും രണ്ടും ആ ഉത്തരത്തെ ആശ്രയിച്ചിരിക്കുന്നു, സാധാരണ നാല് ഉടമകളുണ്ട്: VPN ഡീമണിനായി ഒരു systemd unit, WireGuard ഇന്റർഫേസിനായി ഒരു wg-quick ഇൻസ്റ്റൻസ് unit, ഒരു കണ്ടെയ്നർ റൺടൈം, അല്ലെങ്കിൽ ഒരു നെറ്റ്വർക്ക് മാനേജർ പ്രൊഫൈൽ. ഉടമയെ പേരിടാൻ കഴിയില്ലെങ്കിൽ, നിർത്തി അത് കണ്ടെത്തുക, കാരണം പ്രതീക്ഷിത സ്റ്റാർട്ടപ്പ് പാതയില്ലാത്ത റീബൂട്ട് പരിശോധന എന്തോ സംഭവിച്ചു എന്ന് മാത്രം പറയും.

ഓരോ ഉടമയും തന്റെ കോൺഫിഗറേഷൻ വേറെയിടത്ത് സൂക്ഷിക്കുന്നു. systemd നിയന്ത്രിക്കുന്ന OpenVPN സർവർ സ്റ്റാർട്ടപ്പിൽ അതിന്റെ കോൺഫിഗറേഷൻ വായിക്കുന്നു, അതിനാൽ ബൂട്ട് സമയത്ത് ഫയലിൽ ഉള്ളതാണ് പ്രവർത്തിക്കുന്നത്. wg-quick ഇന്റർഫേസ് അതിന്റെ വിലാസങ്ങളും റൂട്ടുകളും DNS-ഉം അതേ ഫയലിൽ നിന്ന് എടുക്കുന്നു, അതായത് ഷെല്ലിൽ നിന്ന് കൈകൊണ്ട് ഉയർത്തിയതും ഒരിക്കലും unit ആയി പ്രവർത്തനക്ഷമമാക്കാത്തതുമായ ഇന്റർഫേസ് തിരികെ വരില്ല. കണ്ടെയ്നർ അതിന്റെ എൻട്രിപോയിന്റ് തിരികെ കൊണ്ടുവരും, പക്ഷേ ഹോസ്റ്റിന്റെ firewall മാറ്റങ്ങൾ അല്ല, അവ കണ്ടെയ്നറിന് പുറത്താണെങ്കിൽ ഒഴികെ.

ആദ്യം ബേസ്‍ലൈൻ, അല്ലെങ്കിൽ ഫലത്തിന് അർത്ഥമില്ല

പ്രവർത്തിക്കുമ്പോൾ തന്നെ പ്രവർത്തനാവസ്ഥ രേഖപ്പെടുത്തുക: ടണലിലെ വിലാസങ്ങൾ, ക്ലയന്റ് സബ്നെറ്റിനുള്ള റൂട്ടുകൾ, NAT അല്ലെങ്കിൽ ഫോർവേഡിംഗ് നിയമങ്ങൾ, കേൾക്കുന്ന സോക്കറ്റ്, ഫോർവേഡിംഗ് sysctl. ip addr show wg0, ip route, nft list ruleset അല്ലെങ്കിൽ iptables-save, ss -lunp, sysctl net.ipv4.ip_forward എന്നിവ മിക്ക ഹോസ്റ്റുകളിലും മതി.

സേവനം പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് മാത്രമല്ല, അത് എങ്ങനെ സ്റ്റാർട്ട് ചെയ്യാൻ ക്രമീകരിച്ചിരിക്കുന്നു എന്നും രേഖപ്പെടുത്തുക. systemctl is-enabled wg-quick@wg0 ഉം systemctl is-active wg-quick@wg0 ഉം വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, ബൂട്ട് സമയത്ത് പ്രധാനമായത് പ്രവർത്തനക്ഷമമാക്കിയ അവസ്ഥയാണ്, systemctl(1)-ൽ വിവരിച്ചതുപോലെ. OpenVPN-ന്റെ കാര്യത്തിൽ, ഹോസ്റ്റ് ഏത് ടെംപ്ലേറ്റ് ഉപയോഗിക്കുന്നു എന്ന് പരിശോധിക്കുക, കാരണം openvpn@server ഉം openvpn-server@server ഉം വ്യത്യസ്ത ഡിഫോൾട്ടുകളുള്ള വ്യത്യസ്ത unit-കളാണ്.

റീസ്റ്റാർട്ട് നടത്തി ആദ്യ പരാജയം വായിക്കുക

നിങ്ങൾ തിരഞ്ഞെടുത്ത സമയത്ത് ബോധപൂർവ്വം റീബൂട്ട് ചെയ്യുക, ഒരു കോൺസോളോ ഓൗട്ട്-ഓഫ്-ബാൻഡ് പാതയോ തുറന്നുവെച്ച്. അന്തിമാവസ്ഥയല്ല, സംഭവങ്ങളുടെ ക്രമം നിരീക്ഷിക്കുക: ഹോസ്റ്റ് എത്താവുന്നത്, unit സജീവമായത്, ഇന്റർഫേസ് ഉള്ളത്, റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്തത്, firewall നിയമങ്ങൾ ഉള്ളത്, ശ്രോതാവ് ബന്ധിച്ചത്, ക്ലയന്റ് സ്വീകരിച്ചത്. സംഭവിക്കാത്ത ആദ്യ ഘട്ടമാണ് കണ്ടെത്തൽ; അതിനുശേഷമുള്ളതെല്ലാം ബഹളമാണ്.

ടണൽ ഉപയോഗശൂന്യമായിരിക്കുമ്പോഴും ഡീമൺ സജീവമായിരിക്കാം, അതാണ് ഏറ്റവും സാധാരണ തെറ്റായ വിജയം. unit network-online.target-ന് പകരം network.target-നായി മാത്രം കാത്തിരുന്നാൽ, നെറ്റ്വർക്ക് ഓൺലൈൻ ആകുന്നതിന് മുൻപ് സ്റ്റാർട്ടപ്പ് പൂർത്തിയാകാം. സർട്ടിഫിക്കറ്റുകൾ, കീകൾ അല്ലെങ്കിൽ CRL പോലുള്ള റഫറൻസ് ഫയലുകൾ അപ്പോൾ വായിക്കാൻ കഴിയാത്തതായിരിക്കാം, കാരണം ഒരു മൗണ്ട് അല്ലെങ്കിൽ രഹസ്യങ്ങളുടെ പാത ഇനിയും തയ്യാറല്ല. unit-ന്റെ ജേണൽ വായിക്കുന്നതുവരെ രണ്ട് പ്രശ്നങ്ങളും systemctl status-ൽ കാണില്ല.

ഹോസ്റ്റിന് പുറത്തുനിന്ന് പരീക്ഷിക്കുക. ഒരേ LAN-ലെ ഒരു ക്ലയന്റ്, ഒരു ദൂരസ്ഥ ക്ലയന്റും ഒരിക്കലും ഉപയോഗിക്കാത്ത ഒരു റൂട്ടിലൂടെ വിജയിച്ചേക്കാം, കൂടാതെ മെഷീനിലേക്കുള്ള SSH സെഷൻ ടണലിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. കണക്റ്റ് ചെയ്യുക, ആന്തരിക നാമം റിസോൾവ് ചെയ്യുക, സ്വകാര്യ വിഭവത്തിൽ എത്തുക, പിന്നീട് റദ്ദാക്കൽ അവസ്ഥയും കീകളും ഇപ്പോഴും ബാധകമാണെന്ന് ഉറപ്പാക്കാൻ ഒരിക്കൽ കൂടി കണക്റ്റ് ചെയ്യുക.

നിങ്ങളുടെ തിരുത്തൽ നിർണ്ണയിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

ടണൽ തിരികെ വന്നിട്ടും ക്ലയന്റുകൾക്ക് എങ്ങും എത്താൻ കഴിയുന്നില്ലെങ്കിൽ, പരാജയം റൗട്ടിംഗിലോ NAT സ്ഥിരതയിലോ ആണ്. ക്ലയന്റുകൾക്ക് ഹാൻഡ്ഷേക്ക് പോലും പൂർത്തിയാക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, പരാജയം ഇന്റർഫേസിലോ പ്രാമാണീകരണ വസ്തുവിലോ ആണ്. സേവനം ഒരിക്കലും സ്റ്റാർട്ട് ആകുന്നില്ലെങ്കിൽ, പരാജയം unit ഫയലിലോ അതിന്റെ ആശ്രിതത്വങ്ങളിലോ ആണ്. ഈ മൂന്ന് ശാഖകളും വ്യത്യസ്ത തിരുത്തലുകളിലേക്ക് നയിക്കുന്നു, അതുകൊണ്ടാണ് ബേസ്‍ലൈനില്ലാത്ത അന്ധമായ റീബൂട്ട് ലാഭിക്കുന്നതിനേക്കാൾ സമയം എടുക്കുന്നത്.

ക്രമീകരണത്തിന്റെ ഉടമസ്ഥതയുള്ളിടത്ത് തിരുത്തൽ നടത്തുക. ഫോർവേഡിംഗ് ഒരു sysctl drop-in-ൽ ഇടുക, NAT നിയമങ്ങൾ ബൂട്ടിൽ ലോഡ് ചെയ്യുന്ന നിയമക്കൂട്ടത്തിൽ ഇടുക, unit സ്റ്റാർട്ട് ചെയ്യുന്നതിന് പകരം പ്രവർത്തനക്ഷമമാക്കുക, ഒപ്പം unit സ്റ്റാർട്ട് ആകുന്നതിന് മുൻപ് നിലനിൽക്കുന്ന ഒരു പാതയിൽ രഹസ്യങ്ങൾ സൂക്ഷിക്കുക. unit-ലേക്ക് ഉറക്കം ചേർക്കുന്നത് ആശ്രിതത്വം പ്രഖ്യാപിക്കുന്നതിന് പകരം മറയ്ക്കുന്നു.

ഫലം runbook-ൽ രേഖപ്പെടുത്തുക

സ്വയം എന്ത് തിരികെ വന്നു, എന്ത് നിങ്ങൾക്ക് സ്റ്റാർട്ട് ചെയ്യേണ്ടിവന്നു, വിടവ് എത്രനേരം നിലനിന്നു എന്നിവ എഴുതുക. പരിശോധനയ്ക്ക് ഉപയോഗിച്ച കൃത്യമായ കമാൻഡുകൾ ഉൾപ്പെടുത്തുക, അടുത്ത വ്യക്തി പുതിയത് കണ്ടുപിടിക്കുന്നതിന് പകരം പരിശോധന ആവർത്തിക്കാൻ. ഏതെങ്കിലും ഘട്ടത്തിന് കൈകൊണ്ട് കമാൻഡ് വേണ്ടിവന്നെങ്കിൽ, ആ കമാൻഡ് കോൺഫിഗറേഷനിൽ ഉള്ളതാണ്, runbook-ൽ സ്ഥിരമായ ഘട്ടമായി അല്ല.

പിന്നീട് അടുത്ത പരിശോധന ഹോസ്റ്റിന്റെ നെറ്റ്വർക്ക് സ്റ്റാക്കിലെ അടുത്ത മാറ്റത്തിന് ശേഷമായി നിശ്ചയിക്കുക, ആറ് മാസം കഴിഞ്ഞുള്ള ഒരു കലണ്ടർ തീയതിക്കല്ല. നിങ്ങൾ പ്രതിരോധിക്കുന്ന പരാജയ മാതൃക സ്ഥിരമായി തോന്നിയ ഒരു താൽക്കാലിക കമാൻഡാണ്, അവ ആരെങ്കിലും firewall നിയമങ്ങൾ തിരുത്തുമ്പോഴോ ഒരു സേവനം പുതിയ unit-ലേക്ക് മാറ്റുമ്പോഴോ കൃത്യമായി പ്രത്യക്ഷപ്പെടുന്നു.