രണ്ട് സജീവ IPsec ടണലുകൾക്ക് ഇപ്പോഴും തിരിച്ചുവരവ് പാതയുടെ പദ്ധതി വേണം
രണ്ട് ടണലുകൾ ഒരു പദ്ധതിയല്ല. ഒരു TCP സംഭാഷണം ഒരു ഗേറ്റ്വേ ജോടിയിലൂടെ പുറത്തേക്കും മറ്റൊന്നിലൂടെ തിരികെയും പിന്തുടർന്ന്, അവസ്ഥ ആരാണ് കൈവശം വയ്ക്കുന്നതെന്ന് തീരുമാനിക്കുക.
ഒരു സൈറ്റിലെ വർക്ക്സ്റ്റേഷനിൽ ടെർമിനൽ തുറന്ന് മറ്റേ സൈറ്റിലെ സർവറിലേക്ക് കണക്റ്റ് ചെയ്യുക. ആ ഒറ്റ TCP സംഭാഷണം ഇപ്പോൾ രണ്ടിനു പകരം നാല് ഗേറ്റ്വേകൾ കടക്കണം, താൽപ്പര്യമുള്ള ഭാഗം അത് നല്ല ദിവസം പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതല്ല. താൽപ്പര്യമുള്ളത്, മുന്നോട്ടുള്ള ദിശ ഏത് ഗേറ്റ്വേ ജോടിയെ തിരഞ്ഞെടുത്തു, മറുപടി ഏത് ജോടിയെ തിരഞ്ഞെടുക്കുന്നു, അതു നടക്കുമ്പോൾ ഫ്ലോയുടെ അവസ്ഥ ആരാണ് കൈവശം വയ്ക്കുന്നത് എന്നതാണ്. റൂട്ടിംഗ് പട്ടികയിൽ ഒന്നും അത് നിങ്ങൾക്കുവേണ്ടി തീരുമാനിക്കുന്നില്ല.
റൂട്ട് വരയ്ക്കുന്നതിന് മുമ്പ് നാല് ഗേറ്റ്വേകൾ വരയ്ക്കുക
ഓരോ സൈറ്റിലും രണ്ട് സ്വതന്ത്ര VPN ഫയർവാളുകളുള്ള ഇരട്ട സജീവ രൂപകൽപ്പന, ഓരോ ദാതാവിനും ഒരു ജോടി, നിങ്ങൾക്ക് രണ്ട് ഉപയോഗയോഗ്യമായ പാതകളും അവ തകർക്കാനുള്ള മൂന്ന് വഴികളും നൽകുന്നു. എന്തെങ്കിലും കോൺഫിഗർ ചെയ്യുന്നതിന് മുമ്പ് വിലാസങ്ങൾ എഴുതുക: ഓരോ ഗേറ്റ്വേയ്ക്കും മുമ്പും ശേഷവും കാണുന്ന ക്ലയന്റ്, സർവറും അതുപോലെ, മുന്നോട്ടുള്ള അടുത്ത ഹോപ്പ്, തിരിച്ചുള്ള അടുത്ത ഹോപ്പ്.
ആ പട്ടികയാണ് രൂപകൽപ്പന. അതിനുശേഷമുള്ളതെല്ലാം ഉപകരണങ്ങൾ പട്ടികയോട് യോജിക്കുന്നുണ്ടോ എന്ന ചോദ്യമാണ്.
മുന്നോട്ടുള്ള പാത എങ്ങനെ തിരഞ്ഞെടുക്കുന്നു
തുല്യ ചെലവുള്ള ബഹുപാത റൂട്ടിംഗ് പാളി, ഹെഡർ ഫീൽഡുകൾ ഹാഷ് ചെയ്ത് ഫ്ലോകളെ അടുത്ത ഹോപ്പുകളിലേക്ക് വിതരണം ചെയ്യുന്നു, ഇത് RFC 2992 വിശദമായി വിവരിക്കുന്നു. ആ തിരഞ്ഞെടുപ്പ് പൂർണ്ണമായും അവസ്ഥാരഹിതമാകാം: അതിന് കണക്ഷൻ-ട്രാക്കിംഗ് എൻട്രി ആവശ്യമില്ല, മാറാത്ത ഫീൽഡുകളിൽ സ്ഥിരമായ ഹാഷ് മാത്രം മതി. പാതാ ഗണവും ഹാഷ് ഇൻപുട്ടുകളും സ്ഥിരമായി നിർത്തുക, എന്നാൽ ഫ്ലോയിലെ ഓരോ പാക്കറ്റും അതേ അടുത്ത ഹോപ്പ് തിരഞ്ഞെടുക്കും.
ഓരോ ഫ്ലോയ്ക്കും തിരഞ്ഞെടുക്കൽ വ്യത്യസ്ത കാലതാമസമുള്ള ലിങ്കുകളിൽ പാക്കറ്റ്-ബൈ-പാക്കറ്റ് സന്തുലനം ഉണ്ടാക്കുന്ന പുനഃക്രമീകരണം ഒഴിവാക്കുന്നു. തുല്യ റൂട്ടിംഗ് ചെലവ് എന്നാൽ തുല്യ അളന്ന കാലതാമസം എന്ന് അത് വാഗ്ദാനം ചെയ്യുന്നില്ല, കാരണം അങ്ങനെയല്ല. പാതകളുടെ ഘടന മാറുമ്പോൾ ഫ്ലോകൾ വീണ്ടും മാപ്പ് ചെയ്യപ്പെടുന്നു, അതിനാൽ തകരാർ സമയത്ത് കണക്ഷൻ നിലനിൽക്കുന്നത് പാതാ തിരഞ്ഞെടുപ്പിൽനിന്ന് വേറിട്ട ആവശ്യകതയാണ്.
തിരിച്ചുവരവ് പാതയ്ക്ക് യഥാർത്ഥത്തിൽ വേണ്ടത്
ഇവിടെ യാത്ര സമമിതമല്ലാതാകുന്നു. സ്ഥിരമായ മുന്നോട്ടുള്ള ഹാഷ്, ദൂരെയുള്ള സൈറ്റ് മറുപടിയോട് എന്ത് ചെയ്യുമെന്നതിനെക്കുറിച്ച് നിങ്ങളോട് ഒന്നും പറയുന്നില്ല. സ്വതന്ത്ര ഫയർവാൾ ഉപയോഗപ്രദമായ അവസ്ഥ നിലനിർത്താൻ കണക്ഷന്റെ രണ്ട് ദിശകളും കാണേണ്ടതുണ്ടെങ്കിൽ, അതിനെ ഒഴിവാക്കുന്ന തിരിച്ചുവരവ് പാത ഒന്നിനോടും യോജിക്കാത്ത ട്രാഫിക് അവശേഷിപ്പിക്കുന്നു. സമാന നിയമ ഗണങ്ങളുള്ള രണ്ട് പെട്ടികൾ പങ്കിട്ട അവസ്ഥയല്ല.
നടപ്പാക്കിയ ദ്വിദിശ പെരുമാറ്റം സ്ഥിരീകരിക്കുക, അല്ലെങ്കിൽ ആവശ്യമായ അതിരുകൾ സുസംഗതമായി നിലനിർത്തുന്ന വ്യക്തമായ നയം എഴുതുക. ഇവിടത്തെ ഊഹം തടസ്സ സമയത്ത്, അത് ആസ്വദിക്കാത്ത ആളുകളാൽ കണ്ടെത്തപ്പെടുന്നു.
വിവർത്തനം നിങ്ങൾക്കുവേണ്ടി തീരുമാനിക്കുന്നിടം
NAT മറ്റൊരു ഉത്തോലകമാണ്, അത് നിർബന്ധിതമല്ല, ഐച്ഛികമാണ്. പാത-നിർദ്ദിഷ്ട വിവർത്തനം ചെയ്ത ഐഡന്റിറ്റികൾക്ക് മറുപടികൾ അവസ്ഥ കൈവശം വയ്ക്കുന്ന ഗേറ്റ്വേയിലേക്ക് തിരികെ വിടാൻ കഴിയും, അത് സാധുവായ രൂപകൽപ്പനയാണ്. അവ മാപ്പിംഗുകളും തിരിച്ചുവരവ് പാതകളും ആ അവസ്ഥയുടെ ഉടമയും ചേർക്കുന്നു, അതിനാൽ ഉച്ചത്തിൽ പറയാൻ കഴിയുന്ന ആവശ്യകതയ്ക്ക് മാത്രം ഭാരം സ്വീകരിക്കുക.
ആവശ്യകത രണ്ട് പാതകളും ട്രാഫിക് വഹിക്കുകയും ഏതെങ്കിലും ഒന്ന് ദാതാവിന്റെ നഷ്ടം അതിജീവിക്കുകയും ചെയ്യുക മാത്രമാണെങ്കിൽ, സുസംഗതമായ തിരിച്ചുവരവ് റൂട്ടിംഗുള്ള സാധാരണ പ്രതി-ഫ്ലോ ബഹുപാത സാധാരണയായി ചെറിയ രൂപകൽപ്പനയാണ്.
സ്വീകാര്യത ക്രമത്തിൽ നടക്കുക
ഈ ക്രമത്തിൽ പരിശോധിച്ച് ഓരോ ഘട്ടത്തിലും വിലാസങ്ങൾ രേഖപ്പെടുത്തുക: പാത A യിൽ പുതിയ കണക്ഷനും അതിന്റെ മറുപടി പാതയും, പാത B യിൽ അതുതന്നെ, പിന്നെ ഒരു ദാതാവിന്റെ നഷ്ടം, പിന്നെ പുനഃസ്ഥാപനം. ഓരോ ഫലത്തിനും ഏത് സ്ഥാപിത ഫ്ലോകൾ നീങ്ങി, ഏതിന് വീണ്ടും കണക്റ്റ് ചെയ്യേണ്ടിവന്നു, പുതിയ ഫ്ലോകൾ പിന്നീട് എവിടെ പോയി എന്ന് കുറിക്കുക. ആദ്യം പ്രതീക്ഷിത മൂല്യം എഴുതുക, പിന്നെ അത് ക്യാപ്ചറുമായി താരതമ്യം ചെയ്യുക. രണ്ട് സ്ഥാപിത ടണലുകൾ അതിൽ ഒന്നും തെളിയിക്കുന്നില്ല.
നിങ്ങൾ എഴുതിയ പട്ടിക ക്യാപ്ചർ കാണിക്കുന്നതുമായി യോജിക്കുമ്പോൾ രൂപകൽപ്പന പൂർത്തിയാകുന്നു, രണ്ട് ടണലുകളും ഉയർന്നിരിക്കുമ്പോൾ അല്ല.