pfSense-ൽ OpenVPN ഫെയിൽഓവറിന്റെ മൂന്ന് തരം, മൂന്ന് സംവിധാനങ്ങൾ

pfSense-ൽ „OpenVPN failover“ കുറഞ്ഞത് മൂന്ന് ബന്ധമില്ലാത്ത രൂപകൽപ്പനകളെ ഉൾക്കൊള്ളുന്നു, ഓരോന്നിനും വേറെ സംവിധാനം വേണം. ബാക്കപ്പ് ഇന്റർനെറ്റ് ലിങ്കിലൂടെ ടണൽ ജീവനോടെ നിലനിർത്തുക, മറ്റൊരു സർവറിലേക്ക് വീണ്ടും ബന്ധിപ്പിക്കുക, LAN ട്രാഫിക് ഇതിനകം സ്ഥാപിച്ച മറ്റൊരു ടണലിലേക്ക് തിരിച്ചുവിടുക എന്നിവ ഒരേ സവിശേഷതയുടെ ഭാവഭേദങ്ങളല്ല. ഗേറ്റ്വേ ഗ്രൂപ്പ് നിർമ്മിക്കുന്നതിന് മുമ്പ് നിങ്ങൾ ഏത് തകരാറിനെതിരെ പ്രതിരോധിക്കുന്നു എന്ന് തിരഞ്ഞെടുക്കുക. അവയിൽ ഒന്ന് ശരിയാക്കുന്ന ഗ്രൂപ്പ് ബാക്കി രണ്ടിനും ഒന്നും ചെയ്യുന്നില്ല.

ഗ്രൂപ്പ് നിർമ്മിക്കുന്നതിന് മുമ്പ് തകരാറിന് പേരിടുക

തടസ്സ വേളയിൽ ശരിയായിരിക്കണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്ന വാക്യം എഴുതുക. „ടണൽ ബാക്കപ്പ് WAN വഴി വീണ്ടും ബന്ധിപ്പിക്കുന്നു“ എന്നതും „ശാഖ ഇപ്പോഴും മറ്റൊരു ടണൽ വഴി അപ്ലിക്കേഷനിൽ എത്തുന്നു“ എന്നതും വേറെ വാക്യങ്ങളാണ്. ആദ്യത്തേത് മാത്രമാണ് ഗതാഗതത്തെക്കുറിച്ച്.

പിന്നീട് അതിനെ ഒരു സംവിധാനവുമായി ബന്ധിപ്പിക്കുക. പ്രാദേശിക WAN നഷ്ടം ഇന്റർഫേസ് തിരഞ്ഞെടുപ്പിന്റെ പ്രശ്നമാണ്, മരിച്ച ദൂര അറ്റം കണക്ഷൻ പട്ടികയുടെ പ്രശ്നമാണ്, സ്ഥാപിത ടണലിനുള്ളിലെ ഉപയോഗശൂന്യമായ പാത റൂട്ടിംഗിന്റെയും നയത്തിന്റെയും പ്രശ്നമാണ്.

പ്രാദേശിക WAN: ഗതാഗതം നീക്കുക

pfSense OpenVPN ക്ലയന്റിന് പിന്തുണയുള്ള ബഹു-WAN ക്രമീകരണം യോജിച്ച ഗേറ്റ്വേ ഗ്രൂപ്പിനെ ക്ലയന്റ് ബന്ധിക്കുന്ന ഇന്റർഫേസായി തിരഞ്ഞെടുക്കുന്നു. പ്രാഥമിക കൈവിടുമ്പോൾ ബാഹ്യ കണക്ഷന് ബാക്കപ്പ് ലിങ്ക് വഴി പുറത്തുപോകാൻ ഇതാണ് അനുവദിക്കുന്നത്. സ്വയം ഇത് ആന്തരിക ട്രാഫിക് എങ്ങനെ റൂട്ട് ചെയ്യപ്പെടുന്നു എന്നത് മാറ്റുന്നില്ല.

അതേ രൂപകൽപ്പനയുടെ സർവർ വശം വേറെയാണ്. നിരവധി പൊതു വിലാസങ്ങളിലൂടെ എത്തേണ്ട OpenVPN സർവറിന് ആ ഓരോ എൻട്രിക്കും ഒരു ശ്രോതാവും ഇൻബൗണ്ട് നയവും വേണം, രണ്ട് ലിങ്കിലൂടെ ഡയൽ ചെയ്യാൻ കഴിയുന്ന ക്ലയന്റ് മാത്രമല്ല. പ്രവർത്തിക്കുന്ന ഒരു പൊതു എൻട്രി രണ്ടാമത്തേത് കോൺഫിഗർ ചെയ്തു എന്നതിന് തെളിവല്ല.

ഫോർവേഡ് ചെയ്ത LAN പാക്കറ്റുകൾക്കുള്ള നയാധിഷ്ഠിത റൂട്ടിംഗ് നിയമം പ്രാദേശികമായി സൃഷ്ടിച്ച VPN ഗതാഗത കണക്ഷനെ നീക്കുന്ന ക്രമീകരണമല്ല. ഇവ രണ്ട് വേറെ തിരയലുകളാണ്, ഒന്ന് മാറ്റുന്നത് മറ്റൊന്നിനെ മാറ്റുന്നില്ല.

ദൂര അറ്റം: മറ്റൊരു സർവർ

ഇതര remote കണക്ഷൻ പട്ടികയുടെ സവിശേഷതയാണ്. നിലവിലെ എൻട്രി പ്രതികരിക്കാത്തപ്പോൾ ക്ലയന്റ് അടുത്തത് ശ്രമിക്കുന്നു, ഇത് ഒരു നിർദ്ദിഷ്ട ഹോസ്റ്റ് വീണിരിക്കുമ്പോൾ പ്രയോജനകരമാണ്, നിങ്ങളുടെ സ്വന്തം അപ്ലിങ്ക് വീണിരിക്കുമ്പോൾ അല്ല. രണ്ട് തകരാറുകളും ഉപയോക്താവിന്റെ മേശയിൽ നിന്ന് ഒരുപോലെ കാണപ്പെടുന്നു, വേറെ തിരുത്തലുകൾ വേണം.

ഓരോ സ്ഥാനാർഥിയും യഥാർത്ഥ പകരക്കാരനായിരിക്കണം: പൊരുത്തപ്പെടുന്ന പ്രാമാണീകരണം, പൊരുത്തപ്പെടുന്ന ക്ലയന്റ് നയം, അതേ സ്വകാര്യ വിഭവങ്ങളിലേക്കുള്ള പ്രവേശനം. അതേ തകർന്ന ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് പരിഹരിക്കുന്ന രണ്ടാമത്തെ ഹോസ്റ്റ്നാമും ബാക്കപ്പല്ല. ആവശ്യമായ റൂട്ട് ഇല്ലാത്ത സർവറും അല്ല, അതിന്റെ ഹാൻഡ്ഷേക്ക് എത്ര ആരോഗ്യകരമായി കാണപ്പെട്ടാലും.

ഈ സംവിധാനം രണ്ട് ടണലുകളെ ഒരേസമയം ഫോർവേഡ് ചെയ്യുന്നതുമില്ല. ഒരു കണക്ഷന് ശേഷം മറ്റൊന്ന് ക്രമമായി വയ്ക്കുന്നു, അവയ്ക്കിടയിലുള്ള വിടവ് പ്രവർത്തിച്ചിരുന്ന എല്ലാത്തിനും കാണാം.

ടണൽ പാത: മറ്റൊരു പുറത്തുകടക്കൽ തിരഞ്ഞെടുക്കുക

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

ഈ രൂപകൽപ്പന തിരഞ്ഞെടുപ്പിനെക്കുറിച്ചാണ്, വീണ്ടെടുപ്പിനെക്കുറിച്ചല്ല. പുതിയ കണക്ഷനുകൾ രണ്ടാം ടണലിലേക്ക് നീക്കുന്നത് ആദ്യത്തിൽ ഇതിനകം സ്ഥാപിച്ച സെഷനുകളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ദൂര വശം പുതിയ ഉറവിട വിലാസം സ്വീകരിക്കുമോ എന്നതിനെക്കുറിച്ചും ഒന്നും പറയുന്നില്ല. അതിനെ വീണ്ടെടുപ്പ് സംവിധാനമായി കാണുന്നത് പ്രതീക്ഷകൾ വളരെ ഉയർത്തി വയ്ക്കുന്ന വഴിയാണ്.

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

നിരീക്ഷകർ, NAT, fail-closed നിയമം

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

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

പിന്നീട് ഒരിക്കലും WAN ഉപയോഗിക്കാൻ പാടില്ലാത്ത ട്രാഫിക്കിന് എന്ത് സംഭവിക്കും എന്ന് തീരുമാനിക്കുക. pfSense-ൽ തിരഞ്ഞെടുത്ത ഗേറ്റ്വേ വീണ നിയമങ്ങൾക്ക് നിർവചിച്ച പെരുമാറ്റമുണ്ട്, പിന്നീട് വരുന്ന വിശാല അനുമതി നിയമമോ ഡിഫോൾട്ട് റൂട്ടോ നിങ്ങളുടെ ഉദ്ദേശ്യം റദ്ദാക്കാം. തടയപ്പെട്ട ഫലം ആവശ്യകതയായി എഴുതുക, പിന്നീട് പാത ഇറക്കി അത് പരിശോധിക്കുക.

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