നിരീക്ഷിക്കാത്ത VPN സെർവർ അപ്ഡേറ്റുകൾക്ക് പരീക്ഷിച്ച വീണ്ടെടുപ്പ് പാത വേണം
ഒരു അപ്ഡേറ്റ് സെർവറിലേക്ക് എത്താൻ നിങ്ങൾ ഉപയോഗിക്കുന്ന അതേ സേവനം തന്നെ പുനരാരംഭിച്ചേക്കാം. ഓട്ടോമേറ്റ് ചെയ്യുന്നതിന് മുൻപ് ഔട്ട്-ഓഫ്-ബാൻഡ് കൺസോളിനെ ടണൽ മാത്രമുള്ള വീണ്ടെടുപ്പ് പദ്ധതിയുമായി താരതമ്യം ചെയ്യുക.
സ്വന്തം VPN വഴി നിങ്ങൾ എത്തുന്ന സെർവറിന് നിരീക്ഷിക്കാത്ത അപ്ഡേറ്റുകൾ ന്യായമായ നയമാണ്, അതേസമയം അവ നിങ്ങൾ തന്നെ സൃഷ്ടിക്കുന്ന ഒരൊറ്റ പരാജയബിന്ദുവുമാണ്. പാക്കേജ് പ്രവർത്തനം സേവനം പുനരാരംഭിക്കുന്നു, ടണൽ വീഴുന്നു, നിങ്ങൾ ഉപയോഗിച്ചിരുന്ന ഭരണപരമായ പാത അതിനൊപ്പം അപ്രത്യക്ഷമാകുന്നു. വീണ്ടെടുപ്പിന് രണ്ട് മാതൃകകളുണ്ട്, അവ തമ്മിലുള്ള തിരഞ്ഞെടുപ്പ് ഒരു വ്യവസ്ഥയെ ആശ്രയിച്ചിരിക്കുന്നു: നിങ്ങൾക്ക് അപ്ഡേറ്റ് ചെയ്യുന്ന കാര്യത്തിലൂടെ കടന്നുപോകാത്ത പ്രവേശന പാത ഉണ്ടോ എന്ന്.
രണ്ട് വീണ്ടെടുപ്പ് മാതൃകകൾ, ഒരു നിർണായക വ്യവസ്ഥ
ആദ്യ മാതൃക അപ്ഡേറ്റിനെ വിശ്വസിക്കുന്നു, അതിനുശേഷം നിങ്ങൾക്ക് വീണ്ടും ബന്ധിപ്പിക്കാമെന്ന് അനുമാനിക്കുന്നു. VPN ഹോസ്റ്റിലേക്ക് എത്താനുള്ള പല വഴികളിലൊന്നാകുമ്പോഴും ടണലിന്റെ പരാജയം അത് രോഗനിർണയം ചെയ്യാനുള്ള കഴിവ് എടുത്തുകളയാത്തപ്പോഴും ഇത് പ്രവർത്തിക്കുന്നു. രണ്ടാം മാതൃക മുൻകൂട്ടി ഒരു സ്വതന്ത്ര പാത, സാധാരണയായി ഹോസ്റ്റിംഗ് ദാതാവിന്റെ കൺസോൾ, സ്ഥാപിക്കുന്നു, പരിപാലനം ഏറ്റവും സാധ്യതയുള്ള തകർക്കാൻ ഇടയുള്ള കാര്യമായി ടണലിനെ കണക്കാക്കുന്നു. രണ്ട് മാതൃകകളും ന്യായീകരിക്കാവുന്നതാണ്, അവയിൽ ഒന്നിന് മാത്രമേ മുൻകൂട്ടിയുള്ള ജോലി ആവശ്യമുള്ളൂ.
നിർണായക വ്യവസ്ഥ പറയാൻ എളുപ്പമാണ്, ഒഴിവാക്കാനും എളുപ്പമാണ്. യന്ത്രത്തിലേക്കുള്ള എല്ലാ ഭരണപരമായ പാതയും അപ്ഡേറ്റ് ചെയ്യുന്ന സേവനത്തിലൂടെ കടന്നുപോകുന്നെങ്കിൽ, നിങ്ങൾക്ക് വീണ്ടെടുപ്പ് മാതൃകയേ ഇല്ല, ഒരു പ്രതീക്ഷ മാത്രമുണ്ട്. മാറ്റ അവലോകനത്തിൽ അത് ഉറക്കെ പറയുക.
ആ വ്യവസ്ഥ പരിശോധിക്കാൻ പത്ത് മിനിറ്റ് എടുക്കും, അത് ആദ്യ നിരീക്ഷിക്കാത്ത അപ്ഡേറ്റിന് മുൻപ് നടക്കണം, സംഭവസമയത്തല്ല. എല്ലാം പ്രവർത്തിക്കുമ്പോൾ കൺസോൾ തുറക്കുക, ക്രെഡൻഷ്യലുകൾ സാധുവാണെന്ന് ഉറപ്പാക്കുക, വീണ്ടും അടയ്ക്കുക. കൺസോൾ നിങ്ങൾ കരുതുന്ന ഹോസ്റ്റിൽ തുറക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് രാത്രി 3 മണിക്ക് നിങ്ങൾ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ലോഗിൻ ഇപ്പോഴും പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക.
ആ അവസാന ഭാഗം കേൾക്കുന്നതിനേക്കാൾ പ്രധാനമാണ്. ആറ് മാസം മുൻപ് പാസ്വേഡ് മാറ്റിയതും ഒരിക്കലും പരിശോധിക്കാത്തതുമായ കൺസോൾ അക്കൗണ്ട് വീണ്ടെടുപ്പ് പാതയല്ല; അത് അത്തരം ഒരു പാത വിവരിക്കുന്ന രേഖയാണ്.
ബാക്കപ്പ് വീണ്ടെടുക്കാത്തത്
കോൺഫിഗറേഷൻ ആർക്കൈവ് ഫയലുകളുടെ രേഖയാണ്, അപ്ഡേറ്റ് ഫയലുകളേക്കാൾ കൂടുതൽ മാറ്റുന്നു. പാക്കേജ് നില, കെർണൽ മൊഡ്യൂളുകൾ, പ്രവർത്തനക്ഷമമാക്കിയ യൂണിറ്റ് ലിങ്കുകൾ, വേറെ ഒരു ഉപകരണം വഴി പ്രയോഗിച്ച ഫയർവാൾ നിയമങ്ങൾ എന്നിവയെല്ലാം കോൺഫിഗറേഷൻ ഡയറക്ടറിക്ക് പുറത്താണ് ജീവിക്കുന്നത്, അവയെ അവഗണിക്കുന്ന പുനഃസ്ഥാപനം കോൺഫിഗർ ചെയ്തതായി തോന്നുന്ന, ഫോർവേഡ് ചെയ്യാത്ത ഒരു യന്ത്രം സൃഷ്ടിക്കുന്നു.
| What changed | Restored by a configuration backup | Needs its own action |
|---|---|---|
| Service unit or startup ordering | Partly, if the unit file was included | Package state and enabled links |
| Kernel module or interface support | No | Kernel or module rollback, or a boot-time decision |
| Peer or device authorization | Only if the backup predates the revocation | A deliberate decision about which peers return |
| Firewall rules applied outside the config | Only if they were captured | Replaying and verifying each rule |
അധികാരപ്പെടുത്തൽ അതിന്റെ സ്വന്തം വരിക്ക് അർഹമാണ്. വിട്ടുപോയ ഉപകരണം നീക്കം ചെയ്യുന്നതിന് മുൻപ് എടുത്ത ബാക്കപ്പ് ആ ഉപകരണത്തിന്റെ പ്രവേശനം സന്തോഷത്തോടെ പുനഃസ്ഥാപിക്കും. തടസ്സസമയത്ത് അതിലേക്ക് മടങ്ങുന്നതാണ് ഒരു സംഭവം രണ്ടാകുന്ന വഴി, പുനഃസ്ഥാപന തീരുമാനം ഫയലുകളെക്കുറിച്ച് എത്ര വ്യക്തമാണോ അത്ര വ്യക്തമായി പങ്കാളികളെക്കുറിച്ചും എടുക്കണം.
റോൾബാക്കിന്റെ സംവിധാനവും പ്രധാനമാണ്. പാക്കേജ് നിയന്ത്രിക്കുന്ന ഫയലിന് മുകളിൽ പഴയ എക്സിക്യൂട്ടബിൾ പകർത്തുന്നത് പാക്കേജ് മാറ്റത്തിന്റെ പിന്തുണയുള്ള പഴയപടിയാക്കൽ അല്ല, അത് പാക്കേജ് ഡാറ്റാബേസിനെ ഫയൽസിസ്റ്റവുമായി പൊരുത്തപ്പെടാത്ത അവസ്ഥ വിവരിക്കാൻ വിടുന്നു. പാക്കേജ് മാനേജറുടെ സ്വന്തം ഡൗൺഗ്രേഡ് പാതയോ ദാതാവ് നൽകുന്ന സ്നാപ്പ്ഷോട്ടോ ഉപയോഗിക്കുക. പാക്കേജ് ഡാറ്റാബേസ് രേഖപ്പെടുത്തുന്ന ഡൗൺഗ്രേഡ് മാത്രമേ നിങ്ങൾക്ക് ആവർത്തിക്കാനാകൂ.
ഇവയൊന്നും ബാക്കപ്പുകൾക്കെതിരല്ല. ഓരോ ആർട്ടിഫാക്ടും ഏത് പാളിയെ മൂടുന്നു എന്ന് അറിയുന്നതിനാണ് ഇത്, കാരണം ഭാഗിക പുനഃസ്ഥാപനത്തിന്റെ പരാജയരീതി യഥാർത്ഥ തടസ്സത്തേക്കാൾ ആശയക്കുഴപ്പമുണ്ടാക്കുന്നതാണ്. റൺബുക്കിൽ ഓരോ ബാക്കപ്പിനും അടുത്ത് പാളി എഴുതുക.
ചെക്ക്പോയിന്റ്, അപ്ഡേറ്റ്, തുടർന്ന് പുറത്തുനിന്നുള്ള പരിശോധന
മാറ്റത്തിന് മുൻപുള്ള അവസ്ഥ പിന്നീട് താരതമ്യം ചെയ്യാനാകുന്ന രൂപത്തിൽ രേഖപ്പെടുത്തുക: ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പുകൾ, ബന്ധപ്പെട്ട സേവന യൂണിറ്റുകൾ, കേൾക്കുന്ന സോക്കറ്റുകൾ, നിലവിലെ പങ്കാളികളുടെ പട്ടിക. ലിനക്സ് ഹോസ്റ്റിൽ നാല് കമാൻഡുകൾ അതിന്റെ ഭൂരിഭാഗവും ഉൾക്കൊള്ളുന്നു.
systemctl list-units --type=service | grep -E 'openvpn|wg-quick'
ss -lunp | grep -E ':51820|:1194'
journalctl -u wg-quick@wg0 --since '-10 min'ആദ്യത്തേത് ഏതൊക്കെ യൂണിറ്റുകൾ ഉണ്ടെന്നും അവ പ്രവർത്തിക്കുന്നുണ്ടോ എന്നും കാണിക്കുന്നു, രണ്ടാമത്തേത് ശ്രോതാവ് യഥാർത്ഥത്തിൽ ബന്ധിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുന്നു, മൂന്നാമത്തേത് കഴിഞ്ഞ കുറച്ച് മിനിറ്റുകളെക്കുറിച്ചുള്ള സേവനത്തിന്റെ സ്വന്തം വിവരണം നൽകുന്നു. അവയൊന്നും ഒരു ക്ലയന്റിന് ബന്ധിപ്പിക്കാമെന്ന് തെളിയിക്കുന്നില്ല, അതിനാൽ അടുത്ത ഘട്ടം ഹോസ്റ്റിന് പുറത്ത് നടക്കുന്നു. ആ വായനകൾ നിങ്ങളുടെ താരതമ്യ അടിത്തറയായി സൂക്ഷിക്കുക.
ടണൽ ഉപയോഗിക്കാത്ത ഒരു നെറ്റ്വർക്കിൽ നിന്ന് പരിശോധിക്കുക: ഒരു അനുവദനീയ ക്ലയന്റിനെ പ്രാമാണീകരിക്കുക, ഒരു പേര് പരിഹരിക്കുക, ഒരു ഉദ്ദേശിച്ച ആപ്ലിക്കേഷനിൽ എത്തുക. ഇന്റർഫേസ് മുകളിലാണെന്ന് പറയുന്ന പ്രാദേശിക സ്റ്റാറ്റസ് വരി ഇന്റർഫേസിനെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്, റൂട്ടിംഗ്, കീകൾ അല്ലെങ്കിൽ പങ്കാളിയെ അനുവദിക്കുന്ന നയത്തെക്കുറിച്ചല്ല.
തുടർന്ന് വീണ്ടും ബന്ധിപ്പിക്കാനുള്ള പാത ബോധപൂർവം പരീക്ഷിക്കുക. സേവനം ഒരിക്കൽ പുനരാരംഭിച്ച് ടണൽ കൈയേറ്റമില്ലാതെ തിരികെ വരുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം ബൂട്ടിൽ മാത്രം ശരിയായി ആരംഭിക്കുന്ന സേവനം ഏറ്റവും മോശം നിമിഷത്തിൽ നിങ്ങളെ അമ്പരപ്പിക്കും.
അത് പരാജയപ്പെടുമ്പോൾ, പരീക്ഷിച്ച പാത ഉപയോഗിക്കുക
വീണ്ടെടുപ്പ് ക്രമം അതിശയകരമല്ല, അത് പ്രവർത്തിക്കുന്നു: സ്വതന്ത്ര പാതയിലൂടെ ഹോസ്റ്റിൽ എത്തുക, സേവനത്തിന്റെ സ്വന്തം ലോഗുകൾ വായിക്കുക, പരാജയവുമായി യോജിക്കുന്ന നിർദ്ദിഷ്ട ചെക്ക്പോയിന്റ് പുനഃസ്ഥാപിക്കുക. ഓരോ ശ്രമത്തിലും ഒരു കാര്യം മാറ്റുക, അപ്പോൾ അടുത്ത ലോഗ് വായനയ്ക്ക് അർത്ഥമുണ്ടാകും.
ബന്ധം തിരികെ കൊണ്ടുവരാൻ രേഖപ്പെടുത്താത്ത നിരവധി മാറ്റങ്ങൾ വരുത്താനുള്ള പ്രേരണയെ ചെറുക്കുക. അഞ്ച് ഒരേസമയ മാറ്റങ്ങളാൽ നന്നാക്കിയ യന്ത്രം പിന്നീട് വിശദീകരിക്കാനാവില്ല, അടുത്ത അപ്ഡേറ്റ് യഥാർത്ഥത്തിൽ ഭാരം വഹിച്ചതിനെ വീണ്ടും കൊണ്ടുവരും.
തുടർന്ന് തെളിവുകളോടെ സ്ഥിരമായ നയം തീരുമാനിക്കുക. അപ്ഡേറ്റ് ആരും രേഖപ്പെടുത്താത്ത ഒരു ആശ്രിതത്വം വെളിപ്പെടുത്തിയെങ്കിൽ, പരിഹാരം രേഖപ്പെടുത്തലും ഒരു പരിശോധനയുമാണ്, അപ്ഡേറ്റുകൾ ഓഫ് ചെയ്യലല്ല. വൃത്തിയായി പുനരാരംഭിക്കാനാവാത്ത സേവനം വെളിപ്പെടുത്തിയെങ്കിൽ, പരിഹാരം യൂണിറ്റിലാണ്, ഷെഡ്യൂളിലല്ല.
വ്യവസ്ഥയ്ക്ക് പേര് ലഭിച്ചാൽ താരതമ്യം വൃത്തിയായി പരിഹരിക്കപ്പെടും. സ്വതന്ത്ര പാത നിരീക്ഷിക്കാത്ത അപ്ഡേറ്റുകളെ കൈകാര്യം ചെയ്യാവുന്ന അപകടസാധ്യതയാക്കുന്നു. അതിന്റെ അഭാവം അതേ നയത്തെ അജ്ഞാത വീണ്ടെടുപ്പ് സമയമുള്ള ആസൂത്രിത തടസ്സമാക്കുന്നു, ഒരു ഓട്ടോമേഷനും ആ ഗണിതം മാറ്റുന്നില്ല.