Azure peering അല്ലെങ്കിൽ VNet-ൽ നിന്ന് VNet-ലേക്കുള്ള VPN? റൂട്ടിംഗിന് മുമ്പ് തീരുമാനിക്കുക

Azure രണ്ട് വെർച്വൽ നെറ്റ്‌വർക്കുകൾ ബന്ധിപ്പിക്കാൻ കുറഞ്ഞത് രണ്ട് വഴികൾ നൽകുന്നു, അവ ഒരേ ഒബ്ജക്റ്റിലെ പരസ്പരം മാറ്റാവുന്ന ക്രമീകരണങ്ങളല്ല. Peering ഗേറ്റ്‌വേയില്ലാതെ Microsoft-ിന്റെ ബാക്ക്ബോണിൽ VNet-കൾ ബന്ധിപ്പിക്കുന്നു; VNet-ൽ നിന്ന് VNet-ലേക്കുള്ള VPN നിങ്ങൾ വിന്യസിക്കുകയും വലുപ്പം നിർണ്ണയിക്കുകയും നിരീക്ഷിക്കുകയും ചെയ്യുന്ന രണ്ട് ഗേറ്റ്‌വേകൾക്കിടയിൽ IPsec ബന്ധം സ്ഥാപിക്കുന്നു. തീരുമാനം മൂന്ന് വ്യവസ്ഥകളിലേക്ക് എത്തുന്നു, റൂട്ട് ചേർക്കുന്നതിന് മുമ്പ് മൂന്നിനും ഉത്തരം നൽകാൻ കഴിയില്ലെങ്കിൽ, നിങ്ങൾ ഒരിക്കലും തിരഞ്ഞെടുക്കാത്ത ഒരു മോഡലിന് വഴിത്തിരിവ് നിർമ്മിക്കാൻ പോകുന്നു.

മോഡൽ നിർണ്ണയിക്കുന്ന മൂന്ന് വ്യവസ്ഥകൾ

ആദ്യത്തേത്, ആവശ്യകതയിലെ എന്തെങ്കിലും നിങ്ങളുടെ ഉടമസ്ഥതയിലുള്ളതും നിങ്ങൾക്ക് ചൂണ്ടിക്കാണിക്കാവുന്നതുമായ IPsec അതിർത്തി ആവശ്യമാണോ എന്നതാണ്. രണ്ടാമത്തേത്, വിലാസ ഇടങ്ങൾ വൃത്തിയാണോ എന്നും രണ്ട് VNet-കൾ പരസ്പരം സംസാരിക്കേണ്ടത് മാത്രമാണോ എന്നതാണ്. മൂന്നാമത്തേത്, ഏതെങ്കിലും കൈമാറ്റ പാതയുടെയും ഗേറ്റ്‌വേ ബില്ലിന്റെയും ഉടമ ആരെന്നതാണ്. ആ ക്രമത്തിൽ ഉത്തരം നൽകുക, കാരണം രണ്ടാമത്തേത് എത്ര ആകർഷകമായി തോന്നിയാലും ആദ്യത്തേതിന് peering ഒഴിവാക്കാം.

രണ്ട് മോഡലുകൾക്കും പൊതുവായത് കർശനമായ വിലാസ നിയമമാണ്: VNet വിലാസ ഇടങ്ങൾ ഒന്നിനുമേൽ ഒന്ന് വരരുത്. Peering-ഉം VNet-ൽ നിന്ന് VNet-ലേക്കുള്ള VPN-ഉം രണ്ട് സമാന ശ്രേണികളെ അസന്ദിഗ്ധമാക്കാനുള്ള പിന്തുണയുള്ള വഴിയല്ല, കൂടിച്ചേരലിന് മറ്റൊരു കണക്ഷൻ തരത്തല്ല, മാപ്പിംഗ് രൂപകൽപ്പനയോ പുനർരൂപകൽപ്പനയോ വേണം.

വ്യവസ്ഥ 1: നിങ്ങളുടെ ഉടമസ്ഥതയിലുള്ള IPsec അതിർത്തി വേണോ?

Peering ട്രാഫിക് Azure-ിന്റെ സ്വകാര്യ ബാക്ക്ബോണിലൂടെ കൊണ്ടുപോകുന്നു, peered കണക്ഷന് തന്നെ VPN ഗേറ്റ്‌വേ ആവശ്യമില്ല. ഇത് ഗതാഗതത്തെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്, ഓഡിറ്ററെ «ഞങ്ങൾ IPsec പ്രവർത്തിപ്പിക്കുന്നു» എന്ന് നൽകാവുന്ന എൻക്രിപ്ഷൻ പ്രസ്താവനയല്ല. ആവശ്യകത ഉപഭോക്താവ് കോൺഫിഗർ ചെയ്ത ടണൽ, നിർദ്ദിഷ്ട IKE നയം അല്ലെങ്കിൽ നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഉപകരണത്തിൽ അവസാനിക്കുന്ന അതിർത്തി പേരിട്ടാൽ, ബാക്ക്ബോൺ എത്ര സ്വകാര്യമായാലും peering അത് നിറവേറ്റുന്നില്ല.

VNet-ൽ നിന്ന് VNet-ലേക്കുള്ള VPN ആ അതിർത്തി നൽകുന്നു: രണ്ട് ഗേറ്റ്‌വേകൾ, IPsec/IKE ബന്ധം, പങ്കിട്ട കീകൾ, അതിനൊപ്പം വരുന്ന മുഴുവൻ പ്രവർത്തന ഉപരിതലവും. നിങ്ങൾ ടണൽ അവസ്ഥ, ഗേറ്റ്‌വേ ശേഷി, SKU പരിധികൾ, ടണൽ പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്ന നിരീക്ഷണം എന്നിവ പാരമ്പര്യമായി നേടുന്നു. ആവശ്യകത കൃത്യമായി ആ അതിർത്തിയെക്കുറിച്ചാകുമ്പോൾ ഇതാണ് ശരിയായ ഉത്തരം, അത് peering അവലോകനത്തിൽ peering-ൽ നിന്ന് വ്യത്യസ്തമായ കണക്ഷൻ തരമായി വിവരിച്ചിരിക്കുന്നു.

വിപരീത ദിശയിലും അത്രതന്നെ ശ്രദ്ധിക്കുക. «VNet-കൾക്കിടയിൽ എൻക്രിപ്ഷൻ വേണം» പലപ്പോഴും വർക്ക്ലോഡിന്റെ സ്വന്തം TLS കൊണ്ട് നിറവേറ്റുന്നു, അപ്പോൾ ഗേറ്റ്‌വേ പിന്നിൽ ആവശ്യകതയില്ലാത്ത ചെലവാണ്. സംവിധാനം തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഓഡിറ്റർ വായിക്കുന്ന വാക്യം എഴുതുക.

വ്യവസ്ഥ 2: ടോപ്പോളജി നേരിട്ടുള്ളതാണോ, അതോ എന്തെങ്കിലും കൈമാറണോ?

Peering കൈമാറ്റാത്മകമല്ല. ഒരു ഹബ്ബിലേക്ക് peered ചെയ്ത രണ്ട് VNet-കൾ അതുകൊണ്ട് പരസ്പരം ബന്ധിപ്പിച്ചിട്ടില്ല, ഒരു ദിശയിൽ പ്രവർത്തിക്കുന്നതായി തോന്നുന്ന റൂട്ട് സാധാരണയായി ഒരു വശത്ത് മാത്രം Connected എത്തിയ peering ആണ്. ഇരു വശങ്ങളും നിലനിൽക്കണം, രണ്ടും Connected കാണിക്കണം, ട്രാഫിക് നിശബ്ദമായി അപ്രത്യക്ഷമാകുമ്പോൾ ആദ്യം പരിശോധിക്കുന്നത് അതാണ്.

ആവശ്യകത ഹബ്ബിലൂടെ ഓൺ-പ്രിമൈസസ് എത്തിച്ചേരലാണെങ്കിൽ, ഗേറ്റ്‌വേ ട്രാൻസിറ്റ് നിർദ്ദിഷ്ട റോളുകളുള്ള പ്രത്യേക രൂപകൽപ്പനയാണ്: ഹബ്ബ് ഗേറ്റ്‌വേയുടെ ഉടമ, സ്പോക്ക് peering ഗേറ്റ്‌വേ ട്രാൻസിറ്റ് അനുവദിക്കുന്നു, സ്പോക്ക് ഫോർവേഡ് ചെയ്ത ട്രാഫിക് അനുവദിക്കണം. ഇവ peering-ലെ സവിശേഷതകളാണ്, VNet-കൾ ബന്ധിപ്പിക്കുന്നതിന്റെ സ്വയമേവയുള്ള പരിണിതഫലങ്ങളല്ല:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

ഫലപ്രദമായ റൂട്ട് പട്ടിക «പാതയുണ്ടോ?» എന്നതിന് സത്യസന്ധമായ ഉത്തരമാണ്. പ്ലാറ്റ്ഫോം യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന അടുത്ത ഹോപ്പ് തരം അത് കാണിക്കുന്നു, അതിനാൽ കോൺഫിഗർ ചെയ്തതുപോലെ തോന്നുന്നതും എന്നാൽ ബന്ധിപ്പിച്ചിട്ടില്ലാത്തതുമായ peering രഹസ്യമായല്ല, കാണാത്തതോ തെറ്റായതോ ആയ റൂട്ടായി കാണപ്പെടുന്നു.

വ്യവസ്ഥ 3: കൈമാറ്റ പാതയുടെയും ബില്ലിന്റെയും ഉടമ ആര്?

ഓരോ അധിക ഹോപ്പിനും ഒരു ഉടമയുണ്ട്. Peering-ൽ പുതിയ VNet എന്നാൽ ഇരു വശങ്ങളിലും പുതിയ peering ജോഡി, കൈമാറ്റത്തിന് ട്രാഫിക് തുടർന്ന് കൈമാറുന്ന ഹബ്ബും അതിലേക്ക് തുടർന്ന് ചൂണ്ടുന്ന റൂട്ട് പട്ടികയും. VPN-ൽ പുതിയ VNet എന്നാൽ മറ്റൊരു ഗേറ്റ്‌വേ അല്ലെങ്കിൽ നിലവിലുള്ളതിൽ മറ്റൊരു കണക്ഷൻ, അതിന്റേതായ ശേഷി പരിധി നിരീക്ഷിക്കണം.

ചെലവ് അതേ ആകൃതി പിന്തുടരുന്നു, പക്ഷേ അതേ ഇനങ്ങളല്ല: peering നിരക്കുകൾ കണക്ഷനും ഡാറ്റ കൈമാറ്റവുമാണ്, VPN ഗേറ്റ്‌വേ മണിക്കൂറുകളും സ്വന്തം കൈമാറ്റ നിരക്കുകളും ചേർക്കുന്നു. യഥാർത്ഥത്തിൽ ഒരു വർഷം പ്രവർത്തിപ്പിക്കുന്ന ടോപ്പോളജിയുടെ ആകെത്തുക താരതമ്യം ചെയ്യുക, രണ്ടാമത്തെ ടണലും നിരീക്ഷണവും ഉൾപ്പെടെ, ഇന്നത്തെ ഒരു കണക്ഷന്റെ വിലയല്ല. ആരും ഇൻവോയ്സ് ചെയ്യാത്ത ജോലിയും ഉൾപ്പെടുത്തുക: ആരെങ്കിലും കീകൾ കറക്കണം, ടണൽ അവസ്ഥ നോക്കണം, ഗേറ്റ്‌വേ റീസ്റ്റാർട്ട് ചെയ്യുമ്പോൾ രാത്രി മൂന്ന് മണിക്ക് അലേർട്ടിന് ഉത്തരം നൽകണം. സാധാരണയായി ഈ ഇനമാണ് തർക്കം തീരുമാനിക്കുന്നത്, കാരണം ക്വോട്ടേഷനിൽ ഒരിക്കലും കാണാത്ത ഏക ഇനം അതാണ്.

എന്ത് തിരഞ്ഞെടുത്താലും മൂന്ന് പ്രവാഹങ്ങൾ പരീക്ഷിക്കുക: ഉദ്ദേശിച്ചത്, നിരസിക്കപ്പെട്ടത് നിരസിക്കപ്പെട്ടു തന്നെ ഇരിക്കണം, ഹബ്ബ് ഗേറ്റ്‌വേ അല്ലെങ്കിൽ peering താഴെയിരിക്കുന്ന വീണ്ടെടുപ്പ് കേസ്. സുഖകരമായ പാത മാത്രം വിശദീകരിക്കുന്ന മോഡൽ പരിശോധിക്കപ്പെട്ടിട്ടില്ല, പ്രദർശിപ്പിക്കപ്പെട്ടിരിക്കുന്നു.

തിരഞ്ഞെടുപ്പ് അതിന്റെ സ്വന്തം അവകാശവാദത്തിനെതിരെ പരിശോധിക്കുക

മോഡൽ, അതിർത്തി, ഉടമ എന്നിവ പേരിടുന്ന ഒരു വാക്യം എഴുതുക, തുടർന്ന് വിന്യസിച്ച അവസ്ഥ അതിനോട് യോജിക്കുന്നുവെന്ന് പരിശോധിക്കുക. Peering-ന് അത് രണ്ട് peering അവസ്ഥകളും Connected, ഫലപ്രദമായ റൂട്ട് ലക്ഷ്യ പ്രിഫിക്സിന് peering അടുത്ത ഹോപ്പ് കാണിക്കുന്നു, പാതയിൽ ഗേറ്റ്‌വേ ഇല്ല. VNet-ൽ നിന്ന് VNet-ലേക്കുള്ള VPN-ന് അത് രണ്ട് കണക്ഷനുകളും Connected, രണ്ട് ഗേറ്റ്‌വേകളിലും യോജിക്കുന്ന കീകളും നയങ്ങളും, അടുത്ത ഹോപ്പ് വെർച്വൽ നെറ്റ്‌വർക്ക് ഗേറ്റ്‌വേ ആയ റൂട്ട്.

പരിശോധനകൾ വാക്യവുമായി വൈരുദ്ധ്യം പ്രകടിപ്പിച്ചാൽ ആദ്യം വാക്യം തിരുത്തുക. ഈ രൂപകൽപ്പനകളിലെ മിക്ക ആശയക്കുഴപ്പവും ആരും വിവരിക്കാത്ത സങ്കരത്തിൽ നിന്നാണ്: വർക്ക്ലോഡ് സബ്നെറ്റിന് peering, ഒരു പഴയ സേവനത്തിന് VPN, നിശബ്ദമായി ഒന്നിന് മുൻഗണന നൽകുന്ന റൂട്ട് പട്ടിക.