Azure UDR മുതൽ VPN ഗേറ്റ്‌വേ വരെ: ഒരു ലക്ഷ്യസ്ഥാനം, മുഴുവൻ എക്സിറ്റും അല്ല

ഒരു ബാഹ്യ പ്രിഫിക്സിനായി ഉപയോക്താവ് നിർവചിച്ച റൂട്ട് ചേർത്ത്, അത് VPN ഗേറ്റ്‌വേയിലേക്ക് ചൂണ്ടി, ട്രാഫിക് ഇപ്പോഴും Azure-ന്റെ ഇന്റർനെറ്റ് പാതയിലൂടെ പുറത്തുപോകുന്നു. അല്ലെങ്കിൽ അത് ശരിയായി പുറത്തുപോകുന്നു, മറുപടി ഒരിക്കലും തിരികെ വരുന്നില്ല. രണ്ട് ഫലങ്ങളും ഒരേ തെറ്റിൽ നിന്നാണ് വരുന്നത്: Azure-ന്റെ അടുത്ത ഹോപ്പിനെ മുഴുവൻ ഡിസൈനായി കാണുന്നത്. റൂട്ട് പട്ടിക Azure-നുള്ളിൽ പാക്കറ്റ് ഏത് എക്സിറ്റ് എടുക്കുന്നു എന്ന് മാത്രം തീരുമാനിക്കുന്നു. ടണലിന് ശേഷം അതിന് എന്ത് സംഭവിക്കുന്നു, മറുപടി എങ്ങനെ തിരികെ വരുന്നു എന്നത് നിങ്ങൾ നിർമ്മിക്കേണ്ട രണ്ടാം പകുതിയാണ്.

അടുത്ത ഹോപ്പ് ഒരു ഗേറ്റ്‌വേയാണ്, ഒരു ഉപകരണത്തിന്റെ IP അല്ല

ഒരു UDR പൊരുത്തപ്പെടുന്ന പ്രിഫിക്സ് അടുത്ത-ഹോപ്പ് തരത്തിലേക്ക് അയയ്ക്കുന്നു, VirtualNetworkGateway ഒരു തരമാണ്, വിലാസമല്ല. ആളുകൾ ഗേറ്റ്‌വേയുടെ സ്വകാര്യ IP ഒരു VirtualAppliance റൂട്ടിൽ ഒട്ടിച്ച്, എന്തുകൊണ്ട് ഒന്നും പൊരുത്തപ്പെടുന്നില്ല എന്ന് ആശ്ചര്യപ്പെടുന്നു, കാരണം ആ തരം പകരം ഒരു NIC അല്ലെങ്കിൽ ആന്തരിക ലോഡ് ബാലൻസർ പ്രതീക്ഷിക്കുന്നു. Microsoft-ന്റെ റൂട്ടിംഗ് ഡോക്യുമെന്റേഷനും ഗേറ്റ്‌വേ അടുത്ത ഹോപ്പിനെ ഗേറ്റ്‌വേ ഒരു VPN ഗേറ്റ്‌വേയായുള്ള വെർച്വൽ നെറ്റ്‌വർക്കിലേക്ക് പരിമിതപ്പെടുത്തുന്നു. ExpressRoute, Route Server, Virtual WAN ഹബ് എന്നിവ ആ ഓപ്ഷൻ ഉപയോഗിച്ച് വിലാസം നൽകപ്പെടുന്നില്ല.

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

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഫലപ്രദമായ റൂട്ട് വായിക്കുക

Azure സിസ്റ്റം റൂട്ടുകൾ, BGP വഴി പഠിച്ച പ്രിഫിക്സുകൾ, UDR എന്നിവ ഓരോ NIC-ക്കും ഫലപ്രദമായ റൂട്ട് പട്ടികയിൽ സംയോജിപ്പിക്കുന്നു, ഏറ്റവും നീളമുള്ള പൊരുത്തപ്പെടുന്ന പ്രിഫിക്സ് എവിടെ നിന്ന് വന്നാലും വിജയിക്കുന്നു. ഒരേ പ്രിഫിക്സിന്, UDR ഒരു BGP റൂട്ടിനെ തോൽപ്പിക്കുന്നു. ഈ ക്രമമാണ് മുൻ പരീക്ഷണത്തിൽ നിന്നുള്ള പഴയ UDR നിങ്ങൾ ഇപ്പോൾ ടണലിലൂടെ പഠിച്ച പ്രിഫിക്സിനെ നിശബ്ദമായി മറികടക്കാൻ കാരണം.

ആദ്യം ഫലപ്രദമായ പട്ടിക നോക്കുക, തുടർന്ന് നിങ്ങൾ ഒരു റൂട്ട് ചേർക്കുകയാണോ മാറ്റിസ്ഥാപിക്കുകയാണോ എന്ന് തീരുമാനിക്കുക:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

പ്രിഫിക്സിനൊപ്പം സ്രോതസ്സ് കോളവും വായിക്കുക. ശരിയായ പ്രിഫിക്സും തെറ്റായ സ്രോതസ്സും ഉള്ള ഒരു റൂട്ട് ഏത് ഒബ്ജക്റ്റ് എഡിറ്റ് ചെയ്യണം എന്ന് പറയുന്നു, ആദ്യത്തേതിനോട് തോൽക്കുന്ന രണ്ടാമത്തെ റൂട്ട് ചേർക്കുന്നതിൽ നിന്ന് രക്ഷിക്കുന്നു.

യഥാർത്ഥ പ്രിഫിക്സിനും സബ്‌നെറ്റിനും എതിരായി റൂട്ട് എഴുതുക

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

റൂട്ട് സൃഷ്ടിക്കുക, തുടർന്ന് വർക്ക്ലോഡ് ഹോസ്റ്റ് ചെയ്യുന്ന സബ്‌നെറ്റിലേക്ക് പട്ടിക ബന്ധിപ്പിക്കുക:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

പ്രചരണവും പ്രധാനമാണ്. ആ പട്ടികയിൽ BGP പ്രചരണം പ്രവർത്തനക്ഷമമാക്കിയാൽ, പഠിച്ച പ്രിഫിക്സുകൾ നിങ്ങൾ എഴുതിയവയ്ക്കൊപ്പം ദൃശ്യമാകും, കൂടാതെ കൂടുതൽ നിർദ്ദിഷ്ടമായ പഠിച്ച പ്രിഫിക്സ് വിശാലമായ UDR-നെ തോൽപ്പിക്കാം. ആ സബ്‌നെറ്റിന് UDR കൂട്ടം അധികാരമുള്ളതായിരിക്കണമെന്ന് നിങ്ങൾ ഉദ്ദേശിക്കുമ്പോൾ മാത്രം പ്രചരണം പ്രവർത്തനരഹിതമാക്കുക.

ഓൺ-പ്രെമിസ് പകുതി പൂർത്തിയാക്കുക, അല്ലാത്തപക്ഷം ഫ്ലോ അവിടെ മരിക്കും

ഓൺ-പ്രെമിസ് ഗേറ്റ്‌വേ Azure സ്രോതസ്സ് സ്വീകരിക്കണം, അത് ലക്ഷ്യസ്ഥാനത്തേക്ക് ഫോർവേഡ് ചെയ്യണം, ആപ്ലിക്കേഷന് അനുമതി നൽകണം. അതിന്റെ അടുത്ത പാത ഒരു ഇന്റർനെറ്റ് എക്സിറ്റ് അല്ലെങ്കിൽ മറ്റൊരു സ്വകാര്യ ഹോപ്പ് ആകാം, പക്ഷേ ആ തീരുമാനം Azure റൂട്ട് പട്ടികയിലല്ല, പ്ലാനിലാണ്. സാധാരണ പരാജയം തിരിച്ചുവരവാണ്. ഒരു ഇന്റർനെറ്റ് ലക്ഷ്യസ്ഥാനം സ്വകാര്യ Azure സ്രോതസ്സിനെ നിങ്ങളിലേക്ക് തിരികെ റൂട്ട് ചെയ്യില്ല, അതിനാൽ മറുപടി അതിന്റെ സ്വന്തം ഡിഫോൾട്ട് ഗേറ്റ്‌വേയിലേക്ക് പോയി മരിക്കുന്നു, അല്ലെങ്കിൽ പുറത്തുപോകുന്നേയില്ല.

രണ്ട് ഡിസൈനുകൾ ഇത് പരിഹരിക്കുന്നു, അവ പരസ്പരം മാറ്റാനാവില്ല. എക്സിറ്റിൽ സ്രോതസ്സ് വിവർത്തനം ചെയ്യുക, അതുവഴി ലക്ഷ്യസ്ഥാനം ഓൺ-പ്രെമിസ് നെറ്റ്‌വർക്കിന് സ്വന്തമായുള്ള ഒരു പൊതു വിലാസത്തിന് മറുപടി നൽകുന്നു. അല്ലെങ്കിൽ സ്രോതസ്സ് സംരക്ഷിച്ച്, മറുപടികൾ ടണലിലൂടെ തിരികെ വരുന്നതിന് ഒരു റൂട്ട് ചെയ്ത തിരിച്ചുവരവ് ബന്ധം നിർമ്മിക്കുക. ഒന്ന് തിരഞ്ഞെടുത്ത് ആപ്ലിക്കേഷൻ ഏത് വിലാസം കാണുമെന്ന് എഴുതുക.

സെലക്ടറുകളും അനുമതി പട്ടികകളും ഇവയെല്ലാംതിൽ നിന്ന് വേർതിരിച്ചതാണ്. Azure അടുത്ത ഹോപ്പ് തിരഞ്ഞെടുക്കുന്നത് VPN ട്രാഫിക് സെലക്ടറുകൾ വിശാലമാക്കുന്നില്ല, ഒരു ബാഹ്യ സേവനത്തിന്റെ സ്രോതസ്സ് അനുമതി പട്ടിക മാറ്റുന്നുമില്ല.

ലക്ഷ്യസ്ഥാനം കാണുന്ന സ്രോതസ്സ് ഉപയോഗിച്ച് പരിശോധിക്കുക

മറ്റൊരു സബ്‌നെറ്റിലെ ജംപ് ഹോസ്റ്റിൽ നിന്നല്ല, യഥാർത്ഥ വർക്ക്ലോഡിൽ നിന്ന് അഭ്യർത്ഥന അയയ്ക്കുക, തുടർന്ന് ലക്ഷ്യസ്ഥാനം കണ്ട സ്രോതസ്സ് വിലാസം വായിക്കുക. ആ ഒരു മൂല്യം രണ്ട് തിരിച്ചുവരവ് ഡിസൈനുകളിൽ ഏതാണ് ഉള്ളതെന്ന് പറയുന്നു. തുടർന്ന് മറുപടി പാത പരിശോധിക്കുക, VM-ലേക്കുള്ള സാധാരണ മാനേജ്മെന്റ് ട്രാഫിക് ഇപ്പോഴും പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, കാരണം അബദ്ധത്തിൽ ചേർത്ത ഒരു ഡിഫോൾട്ട് റൂട്ട് ആപ്ലിക്കേഷൻ തകരുന്നതിന് വളരെ മുമ്പേ തകർന്ന SSH സെഷനായി കാണപ്പെടുന്നു.

തിരഞ്ഞെടുത്ത പ്രിഫിക്സിലൂടെയുള്ള ട്രാൻസിറ്റ് നിർബന്ധിത ടണലിംഗിനേക്കാൾ വളരെ ഇടുങ്ങിയ മാറ്റമാണ്. അത് ഇടുങ്ങിയതായി നിലനിർത്തുക, പിൻവലിക്കൽ ഒരു റൂട്ട് ഇല്ലാതാക്കുക എന്നതാണ്.