VPN ഫെയിൽഓവർ: തിരിച്ചുവരവ് പാത പഴയ ടണലിൽ തുടരുമ്പോൾ

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

ആദ്യം രണ്ട് അറ്റങ്ങളിലും റൂട്ടുകൾ രേഖപ്പെടുത്തുക; ഒരു സൈറ്റിൽ നിന്നുള്ള കാഴ്ച അസമമായ പാത കാണിക്കാൻ കഴിയില്ല. സമയ സമ്മർദ്ദത്തിൽ ഏറ്റവും കൂടുതൽ ഒഴിവാക്കപ്പെടുന്ന ഘട്ടവുമാണിത്.

പരിശോധനയ്ക്ക് മുൻപ് രണ്ട് സൈറ്റുകളുടെയും റൂട്ടുകൾ രേഖപ്പെടുത്തുക

ഓരോ സംരക്ഷിത പ്രിഫിക്സിനും പ്രാഥമിക റൂട്ട്, ബാക്കപ്പ് റൂട്ട്, അവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കുന്ന മുൻഗണന എന്നിവ എഴുതുക. ഓരോ VPN എൻഡ്പോയിന്റിനും പിന്നിലുള്ള LAN ഗേറ്റ്വേ ഉൾപ്പെടുത്തുക, കാരണം എൻഡ്പോയിന്റ് അപൂർവമായി മാത്രമേ അവസാന ചാട്ടമാകൂ.

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

ഇത് രണ്ട് സൈറ്റുകളിലും ചെയ്യുക. ഒരു വശത്ത് മുൻഗണനയും മറുവശത്ത് അവഗണനയും ലഭിക്കുന്ന ബാക്കപ്പ് നിങ്ങൾ ഒഴിവാക്കാൻ ശ്രമിക്കുന്ന അസമത്വം തന്നെ സൃഷ്ടിക്കുന്നു.

ഓരോ ഘട്ടത്തിലും അഭ്യർത്ഥനകളും ഉത്തരങ്ങളും നിരീക്ഷിക്കുക

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

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

പരിശോധനയ്ക്ക് ശേഷം യഥാർത്ഥ അവസ്ഥ പുനഃസ്ഥാപിച്ച് പ്രാഥമിക പാതയ്ക്ക് വീണ്ടും മുൻഗണന ഉറപ്പാക്കുക. പുനഃസ്ഥാപിച്ച പ്രാഥമിക പാതയ്ക്ക് മുൻഗണന ഇല്ലെങ്കിൽ അത് പൂർത്തിയാകാത്ത ഫെയിൽഓവർ ഡിസൈനാണ്.

ഗേറ്റ്വേ മാറുമ്പോൾ സെഷൻ അവസ്ഥ കൈകാര്യം ചെയ്യുക

ഫയർവാളുകൾക്കും NAT-നും ഒരു ഗേറ്റ്വേയിൽ കണക്ഷൻ അവസ്ഥ സൂക്ഷിക്കാം, മറ്റൊരു ഗേറ്റ്വേയിലേക്കുള്ള പാത മാറ്റം അത് കൊണ്ടുപോകുന്നില്ല. ചില ആപ്പുകൾ സ്വയം വീണ്ടും ബന്ധിപ്പിക്കുന്നു; മറ്റുള്ളവ സെഷൻ പുനഃസ്ഥാപിക്കുന്നതുവരെ പരാജയപ്പെടുന്നു. ബാക്കപ്പ് പൊതു ഉറവിടമോ വിവർത്തനം ചെയ്ത സ്വകാര്യ വിലാസമോ മാറ്റുന്നുവെങ്കിൽ, വിദൂര ആക്സസ് നിയമങ്ങളും പ്രതികരിച്ചേക്കാം. തടസ്സമില്ലാത്ത ഫെയിൽഓവർ വാഗ്ദാനം ചെയ്യുന്നതിനുപകരം പ്രതീക്ഷിക്കുന്ന സെഷൻ പുനരാരംഭം രേഖപ്പെടുത്തുക.

ആപ്പ് ആവശ്യപ്പെടുന്നിടത്ത് സ്ഥിരമായ വിലാസനിർണ്ണയം നിലനിർത്തുക. ഓരോ സെഷനും ഉറവിട വിലാസം മാറ്റുന്ന ഫെയിൽഓവർ ഡിസൈൻ ഒരു ഡിസൈൻ തിരഞ്ഞെടുപ്പാണ്, അത് രേഖപ്പെടുത്തണം. ആ തിരഞ്ഞെടുപ്പ് ഉപയോക്താക്കൾ തടസ്സം എത്രത്തോളം ശ്രദ്ധിക്കുന്നു എന്ന് നിർണ്ണയിക്കുന്നു.

പുതിയ അഭ്യർത്ഥന മാത്രമല്ല, ദീർഘ സെഷൻ നിലനിർത്തുന്ന ആപ്പും പരിശോധിക്കുക.

പ്രാഥമിക പാത പുനഃസ്ഥാപിച്ച് ഫ്ലാപ്പിംഗ് പരിശോധിക്കുക

റൂട്ട് പ്രഖ്യാപനങ്ങളോ മുൻഗണനകളോ ആന്ദോളനമില്ലാതെ സ്ഥിരപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക. ഫ്ലാപ്പിംഗ് പ്രാഥമിക പാത വ്യക്തമായ തകരാറിനേക്കാൾ കൂടുതൽ ശല്യമുണ്ടാക്കാം, കാരണം ഓരോ പരിവർത്തനവും അവസ്ഥ പുനഃസജ്ജമാക്കുന്നു.

ഗേറ്റ്വേ അഡ്മിനിസ്ട്രേഷൻ വീണ്ടെടുക്കൽ പാതയിലൂടെ എത്തിച്ചേരാവുന്നതാക്കി വയ്ക്കുക, പരിശോധന തന്നെ നിങ്ങളെ പുറത്താക്കാതിരിക്കാൻ. ഘട്ടങ്ങൾ, നിരീക്ഷിച്ച പാതകൾ, വീണ്ടെടുക്കൽ സമയം എന്നിവ രേഖപ്പെടുത്തുക; ആ രേഖയാണ് അടുത്ത ഫെയിൽഓവറിനെ പ്രവചനീയമാക്കുന്നത്. strongSwan-ന്റെ ഫോർവേഡിംഗ് കുറിപ്പുകൾ എൻഡ്പോയിന്റുകൾ Linux ഹോസ്റ്റുകളാകുമ്പോൾ ഉപകാരപ്രദമാണ്.