പീർ ചെയ്ത Azure VNet ന് സ്വന്തമായി VPN ഗേറ്റ്വേ ആവശ്യമുണ്ടോ?

ഒരു പുതിയ spoke VNet വരുന്നു, hub-ന് ഇതിനകം പ്രവർത്തിക്കുന്ന site-to-site ഗേറ്റ്വേ ഉണ്ട്, ഒരു രണ്ടാം ഗേറ്റ്വേയ്ക്ക് പണം നൽകേണ്ടതുണ്ടോ എന്നതാണ് വ്യക്തമായ ചോദ്യം. സാധാരണയായി ഇല്ല: ഗേറ്റ്വേ ട്രാൻസിറ്റ് spoke-ന് peering വഴി hub-ന്റെ ഗേറ്റ്വേ ഉപയോഗിക്കാൻ അനുവദിക്കുന്നു. മൂന്ന് വ്യവസ്ഥകളാണ് അത് പ്രവർത്തിക്കുമോ എന്ന് തീരുമാനിക്കുന്നത്, അവയൊന്നും peering സ്റ്റാറ്റസ് ബാഡ്ജിൽ കാണുന്നില്ല. Peering കണക്റ്റിവിറ്റിയും മറ്റൊരാളുടെ ഗേറ്റ്വേ ഉപയോഗിക്കാനുള്ള അനുമതിയും വെവ്വേറെ സെറ്റിംഗുകളാണ്, അതിനാൽ ഇതിനകം പരസ്പരം ping ചെയ്യാൻ കഴിയുന്ന രണ്ട് VM VPN പാതയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.

ആദ്യ വ്യവസ്ഥ: ഗേറ്റ്വേയും spoke-ൽ അതില്ലായ്മയും

Azure Basic ഒഴികെയുള്ള VPN Gateway SKU-കൾക്ക് ഗേറ്റ്വേ ട്രാൻസിറ്റ് പിന്തുണയ്ക്കുന്നു, പ്രാദേശികവും ആഗോളവുമായ peering രണ്ടും അത് വഹിക്കാൻ കഴിയും. spoke-ന് സ്വന്തമല്ലാത്ത ഗേറ്റ്വേയാണ് ഉപയോഗിക്കുന്നത്, അതിനാൽ സ്വന്തമായി ഒന്ന് ഉണ്ടാകാൻ കഴിയില്ല: spoke-ൽ ഇതിനകം ഗേറ്റ്വേ ഉണ്ടെങ്കിൽ, അല്ലെങ്കിൽ വിദൂര ഗേറ്റ്വേ ഓപ്ഷൻ ഇതിനകം തിരഞ്ഞെടുത്തിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾ ആഗ്രഹിക്കുന്ന ട്രാൻസിറ്റ് സെറ്റിംഗ് ലഭ്യമല്ലാതിരിക്കുകയോ ഫലപ്രദമല്ലാതിരിക്കുകയോ ചെയ്യും. എന്തെങ്കിലും ഡീബഗ് ചെയ്യുന്നതിന് മുമ്പ് ഇത് പരിശോധിക്കുക, കാരണം നിഷ്ക്രിയമായ ചെക്ക്ബോക്സ് ലക്ഷണമാണ്, കുറ്റമല്ല. ആദ്യം SKU-വും നിലവിലുള്ള ഗേറ്റ്വേയും വായിക്കുക, തുടർന്ന് peering സെറ്റിംഗുകൾ നോക്കുക.

ഓപ്ഷൻ കാണിക്കാൻ നിലവിലുള്ള spoke ഗേറ്റ്വേ അതിനെ ആശ്രയിക്കുന്നത് എന്തെന്ന് അറിയുന്നതുവരെ ഇല്ലാതാക്കരുത്. മാറ്റത്തിന്റെ ക്രമം ചെക്ക്ബോക്സിനേക്കാൾ പ്രധാനമാണ്.

രണ്ടാം വ്യവസ്ഥ: ഓരോ peering ദിശയിലും ഒരു സെറ്റിംഗ്

peering രണ്ട് ഒബ്ജക്റ്റുകളാണ്, ഓരോ VNet-ലും ഒന്ന്, ട്രാൻസിറ്റ് സെറ്റിംഗുകൾ ആ ജോഡിയുടെ വ്യത്യസ്ത വശങ്ങളിലാണ്. hub-ൽ നിന്ന് spoke-ലേക്കുള്ള peering, hub ഗേറ്റ്വേ spoke-ന് സേവനം നൽകാൻ അനുവദിക്കണം; spoke-ൽ നിന്ന് hub-ലേക്കുള്ള peering, hub-ന്റെ ഗേറ്റ്വേ സ്വീകരിക്കണം. Microsoft-ന്റെ ഗേറ്റ്വേ-ട്രാൻസിറ്റ് ഗൈഡ് ദിശ അനുസരിച്ച് അവയ്ക്ക് പേര് നൽകുന്നു, അവ ശരിയായി നിലനിർത്താനുള്ള ഏക മാർഗം അതാണ്:

remote എന്ന ലേബലുള്ള നിയന്ത്രണം നിങ്ങൾ ഏത് VNet-ന്റെ peering എഡിറ്റ് ചെയ്യുന്നു എന്നതനുസരിച്ച് അർത്ഥം മാറുന്നു, അതിനാൽ വാക്കല്ല, ദിശ വായിക്കുക. രണ്ട് വശങ്ങളും സെറ്റ് ചെയ്ത് സംരക്ഷിച്ച്, peering രണ്ട് സ്ഥലങ്ങളിലും കണക്റ്റ് ചെയ്തതായി റിപ്പോർട്ട് ചെയ്യുന്നുവെന്ന് ഉറപ്പാക്കുക.

മൂന്നാം വ്യവസ്ഥ: വിലാസ ഇടവും അനുമതി അതിരുകളും

ഒരേ ലക്ഷ്യ പ്രിഫിക്സ് രണ്ട് നെറ്റ്വർക്കുകളെ അർത്ഥമാക്കാൻ ട്രാൻസിറ്റിന് കഴിയില്ല, അതിനാൽ hub, spoke, പ്രാദേശിക നെറ്റ്വർക്ക് ശ്രേണികൾ ഇവയിലൊന്നും പ്രവർത്തിക്കുന്നതിന് മുമ്പ് വേർതിരിഞ്ഞിരിക്കണം. VNet-കൾ വ്യത്യസ്ത സബ്സ്ക്രിപ്ഷനുകളിലോ വ്യത്യസ്ത ടെനന്റുകളിലോ ആകാം; അത് വിലക്കല്ല, പക്ഷേ ഓരോ peering-ഉം സൃഷ്ടിക്കുന്നതോ അപ്ഡേറ്റ് ചെയ്യുന്നതോ ആയ ഐഡന്റിറ്റിക്ക് ആ നെറ്റ്വർക്കിൽ ആവശ്യമായ അനുമതികൾ ഉണ്ടായിരിക്കണം. സബ്സ്ക്രിപ്ഷനുകൾക്കിടയിലുള്ള മാറ്റങ്ങൾ പലപ്പോഴും അനുമതിയിൽ പരാജയപ്പെടുന്നു, പിശക് ടോപ്പോളജി പ്രശ്നമായി തെറ്റായി വായിക്കാൻ എളുപ്പമാണ്.

മാറ്റത്തിന് മുമ്പ് ശ്രേണികളും ഉടമകളും എഴുതിവയ്ക്കുക. രണ്ടിലൊന്ന് ഊഹിക്കുന്നത് കണക്റ്റ് ചെയ്യുന്നതും എന്നാൽ ഒന്നും റൂട്ട് ചെയ്യാത്തതുമായ peering സൃഷ്ടിക്കുന്നു.

peering സ്റ്റാറ്റസ് കൊണ്ടല്ല, ഫലപ്രദമായ റൂട്ടുകൾ കൊണ്ട് പരിശോധിക്കുക

spoke വർക്ക്ലോഡിന്റെ നെറ്റ്വർക്ക് ഇന്റർഫേസിലെ ഫലപ്രദമായ റൂട്ടുകൾ നോക്കി യഥാർത്ഥ പ്രാദേശിക പ്രിഫിക്സ് കണ്ടെത്തുക. സബ്നെറ്റിന്റെ റൂട്ട് ടേബിളും ഗേറ്റ്വേ റൂട്ട് പ്രചാരം നിഷ്ക്രിയമാണോ എന്നും പരിശോധിക്കുക, കാരണം ഉപയോക്തൃ-നിർവചിത റൂട്ടോ പരിശോധനാ ഉപകരണമോ peering ഫ്ലാഗുകൾ നിർദ്ദേശിക്കുന്ന പാതയെ അതിലംഘിക്കാം. തുടർന്ന് മറുദിശ ഉറപ്പാക്കുക: പ്രാദേശിക നെറ്റ്വർക്ക് site-to-site കണക്ഷനിലൂടെ spoke പ്രിഫിക്സിൽ എത്താനുള്ള വഴി അറിയണം, പഠിച്ച പരസ്യങ്ങളിലൂടെയോ വ്യക്തമായ റൂട്ടും ഉപഭോക്തൃ ഉപകരണത്തിലെ പൊരുത്തമുള്ള സംരക്ഷിത-നെറ്റ്വർക്ക് എൻട്രിയിലൂടെയോ. ഏതെങ്കിലും വശത്ത് പ്രിഫിക്സ് ഇല്ലെങ്കിൽ, മാറ്റേണ്ടത് peering ഫ്ലാഗുകളല്ല.

spoke വർക്ക്ലോഡിൽ നിന്ന് ഒരു സേവനം പരീക്ഷിച്ച് പ്രതികരണം പിന്തുടരുക. VPN ഗേറ്റ്വേയിൽ നിന്നോ hub VM-ൽ നിന്നോ ഉള്ള പരിശോധന വ്യത്യസ്ത ഉറവിട പ്രിഫിക്സും വ്യത്യസ്ത പാതയും ഉപയോഗിക്കുന്നു.

ടോപ്പോളജി point-to-site ക്ലയന്റുകളെയും സേവനം ചെയ്യുന്നുവെങ്കിൽ, അവയുടെ ഇൻസ്റ്റാൾ ചെയ്ത റൂട്ടുകൾ വെവ്വേറെ സാധൂകരിക്കുക. ടോപ്പോളജി മാറ്റത്തിന് ശേഷം Windows ക്ലയന്റ് പാക്കേജുകൾ പുനർനിർമ്മിക്കേണ്ടി വരാം, അത് ഗേറ്റ്വേ പങ്കിടൽ പരാജയപ്പെട്ടതിന്റെ തെളിവല്ല, ക്ലയന്റ് റൂട്ടിംഗ് ജോലിയാണ്.

ഗേറ്റ്വേ പങ്കിടൽ നൽകാത്തത്

ഗേറ്റ്വേ ട്രാൻസിറ്റ് റൂട്ടിംഗ് സൗകര്യമാണ്, അധികാരമല്ല. നെറ്റ്വർക്ക് സുരക്ഷാ ഗ്രൂപ്പുകൾ, പ്രാദേശിക ഫിൽട്ടറുകൾ, സേവന-തല നിയമങ്ങൾ എന്നിവ spoke വർക്ക്ലോഡിന് എവിടെ എത്താമെന്ന് ഇപ്പോഴും തീരുമാനിക്കുന്നു, അതിനാൽ പങ്കിട്ട ടണൽ അതിന് പിന്നിലുള്ള എല്ലാം അനുവദിക്കുന്നുവെന്ന് കരുതുന്നതിന് പകരം നിർദ്ദിഷ്ട ഉറവിടം-ലക്ഷ്യ സേവനം പ്രവർത്തനക്ഷമമാക്കുക.

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