സൈറ്റ്-ടു-സൈറ്റ് VPN-നുള്ളിൽ NAT അതിന്റെ സ്ഥാനം നേടുന്നത് എപ്പോൾ
വിവർത്തനം ഓവർലാപ്പിംഗ് പ്രിഫിക്സിനെയോ ഏകപക്ഷീയമായ റിട്ടേൺ പാതയെയോ രക്ഷിക്കാം, പക്ഷേ ഓരോ നയവും കാണുന്ന വിലാസങ്ങളെ അത് മാറ്റുന്നു. മാപ്പിംഗ് വ്യക്തമായി രൂപകൽപ്പന ചെയ്യുക.
രണ്ട് സൈറ്റുകളും ഒരേ സ്വകാര്യ ശ്രേണി ഉപയോഗിക്കുന്നു, ടണൽ ഉയരുന്നു, പക്ഷേ അതിലൂടെ ഉപയോഗപ്രദമായ ഒന്നും കടക്കുന്നില്ല. വിവർത്തനമാണ് സാധാരണ ഉത്തരം, അത് യഥാർത്ഥ ഉത്തരവുമാണ്: അകലെയുള്ള വശത്തിന് മറ്റൊരു ശ്രേണി കാണിച്ചാൽ ഒരു ഓവർലാപ്പോ മറ്റ് നെറ്റ്വർക്കിന് റൂട്ട് ചെയ്യാൻ കഴിയാത്ത റിട്ടേൺ പാതയോ പരിഹരിക്കാം. വിട്ടുപോകുന്ന ഭാഗം, വിവർത്തനം തുടർന്നുള്ള ഓരോ തീരുമാനവും കാണുന്ന വിലാസങ്ങളെ മാറ്റുന്നു എന്നതാണ്. ഇതിനെ രേഖപ്പെടുത്തിയ മാപ്പിംഗിനൊപ്പം പ്രമാണീകരിച്ച ഡിസൈൻ തീരുമാനമായി കാണുക, പിംഗ് വിജയിക്കുന്നതുവരെ ചേർക്കുന്ന നിയമമായി അല്ല.
ഏത് വിലാസമാണ് വീണ്ടും എഴുതുന്നതെന്ന് തീരുമാനിക്കുക
ഉറവിട വിവർത്തനം അകലെയുള്ള സേവനവും അതിന്റെ ലോഗുകളും ആരെയാണ് ക്ലയന്റായി കാണുന്നത് എന്നത് മാറ്റുന്നു, അതിനാൽ ബ്രാഞ്ച് ഹോസ്റ്റ് എത്തുമ്പോൾ ഗേറ്റ്വേ വിലാസമായി മാറുന്നു. ലക്ഷ്യസ്ഥാനമോ പ്രിഫിക്സോ ഉള്ള വിവർത്തനം പകരം അകലെയുള്ള ഒരു വിഭവത്തിന് ബദൽ വിലാസം നൽകുന്നു. ചില വിന്യാസങ്ങൾക്ക് രണ്ട് അല്ലാതെ സമാനമായ നെറ്റ്വർക്കുകളെ വേർതിരിക്കാൻ ഇരുവശത്തും ഏകോപിത വിവർത്തനം ആവശ്യമാണ്, ഏറ്റവും കൂടുതൽ ആശയക്കുഴപ്പം ഈ സംയോജനത്തിൽ നിന്നാണ് തുടങ്ങുന്നത്.
വിവർത്തനത്തിന് മുമ്പുള്ള ഉറവിടം, ആപ്ലിക്കേഷൻ വിളിക്കുന്ന ലക്ഷ്യസ്ഥാനം, ഓരോ ഗേറ്റ്വേയും പൊരുത്തപ്പെടുന്ന വിലാസ ജോടി എന്നിവ എഴുതുക. മൂന്ന് കോളങ്ങൾ മതി, മൂന്നാമത്തെ കോളമാണ് ആളുകൾ വിട്ടുകളയുന്നത്.
സെലക്ടറുകളുടെ ക്രമവും പ്രധാനമാണ്. IPsec നയത്തിന്റെ തിരഞ്ഞെടുപ്പും വിവർത്തനവും നിർവചിക്കപ്പെട്ട ഘട്ടങ്ങളിൽ സംഭവിക്കുന്നു, അതിനാൽ വിവർത്തനത്തിന് മുമ്പുള്ള വിലാസങ്ങൾക്കായി എഴുതിയ സെലക്ടർ നിങ്ങൾ അനുമാനിച്ച ഘട്ടത്തിൽ പാക്കറ്റുമായി ഒരിക്കലും പൊരുത്തപ്പെട്ടെന്ന് വരില്ല. ഇൻസ്റ്റാൾ ചെയ്ത നയം പരിശോധിക്കുക, ഇൻസ്റ്റാൾ ചെയ്യാൻ ഉദ്ദേശിച്ച നയമല്ല, ഒരു ഘടകം നിയമം സ്വീകരിച്ച് മറ്റൊന്ന് അവഗണിക്കുമ്പോൾ രണ്ടും കൃത്യമായി വേർതിരിയുന്നു:
ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat
പേലോഡും റിട്ടേൺ പാതയും പിന്തുടരുക
വേറിട്ട ബ്രാഞ്ച് ഹോസ്റ്റിന് പകരം വിവർത്തനം ചെയ്ത ഉറവിടം ലോഗ് ചെയ്യുന്ന സെർവർ യഥാർത്ഥ വിലാസവുമായി ബന്ധിപ്പിച്ച ഏത് നിയമത്തെയും റിപ്പോർട്ടിനെയും തകർക്കും. മാപ്പിംഗ് മാറ്റുന്നതിന് മുമ്പ്, ആ ഫീൽഡിൽ നിന്ന് താഴേക്ക് എന്തെങ്കിലും തീരുമാനമെടുക്കുന്നുണ്ടോ എന്ന് കണ്ടെത്തുക: ആക്സസ് ലിസ്റ്റുകൾ, ഓഡിറ്റ് റിപ്പോർട്ടുകൾ, നിരക്ക് പരിധികൾ, ലൈസൻസ് പരിശോധനകൾ. ഇവയിൽ ഓരോന്നും വിവർത്തനം പിന്നീട് വിശദീകരിക്കാനാകാത്ത പരാജയമായി പ്രത്യക്ഷപ്പെടുന്ന സ്ഥലമാണ്.
സ്വന്തം പേലോഡിൽ വിലാസങ്ങൾ വഹിക്കുന്ന പ്രോട്ടോക്കോളുകൾക്ക് പ്രത്യേക ആസൂത്രണം വേണം, കാരണം പുറം ഹെഡർ വീണ്ടും എഴുതുന്നത് ഉള്ളിലെ റഫറൻസിനെ തൊടുന്നില്ല. സജീവ FTP, SIP, ചില റിമോട്ട്-ആക്സസ് ഉൽപ്പന്നങ്ങൾ എന്നിവ ക്ലാസിക് കേസുകളാണ്, അവയെ അവഗണിക്കുന്ന ഡിസൈൻ വെബ് ട്രാഫിക്കിന് പ്രവർത്തിക്കുകയും പ്രധാനമായിരുന്ന ആപ്ലിക്കേഷനിൽ പരാജയപ്പെടുകയും ചെയ്യും.
റിട്ടേൺ ട്രാഫിക് സ്റ്റേറ്റ്ഫുൾ മാപ്പിംഗുകളെ ആശ്രയിച്ചിരിക്കുന്നു. ഗേറ്റ്വേ ഫെയിൽഓവർ ആ അവസ്ഥ നഷ്ടപ്പെടുത്താം, അസമമായ റൂട്ടിംഗ് അതിനെ ഒഴിവാക്കാം, റീസ്റ്റാർട്ട് അകലെയുള്ള വശത്ത് സെഷനുകൾ തുറന്നിരിക്കെ അത് മായ്ക്കാം. അതുകൊണ്ടാണ് ലക്ഷ്യസ്ഥാനത്ത് എത്തുന്ന അഭ്യർത്ഥനയും പൂർത്തിയാകുന്ന സെഷനും രണ്ട് വ്യത്യസ്ത സ്വീകാര്യതാ ഫലങ്ങൾ ആകുന്നത്.
സൈറ്റ് പുനർനമ്പറിംഗിനെതിരെ ഇത് തൂക്കിനോക്കുക
ഒരു സംഘർഷ സൈറ്റ് പുനർനമ്പർ ചെയ്യുന്നത് മാപ്പിംഗ് പൂർണ്ണമായി നീക്കി വിവർത്തന പട്ടികകളില്ലാതെ വായിക്കാവുന്ന വിലാസ പ്ലാൻ അവശേഷിപ്പിക്കുന്നു. ഇത് പ്രവർത്തനപരമായി ചെലവേറിയതാണ്: DNS രേഖകൾ, സ്റ്റാറ്റിക് അനുവദനങ്ങൾ, ഫയർവാൾ നിയമങ്ങൾ, പ്രമാണീകരിച്ച ഓരോ വിലാസവും ഒരുമിച്ച് മാറണം. ചെലവ് ഒരിക്കൽ, ആസൂത്രിതമായ ജാലകത്തിൽ, വ്യക്തമായ അവസാന അവസ്ഥയോടെ വരുന്നു. നിങ്ങൾ വാങ്ങുന്നത് വർഷങ്ങൾക്ക് ശേഷം തിരയൽ പട്ടികയില്ലാതെ പാക്കറ്റ് ക്യാപ്ചർ വായിക്കാനുള്ള കഴിവാണ്.
വിവർത്തനം മിക്ക ലോക്കൽ മാറ്റങ്ങളും ഒഴിവാക്കി DNS, പ്രമാണീകരണം, പ്രശ്നപരിഹാരം എന്നിവയിൽ എന്നെന്നും പരിപാലിക്കേണ്ട മാപ്പിംഗ് സൃഷ്ടിക്കുന്നു. ചെലവ് തുടർച്ചയായി വരുന്നു, ടണലിനുള്ളിൽ ഒരു പ്രിഫിക്സ് മറ്റൊരു അർത്ഥം വഹിക്കുന്നു എന്ന് പഠിക്കേണ്ട ഓരോ ഭാവി എഞ്ചിനീയറുടെ രൂപത്തിൽ.
താൽക്കാലിക കണക്ഷനോ നിങ്ങൾ നിയന്ത്രിക്കാത്ത പങ്കാളി നെറ്റ്വർക്കിനോ തുടർച്ചയായ ചെലവ് സാധാരണയായി മൂല്യവത്താണ്. നിങ്ങളുടെ ഉടമസ്ഥതയിലുള്ളതും വർഷങ്ങളോളം ഉടമസ്ഥതയിലുള്ളതുമായ രണ്ട് സൈറ്റുകൾക്ക്, കുടിയേറ്റം സത്യസന്ധമായി കണക്കാക്കുമ്പോൾ പുനർനമ്പറിംഗ് പലപ്പോഴും വിലകുറഞ്ഞ തീരുമാനമാണ്.
യഥാർത്ഥ സെഷൻ ഉപയോഗിച്ച് രണ്ട് ദിശകളും തെളിയിക്കുക
ഒരു പ്രോബിന് പകരം ആപ്ലിക്കേഷൻ സെഷൻ പരീക്ഷിക്കുക. വിജയകരമായ എക്കോ അഭ്യർത്ഥന ഒരു പ്രോട്ടോക്കോളിന്റെ ഒരു ദിശ പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, അത് സ്റ്റേറ്റ്ഫുള്ളായ എന്തിനും പരാജയപ്പെടുന്ന റിട്ടേൺ പാതയുമായി പൂർണ്ണമായി പൊരുത്തപ്പെടുന്നു. ഡിസൈനിന് പ്രചോദനം നൽകിയ സേവനം ഉപയോഗിക്കുക, അകലെയുള്ള അറ്റത്ത് അതിന്റെ ലോഗ് വായിച്ച് ഏത് ഉറവിട വിലാസമാണ് രേഖപ്പെടുത്തിയതെന്ന് കാണുക.
tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20
തുടർന്ന് മാപ്പിംഗിലൂടെ ഉദ്ദേശിച്ച സേവനങ്ങൾ മാത്രമേ ലഭ്യമാകൂ എന്ന് സ്ഥിരീകരിക്കുക. വിവർത്തനം വിലാസനിർണ്ണയം മാറ്റുന്നു, അധികാരത്തിനായി ഒന്നും ചെയ്യുന്നില്ല, അതിനാൽ എന്താണ് അനുവദനീയമെന്ന് ഫയർവാൾ നയം തന്നെ തീരുമാനിക്കുന്നു. അവ്യക്തമായ വിവർത്തന പ്രിഫിക്സിനെ ആക്സസ് നിയന്ത്രണമായി ആശ്രയിക്കുന്ന ഡിസൈനിന് ആക്സസ് നിയന്ത്രണമേ ഇല്ല.
മാപ്പിംഗ്, പരീക്ഷിച്ച സെഷൻ, ഓരോ വശവും നിരീക്ഷിച്ച വിലാസങ്ങൾ എന്നിവ രേഖപ്പെടുത്തുക. ഈ ടണൽ ഡീബഗ് ചെയ്യുന്ന അടുത്ത ആൾക്ക് കോൺഫിഗറേഷൻ ഫയലിനേക്കാൾ ആ മൂന്ന് വസ്തുതകൾ കൂടുതൽ ആവശ്യമാണ്.