Azure VPN NAT ഓവർലാപ്പിംഗ് VNet വിലാസങ്ങൾ പരിഹരിക്കുന്നില്ല
ഒരേ സ്വകാര്യ ശ്രേണിയുള്ള രണ്ട് VNet NAT ഉള്ളതുകൊണ്ട് മാത്രം ബന്ധിപ്പിക്കപ്പെടില്ല. ആദ്യം കണക്ഷൻ തരം പരിശോധിക്കുക, പിന്നീട് പുനർനമ്പർ ചെയ്യുക അല്ലെങ്കിൽ വിവർത്തന ഉപനാമം സ്വന്തമാക്കുക.
രണ്ട് VNet-കളും 10.40.1.0/24 ഉപയോഗിക്കുന്നു, ടണലുകൾ ഉയരുന്നു, പക്ഷേ ഒന്നും പ്രവർത്തിക്കുന്നില്ല. രണ്ടാമതൊരു VPN ഗേറ്റ്‌വേ ചേർത്താലും അത് മാറില്ല, റൂട്ട് മെട്രിക് കുറച്ചാലും മാറില്ല, കാരണം പ്രശ്നം പാത്ത് തിരഞ്ഞെടുപ്പിലല്ല. ഒരേ സ്വകാര്യ വിലാസത്തിന് ഉത്തരം നൽകുന്ന രണ്ട് വർക്ക്ലോഡുകൾ ഓരോ പാക്കറ്റിനെയും അവ്യക്തമായ ലക്ഷ്യവും പരിശോധിക്കാനാവാത്ത മടങ്ങിവരവ് പാതയും നൽകി വിടുന്നു. ഏതെങ്കിലും വിവർത്തനം ആസൂത്രണം ചെയ്യുന്നതിന് മുൻപ് നിങ്ങൾ യഥാർത്ഥത്തിൽ ഏത് കണക്ഷൻ തരം സൃഷ്ടിച്ചു എന്ന് കണ്ടെത്തുക, കാരണം ആ ഒരു തിരഞ്ഞെടുപ്പാണ് Azure-ന്റെ NAT സൗകര്യം ഉണ്ടോ ഇല്ലയോ എന്ന് തീരുമാനിക്കുന്നത്.
ഈ ലക്ഷണം യഥാർത്ഥത്തിൽ നിങ്ങളോട് എന്ത് പറയുന്നു
VNet A-യിലെ ഒരു ഹോസ്റ്റ് 10.40.1.10-ലേക്ക് അയയ്ക്കുമ്പോൾ, റൂട്ടിംഗ് പട്ടികയ്ക്ക് അതിനെ എവിടേക്കെങ്കിലും ചൂണ്ടിക്കാട്ടാൻ മാത്രമേ കഴിയൂ. VNet B-യിലും 10.40.1.10 ഉണ്ടെങ്കിൽ, ആ വിലാസം പാത്തിന് വേർതിരിച്ചറിയാൻ കഴിയുന്ന ലക്ഷ്യമല്ല; അത് രണ്ട് ഉടമകളുള്ള ഒരു വിലാസമാണ്.
ആളുകൾ സാധാരണ വിന്യസിക്കുന്ന രണ്ടാമത്തെ ഗേറ്റ്‌വേ സഹായിക്കുന്നില്ല. അത് മറ്റൊരു ടണൽ നൽകുന്നു, മറ്റൊരു വിലാസമല്ല, കൂടാതെ തനിപ്പകർപ്പ് ശ്രേണി ടണലിനുള്ളിൽ മാറ്റമില്ലാതെ സഞ്ചരിക്കുന്നു. നിങ്ങൾ സ്ഥിരതയോടെ സൂക്ഷിക്കേണ്ട കോൺഫിഗറേഷനും അത് ഇരട്ടിയാക്കുന്നു. ചെയ്യാനാകാത്തത് ഒരു വിലാസത്തിന് രണ്ട് ഹോസ്റ്റുകൾ എന്ന അർത്ഥം നൽകുകയാണ്.
VPN പിയറുകളുടെ പൊതു വിലാസങ്ങൾ മാറ്റുന്നതും ഒന്നും ചെയ്യുന്നില്ല. ആ വിലാസങ്ങൾ ടണലിന്റെ അറ്റങ്ങൾ തിരിച്ചറിയുന്നു, എന്നാൽ കൂട്ടിയിടി അതിനുള്ളിൽ കൊണ്ടുപോകുന്ന സ്വകാര്യ ശ്രേണിയിലാണ്.
NAT ലഭ്യമാണോ എന്ന് കണക്ഷൻ തരം തീരുമാനിക്കുന്നു
Azure VPN Gateway-ക്ക് തീർച്ചയായും NAT കഴിവുണ്ട്, കൂടാതെ നിർദ്ദിഷ്ട ഗേറ്റ്‌വേ SKU-കളിൽ റൂട്ട് അധിഷ്ഠിത IPsec ഇന്റർ-സൈറ്റ് കണക്ഷനുകൾക്കായി അത് രേഖപ്പെടുത്തിയിട്ടുണ്ട്. അതേ രേഖ VNet-to-VNet, point-to-site കണക്ഷനുകൾ ഒഴിവാക്കുന്നു, അതിനാൽ ഈ സൗകര്യം എല്ലാ ഗേറ്റ്‌വേ ബന്ധത്തിലും പ്രത്യക്ഷപ്പെടുന്ന ഒരു ചെക്ക്ബോക്സല്ല.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
നേറ്റീവ് VNet-to-VNet-നും തുടക്കം മുതൽ VNet, ലോക്കൽ നെറ്റ്‌വർക്ക് ശ്രേണികൾ ഓവർലാപ്പ് ചെയ്യാതിരിക്കേണ്ടതുണ്ട്, ഇത് ഒഴിവാക്കലുമായി യോജിക്കുന്നു. അതേ കാരണത്താൽ VNet പിയറിംഗും ഓവർലാപ്പിനുള്ള പരിഹാരമല്ല.
നേറ്റീവ് തരവുമായി ആളുകൾ കൂട്ടിക്കുഴയ്ക്കുന്ന ഒരു പിന്തുണയുള്ള ബദലുണ്ട്: മറ്റേ VNet-നെ ലോക്കൽ നെറ്റ്‌വർക്കായി മാതൃകയാക്കി സൈറ്റ്-ടു-സൈറ്റ് കണക്ഷനായി ബന്ധിപ്പിക്കുക. അത് വേറെ റിസോഴ്സും വേറെ ഡിസൈനുമാണ്, അതിനാൽ പേരുമാറ്റിയ കണക്ഷനെ വെറും പേരുമാറ്റമല്ല, സാധൂകരിക്കേണ്ട മാറ്റമായി കാണുക.
പുനർനമ്പർ ചെയ്യുക, അല്ലെങ്കിൽ ഉപനാമം സ്വന്തമാക്കുന്ന എന്തെങ്കിലും ഉപയോഗിച്ച് വിവർത്തനം ചെയ്യുക
രണ്ട് VNet-കളും നിങ്ങളുടേതാണെങ്കിൽ, ആസൂത്രിത പുനർനമ്പറിംഗിനെ വിവർത്തനത്തിന്റെ തുടർച്ചയായ ചെലവുമായി താരതമ്യം ചെയ്യുക. പുനർനമ്പറിംഗ് ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷൻ, DNS റെക്കോർഡുകൾ, സുരക്ഷാ നിയമങ്ങൾ, ഓരോ നിലവിലുള്ള കണക്ഷനും സ്പർശിക്കുന്നു, പക്ഷേ പിന്നീട് സാധാരണയായി വായിക്കാവുന്ന ഒരു നെറ്റ്‌വർക്ക് അവശേഷിപ്പിക്കുന്നു. ഒരു സമയത്ത് ഒരു സബ്നെറ്റ് വീതം ചെയ്യുക, DNS മാറ്റം അവസാനം. പകുതി പുനർനമ്പർ ചെയ്ത ശ്രേണി ഏത് ഓപ്ഷനെക്കാളും മോശമാണ്, കാരണം അപ്പോൾ രണ്ട് പ്രിഫിക്സുകളും അടുത്തതായി പട്ടിക വായിക്കുന്നവർക്ക് അധികാരമുള്ളതായി തോന്നും.
പുനർനമ്പറിംഗ് പ്രായോഗികമല്ലാത്തിടത്ത്, ഉപനാമത്തിന് യഥാർത്ഥ ഉടമയുള്ള വിവർത്തന ഡിസൈൻ ഉപയോഗിക്കുക. VNet A-യിലെ വിളിക്കുന്നവർ VNet B-യുടെ 10.40.1.10-ൽ 10.140.1.10 ആയി എത്തിയേക്കാം, പക്ഷേ ആ ഉപനാമത്തിന് വിവർത്തനം ചെയ്യുന്ന ഉപകരണവും അതിലേക്കുള്ള റൂട്ടും മറുപടിക്ക് യോജിക്കുന്ന സ്വഭാവവും വേണം. DNS-ൽ മാത്രം ചേർത്ത വിലാസം വിവർത്തനമല്ല.
രണ്ട് ശ്രേണികളും രണ്ട് ദിശകളിലും രേഖപ്പെടുത്തുക: വിളിക്കുന്നയാൾ എന്ത് ഡയൽ ചെയ്യുന്നു, ലക്ഷ്യം ഉറവിടമായി എന്ത് കാണുന്നു, ഏത് വശത്തിന് തുടങ്ങാം. Azure-ന്റെ സ്വന്തം NAT നിയമങ്ങളിൽ അവയുടെ SNAT മാപ്പിംഗുകൾക്കുള്ള വിപരീത വിവർത്തനം ഉൾപ്പെടുന്നു, അതിനാൽ നിങ്ങൾ കൈകൊണ്ട് യോജിക്കുന്ന DNAT നിയമം എഴുതുന്നില്ല, പക്ഷേ ആ സൗകര്യം ഈ ഫീച്ചർ പിന്തുണയ്ക്കുന്ന കണക്ഷൻ തരങ്ങളിൽ അവസാനിക്കുന്നു.
എന്ത് പ്രവർത്തിക്കില്ല
ഉപയോക്തൃ-നിർവചിത റൂട്ടോ റൂട്ട് മെട്രിക്കോ കാണാത്ത വിലാസ വ്യത്യാസം സൃഷ്ടിക്കാനാവില്ല. രണ്ടും ഇപ്പോഴും അവ്യക്തമായ ലക്ഷ്യത്തിൽ പ്രവർത്തിക്കുന്നു, പാക്കറ്റ് പട്ടിക ഇഷ്ടപ്പെടുന്ന അടുത്ത ഹോപ്പിൽ എത്തുന്നു.
തനിപ്പകർപ്പ് ശ്രേണി കൂടുതൽ നിർദ്ദിഷ്ട പ്രിഫിക്സായി റൂട്ട് പട്ടികയിൽ ചേർക്കുന്നത് അവ്യക്തതയെ ഒരു ചുവട് മാത്രം നീക്കുന്നു. മറുപടിക്ക് ഇപ്പോൾ രണ്ട് സാധ്യമായ ഉറവിടങ്ങളുള്ള എതിർദിശയെ അത് തകർക്കാനും സാധ്യതയുണ്ട്.
രണ്ട് ദിശകളിലെയും ട്രാഫിക്കോടെ ഡിസൈൻ സ്വീകരിക്കുക
ടണൽ നിലവാരത്താൽ അല്ല, ഓരോ വശത്തുനിന്നും പുതിയ അനുവദിച്ച പ്രവർത്തനത്താൽ ഡിസൈൻ തെളിയിക്കുക. ബന്ധിപ്പിച്ച IPsec ടണൽ പിയറുകൾ ക്രിപ്റ്റോഗ്രഫിയിൽ യോജിക്കുന്നു എന്ന് പറയുന്നു; ലക്ഷ്യങ്ങൾ വേർതിരിച്ചറിയാവുന്നതായോ എന്ന് അത് ഒന്നും പറയുന്നില്ല.
തുടർന്ന് നിരസിച്ച പാതകൾ പ്രവർത്തിപ്പിക്കുക: എത്തിച്ചേരാനാവാത്തതായി തുടരേണ്ട വിലാസം, നയം തടയേണ്ട സേവനം. രണ്ടും ഇപ്പോഴും വിജയിക്കുന്നുവെങ്കിൽ, വിവർത്തനം ഡിസൈൻ ഉദ്ദേശിച്ചതിലും വിശാലമാണ്.
പിന്നീട് ഈ ക്രമീകരണം വിശദീകരിക്കുന്ന വസ്തുതകളോടെ അവസാനിപ്പിക്കുക: യഥാർത്ഥ ശ്രേണി, അവതരിപ്പിച്ച ശ്രേണി, വിവർത്തനം ചെയ്യുന്ന ഉപകരണം, ഓരോ വശത്തിനും തുടങ്ങാവുന്ന ദിശ. ഇവയിൽ ഏതെങ്കിലും കാണാതിരുന്നാൽ, അടുത്ത എൻജിനീയർക്ക് രണ്ട് ഹോസ്റ്റുകൾ ഒരേ പേര് പങ്കിടുന്നതും എന്തുകൊണ്ട് ഒന്ന് മറുപടി നൽകുന്നു എന്ന് ആർക്കും ഓർമയില്ലാത്തതുമായ ഒരു നെറ്റ്‌വർക്ക് അവകാശമായി ലഭിക്കും.