Anypoint VPN അല്ലെങ്കിൽ Transit Gateway NAT: വിവർത്തനം എവിടെ നടക്കുന്നു
Anypoint VPN സ്വയം വിലാസങ്ങൾ വിവർത്തനം ചെയ്യുന്നില്ല. NAT വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് ഫയർവാൾ PAT, AWS പ്രിഫിക്സ് മാപ്പ് അല്ലെങ്കിൽ മറ്റൊരു അറ്റാച്ച്മെന്റ് എന്നിവയിൽ തിരഞ്ഞെടുക്കുക.
മാറുന്ന വിലാസങ്ങളും അവ മാറ്റാൻ അനുവാദമുള്ള ഘടകവും പേരെടുത്ത് പറയുന്നതുവരെ ഒരു NAT ആവശ്യകത ആവശ്യകതയല്ല. MuleSoft കണക്റ്റിവിറ്റിയിൽ ആ തീരുമാനത്തിന് മൂന്ന് ഇൻപുട്ടുകളുണ്ട്: ബാക്കെൻഡിന് പലതിൽ-നിന്ന്-ഒന്നിലേക്കുള്ള പോർട്ട് വിവർത്തനം വേണോ അതോ ഒന്നിൽ-നിന്ന്-ഒന്നിലേക്കുള്ള പ്രിഫിക്സ് അപരനാമം വേണോ, നിങ്ങൾ യഥാർത്ഥത്തിൽ ഉടമസ്ഥതയുള്ള AWS അറ്റാച്ച്മെന്റിന് ആ മാപ്പിംഗ് ചെയ്യാനാകുമോ, ഒപ്പം മുഴുവൻ പാതയും വിതരണക്കാരൻ പിന്തുണയ്ക്കുന്ന സംയോജനത്തിനുള്ളിൽ തുടരുന്നുവോ. ഇവ തെറ്റിയാൽ പ്രവർത്തിക്കുന്നതും എന്നാൽ അവലോകനത്തിൽ പരാജയപ്പെടുന്നതുമായ ഒരു ലബോറട്ടറി നിങ്ങൾ നിർമ്മിക്കും.
ഒരേയൊരു സ്ഥിരതയുള്ള കാര്യം Anypoint VPN തന്നെ ഒരു വിവർത്തന ഉപകരണമല്ല എന്നതാണ്. CloudHub 2.0 ഡോക്യുമെന്റേഷൻ അവിടെ NAT അപിന്തുണയ്ക്കുന്നതായി പട്ടികപ്പെടുത്തുന്നു, അതിനാൽ ടണൽ നിങ്ങളുടെ വർക്കർ വിലാസങ്ങൾ മറയ്ക്കുമെന്ന് കരുതുന്ന ഏതൊരു രൂപകൽപ്പനയും ഇതിനകം തകർന്നിരിക്കുന്നു.
വിവർത്തനം എന്ത് ചെയ്യണമെന്ന് തീരുമാനിക്കുക
നിരവധി ആപ്ലിക്കേഷൻ വർക്കർമാർ ബാക്കെൻഡിന് മുന്നിൽ ഒരു വിലാസമായി കാണപ്പെടേണ്ടതുണ്ടെങ്കിൽ, ആവശ്യകത പങ്കിട്ട ഉറവിട വിവർത്തനമാണ്, സാധാരണയായി നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഫയർവാളിൽ സ്റ്റേറ്റ് നിലനിർത്തുന്ന SNAT അല്ലെങ്കിൽ PAT. ആ ഘടകം അംഗീകൃത പാതയിൽ ഇരിക്കണം, ഫ്ലോയുടെ മുഴുവൻ ആയുസ്സിലും അതിന്റെ അവസ്ഥ നിലനിർത്തണം, കൂടാതെ അത് വീണ്ടും എഴുതിയ ഓരോ കണക്ഷന്റെയും മടങ്ങിവരുന്ന ട്രാഫിക് കാണണം. സെഷന്റെ നടുവിൽ അവസ്ഥ നഷ്ടപ്പെടുന്നത് കണക്ഷനെ ദുർബലമാക്കുന്നില്ല; അത് അതിനെ അവസാനിപ്പിക്കുന്നു. വിവർത്തന അവസ്ഥ പങ്കിടാൻ വിസമ്മതിക്കുന്ന ഒരു ജോടി ഫയർവാളുകൾ ഫെയിൽഓവറിന് ശേഷം സ്റ്റാൻഡ്ബൈ അംഗത്തിൽ എത്തുന്ന ഓരോ സെഷനും ഉപേക്ഷിക്കും. ആ ഘടകം ഒരേസമയം ഉള്ള ഫ്ലോകൾക്കായി അളക്കുക, ത്രൂപുട്ടിനല്ല.
പകരം രണ്ട് നെറ്റ്‌വർക്കുകൾ ഓവർലാപ്പ് ചെയ്യുകയും ഓരോ ഹോസ്റ്റിനും വെവ്വേറെ അപരനാമം വേണ്ടിവരികയും ചെയ്യുന്നുവെങ്കിൽ, ആവശ്യകത അവ്യക്തതയില്ലാത്ത മാപ്പ് ചെയ്ത പ്രിഫിക്സുകൾ, പൊരുത്തപ്പെടുന്ന റൂട്ടുകൾ, മാപ്പിംഗുമായി യോജിക്കുന്ന നാമ പരിഹാരം എന്നിവയുള്ള ഒന്നിൽ-നിന്ന്-ഒന്നിലേക്കുള്ള വിലാസ പദ്ധതിയാണ്. ഓരോ വർക്കറെയും ഒരു വിലാസത്തിന് പിന്നിൽ ഒളിപ്പിക്കുന്നത് അതിന്റെ വിലകുറഞ്ഞ പതിപ്പല്ല, ഒപ്പം ഡിസൈൻ അവലോകനത്തിൽ ഒന്നിനെ മറ്റൊന്നുകൊണ്ട് മാറ്റുന്നതാണ് പ്രോജക്ടുകൾ ഒരു പാദം നഷ്ടപ്പെടുന്ന വഴി.
ഒരു ഉൽപ്പന്നം തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് തീരുമാനം കോൺക്രീറ്റ് പദങ്ങളിൽ രേഖപ്പെടുത്തുക: യഥാർത്ഥ ഉറവിടം, യഥാർത്ഥ ലക്ഷ്യം, വിവർത്തനം ചെയ്ത മൂല്യം, ആരംഭത്തിന്റെ ദിശ, വിവർത്തകന്റെ ഉടമ, പ്രതീക്ഷിക്കുന്ന മറുപടി പാത. ബാക്കെൻഡ് ലോഗുകൾ ഏത് ഐഡന്റിറ്റി നിലനിർത്തുമെന്നും ചേർക്കുക, കാരണം എല്ലാ ഉറവിടങ്ങളും മറയ്ക്കുന്ന ഒരു രൂപകൽപ്പന ഓരോ ക്ലയന്റിനുമുള്ള ഓഡിറ്റും നശിപ്പിക്കുന്നു.
AWS നിങ്ങൾക്കുവേണ്ടി മാപ്പിംഗ് ചെയ്യാനാകുമോ എന്ന് പരിശോധിക്കുക
Transit Gateway, Cloud WAN അറ്റാച്ച്മെന്റുകളിൽ AWS ഇപ്പോൾ നിയന്ത്രിത ഒന്നിൽ-നിന്ന്-ഒന്നിലേക്കുള്ള NAT രേഖപ്പെടുത്തുന്നു, ഇത് 2026 ഒക്ടോബർ അവസാനം പ്രഖ്യാപിച്ചു, അതിനാൽ ഒരു ട്രാൻസിറ്റ് ഗേറ്റ്‌വേയ്ക്ക് ഒരിക്കലും വിവർത്തനം ചെയ്യാനാകില്ല എന്ന പഴയ പൊതു അവകാശവാദം കാലഹരണപ്പെട്ടതാണ്. Transit Gateway NAT ഡോക്യുമെന്റേഷൻ അവസ്ഥയില്ലാത്ത IPv4 പ്രിഫിക്സ് മാപ്പിംഗ് വിവരിക്കുന്നു: യഥാർത്ഥ, വിവർത്തനം ചെയ്ത പ്രിഫിക്സുകൾ ഒരേ നീളം നിലനിർത്തുന്നു, ഹോസ്റ്റ് ബിറ്റുകളും ഗതാഗത പോർട്ടുകളും വിവർത്തനത്തിൽ നിന്ന് അതിജീവിക്കുന്നു. ഇൻഗ്രെസ്, എഗ്രെസ് ദിശകൾ വെവ്വേറെ ഡിസൈൻ തീരുമാനങ്ങളായി വായിക്കുക, കാരണം അവ വെവ്വേറെ കോൺഫിഗർ ചെയ്യപ്പെടുന്നു, ഒന്ന് തയ്യാറാകുമ്പോൾ മറ്റൊന്ന് ആയിക്കൊള്ളണമെന്നില്ല. ആ വിവരണത്തിൽ ഫ്ലോ അനുസരിച്ചുള്ള അവസ്ഥ സൂചിപ്പിക്കുന്നതായി ഒന്നുമില്ല, അതിനാൽ മാപ്പിംഗ് നിങ്ങൾക്കുവേണ്ടി കണക്ഷനുകൾ ട്രാക്ക് ചെയ്യുമെന്ന് പ്രതീക്ഷിക്കരുത്.
അർത്ഥം, 10.80.0.0/16 172.28.0.0/16 ലേക്ക് മാപ്പ് ചെയ്യുമ്പോൾ 10.80.10.23 172.28.10.23 ആയി മാറുന്നു. ഇത് /16 ഒരു വിലാസത്തിലേക്ക് ചുരുക്കുന്നില്ല, PAT ആവശ്യകതയ്ക്ക് പകരമാകുന്നുമില്ല. തിരഞ്ഞെടുത്ത അറ്റാച്ച്മെന്റ് തരങ്ങളും ഇത് ഉൾക്കൊള്ളുന്നു, അവയിൽ VPC ഉം Site-to-Site VPN ഉം ഉണ്ട്, എന്നാൽ Client VPN അറ്റാച്ച്മെന്റുകളല്ല, ഒപ്പം കോൺഫിഗറേഷൻ Anypoint ഭാഗത്തല്ല, ട്രാൻസിറ്റ് ഗേറ്റ്‌വേ ഉടമയുടെ കൈവശമാണ്.
ഈ സവിശേഷതയെ മറ്റൊരു സാധ്യമായ നിയന്ത്രണ ബിന്ദുവായി കാണുക, നിങ്ങളുടെ വിന്യാസത്തിന് ഇത് ഉപയോഗിക്കാമെന്നതിന്റെ തെളിവായി അല്ല. CloudHub 2.0 ഉപഭോക്താവിന്റെ സ്വന്തം AWS അക്കൗണ്ടിലെ ട്രാൻസിറ്റ് ഗേറ്റ്‌വേയിലേക്കുള്ള സ്വകാര്യ-സ്ഥല അറ്റാച്ച്മെന്റുകൾ പ്രാദേശിക, അവകാശ വ്യവസ്ഥകളോടെ രേഖപ്പെടുത്തുന്നു, അതിനാൽ പുതിയ ഓപ്ഷന് ചുറ്റും രൂപകൽപ്പന ചെയ്യുന്നതിന് മുമ്പ് യഥാർത്ഥ അറ്റാച്ച്മെന്റ് തരം, അതിന്റെ ഉടമ, വിതരണക്കാരന്റെ പിന്തുണ നിലപാട് എന്നിവ സ്ഥിരീകരിക്കുക.
പാതയെ പിന്തുണയ്ക്കുന്ന അതിർത്തിക്കുള്ളിൽ നിർത്തുക
ഫയർവാൾ വിവർത്തകനായി, പ്രവർത്തിക്കുന്ന ടണലിൽ ഒരു പൊതു NAT നിയമം ഒട്ടിക്കുന്നതിന് പകരം ആ ഉൽപ്പന്നത്തിന്റെ പിന്തുണയ്ക്കുന്ന VPN, വിവർത്തന, റൂട്ടിംഗ് മാതൃക ഉപയോഗിക്കുക. ബാക്കെൻഡിന്റെ മറുപടി അതേ വിവർത്തന ഘടകത്തിലൂടെ തിരികെ വരണം, ആരോഗ്യകരമായ ഔട്ട്ബൗണ്ട് ടണൽ ആ മടക്കുപാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
ട്രാൻസിറ്റ് ഗേറ്റ്‌വേ റൂട്ടിനായി, സ്വകാര്യ-സ്ഥല അറ്റാച്ച്മെന്റ്, ബന്ധപ്പെട്ട റൂട്ട് ടേബിളുകൾ, ഓൺ-പ്രെമിസ് അറ്റാച്ച്മെന്റ്, ഉപഭോക്താവിന് യഥാർത്ഥത്തിൽ കോൺഫിഗർ ചെയ്യാനാകുന്ന ഭാഗങ്ങൾ എന്നിവയുടെ കണക്കെടുക്കുക. ഇത് വ്യത്യസ്ത കണക്റ്റിവിറ്റി ആർക്കിടെക്ചറാണ്, നിലവിലുള്ള Anypoint VPN കണക്ഷനിൽ ബോൾട്ട് ചെയ്ത NAT ചെക്ക്ബോക്സല്ല, പിന്തുണയുടെ അതിർത്തി അതിനൊപ്പം നീങ്ങുന്നു.
മൂന്ന് ഓപ്ഷനുകളും ഒരു പട്ടികയിൽ താരതമ്യം ചെയ്യുക
മിക്ക ടീമുകൾക്കും രണ്ട് ചോദ്യങ്ങൾക്ക് മാത്രം ഉത്തരം നൽകിയാൽ മതി: പലതിൽ-നിന്ന്-ഒന്നിലേക്കോ ഒന്നിൽ-നിന്ന്-ഒന്നിലേക്കോ, ഒപ്പം അറ്റാച്ച്മെന്റിന്റെ ഉടമ ആരാണ്. താഴെയുള്ള പട്ടിക ആ ഉത്തരങ്ങളെ ഒരു പ്രാരംഭ ഓപ്ഷനാക്കി മാറ്റുന്നു.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
മൂന്നാം നിര പിന്നീടുള്ള ചിന്തയായി അല്ല, അവലോകന ചോദ്യമായി വായിക്കുക. കടലാസിൽ അനുവദനീയമെങ്കിലും നിങ്ങൾക്ക് ഉടമസ്ഥതയില്ലാത്ത ഒരു അറ്റാച്ച്മെന്റിൽ കോൺഫിഗർ ചെയ്ത പ്രിഫിക്സ് മാപ്പ് ഇപ്പോഴും തടഞ്ഞ പ്രോജക്ടാണ്, ട്രാഫിക് കടത്തിവിടുന്നതും എന്നാൽ ഓരോ ക്ലയന്റിനുമുള്ള ലോഗിംഗ് തകർക്കുന്നതുമായ PAT നിയമം തുടർന്നുള്ള ഓഡിറ്റിൽ പരാജയപ്പെടുന്നു.
വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് മാപ്പിംഗ് സാധൂകരിക്കുക
പാതയിലൂടെ ഒരു പുതിയ ആപ്ലിക്കേഷൻ പ്രവർത്തനം അയച്ച് അഭ്യർത്ഥന മാത്രമല്ല, മറുപടിയും സ്ഥിരീകരിക്കുക. ബാക്കെൻഡ് ഉടമയോട് അവരുടെ ലോഗുകൾ ഏത് ഉറവിട വിലാസം രേഖപ്പെടുത്തി എന്ന് ചോദിക്കുക, ഇരു ദിശകളിലും വിലാസ കുടുംബ കൈകാര്യം പ്ലാനുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് പരിശോധിക്കുക, നിരസിക്കേണ്ട ഒരു പാത ഇപ്പോഴും നിരസിക്കപ്പെടുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. പഴയ കണക്ഷൻ നിങ്ങൾ ഇപ്പോൾ മാറ്റിയ മാപ്പിംഗിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.
ബാക്കെൻഡ് ഓതന്റിക്കേഷൻ അതിന്റെ അനുവദനീയ പട്ടിക തൃപ്തിപ്പെടുത്തുന്ന ഏത് വിവർത്തനം ചെയ്ത വിലാസത്തിൽ നിന്നും സ്വതന്ത്രമായി നിർത്തുക, കാരണം മാപ്പിംഗ് നെറ്റ്‌വർക്ക് പ്ലംബിംഗാണ്, ആക്സസ് നിയന്ത്രണ തീരുമാനമല്ല. പാസ്‌വേഡ് റീസെറ്റ് ഒരു NAT പ്രിഫിക്സിനെ ആശ്രയിക്കുന്ന നിമിഷം, ഭാവിയിലെ എല്ലാ ശ്രേണി മാറ്റവും തടസ്സമായി മാറുന്നു.
അനുമതിക്ക് മുമ്പ് മൂന്ന് ഉത്തരങ്ങൾ എഴുതുക: വിവർത്തനത്തിന്റെ തരം, വിവർത്തകന്റെ ഉടമ, അത് വഹിക്കുന്ന പിന്തുണയ്ക്കുന്ന അറ്റാച്ച്മെന്റ് അല്ലെങ്കിൽ ഉൽപ്പന്ന പാത. അവയിലേതെങ്കിലും ഇപ്പോഴും ഊഹമാണെങ്കിൽ, ഡിസൈൻ മാറ്റ വിൻഡോയ്ക്ക് തയ്യാറല്ല.