resolver പിയർ ചെയ്ത VNet-ൽ ആയിരിക്കുമ്പോൾ Azure P2S DNS പരാജയപ്പെടുന്നു

VM-ലേക്ക് പിംഗ് ചെയ്യുക, അത് ഉത്തരം നൽകുന്നു; അതിന്റെ പേര് ചോദിക്കുക, ഹോസ്റ്റ് അജ്ഞാതമാണെന്ന് ക്ലയന്റ് പറയുന്നു. VPN ഗേറ്റ്വേ ഉള്ള നെറ്റ്വർക്കിലല്ല, പിയർ ചെയ്ത വെർച്വൽ നെറ്റ്വർക്കിലാണ് resolver ഇരിക്കുന്നതെങ്കിൽ, ഈ രണ്ട് ഫലങ്ങൾ പ്രതീക്ഷിതമാണ്, എത്ര resolver പരിശോധന നടത്തിയാലും അത് മാറില്ല. ഇല്ലാത്തത് പിയറിംഗ് സ്വതവേ പിടിച്ചുവയ്ക്കുന്ന ഒരു റൂട്ടിംഗ് കരാർ ആണ്. രണ്ട് ടോപ്പോളജികൾ പേപ്പറിൽ ഏതാണ്ട് ഒരുപോലെ കാണപ്പെടുന്നു, പ്രവർത്തിക്കുന്നതും തകർന്നതും തമ്മിലുള്ള വ്യത്യാസം ശരിയായ ദിശയിൽ വച്ച ഒരു ജോടി പിയറിംഗ് സ്വിച്ചുകളാണ്.

ഒരു ലാപ്ടോപ്പ് VNet2-ലെ ഗേറ്റ്വേയിലേക്ക് ടണൽ ചെയ്യുന്നു, DNS നൽകുന്ന ഡൊമെയിൻ കൺട്രോളർ VNet1-ൽ ഇരിക്കുന്നു എന്ന് സങ്കൽപ്പിക്കുക.

രണ്ട് ടോപ്പോളജികൾ, ഒരു വ്യത്യാസം

resolver ഗേറ്റ്വേയുടെ സ്വന്തം വെർച്വൽ നെറ്റ്വർക്കിനുള്ളിൽ വയ്ക്കുക, ടണൽ ഉയരുന്ന നിമിഷം പേര് പരിഹരിക്കപ്പെടും. ആ തിരയലിൽ ഒരു പിയറിംഗ് ക്രമീകരണവും പങ്കെടുക്കുന്നില്ല.

അതേ resolver പിയറിംഗിന് അപ്പുറത്തേക്ക് മാറ്റുക, ക്ലയന്റിന് ഇപ്പോഴും VM-ൽ നിന്ന് ഉത്തരം ലഭിക്കുന്നു, പേര് അജ്ഞാതമായി തുടരുന്നു. സർട്ടിഫിക്കറ്റ്, ടണൽ, ക്ലയന്റ് എന്നിവ മാറിയിട്ടില്ല. മാറിയത് resolver എവിടെ താമസിക്കുന്നു എന്നത് മാത്രമാണ്. പിയറിംഗ് അതിന് ആ വിലാസത്തിലേക്ക് ഒരു റൂട്ട് നൽകി, ഗേറ്റ്വേയ്ക്ക് അങ്ങോട്ട് ട്രാഫിക് കൊണ്ടുപോകാനുള്ള അധികാരമല്ല.

വശം A: ഗേറ്റ്വേ ഉടമയിൽ ഗേറ്റ്വേ ട്രാൻസിറ്റ് അനുവദിക്കുക

പിയറിംഗ് രണ്ട് വെർച്വൽ നെറ്റ്വർക്കുകളെ ബന്ധിപ്പിക്കുന്നു, എന്നാൽ ഗേറ്റ്വേ വഴി വരുന്ന ട്രാഫിക്കിന് ഈ ബന്ധം സംക്രമണമല്ല, പോയിന്റ്-ടു-സൈറ്റ് അഭ്യർത്ഥന കൃത്യമായി അങ്ങനെയാണ് വരുന്നത്. അതിനാൽ VNet2-ലെ ഗേറ്റ്വേയ്ക്ക് ഡിസൈൻ അനുവദിക്കുന്നതുവരെ തിരയൽ VNet1-ന് കൈമാറാൻ അധികാരമില്ല. അനുമതി ഗേറ്റ്വേ ഉള്ള നെറ്റ്വർക്കിന്റെ ഉടമസ്ഥതയിലുള്ള പിയറിംഗിലെ ഒരു സ്വിച്ച് ആണ്.

VNet2-ൽ നിന്ന് VNet1-ലേക്കുള്ള പിയറിംഗിൽ Allow gateway transit സജ്ജമാക്കുക. ഈ പ്രോപ്പർട്ടി ഗേറ്റ്വേ റിസോഴ്സിന്റേതല്ല, പിയറിംഗ് ഒബ്ജക്റ്റിന്റേതാണ്, അതിനാൽ പിയറിംഗ് ബ്ലേഡിൽ അത് വായിക്കുകയും മാറ്റുകയും ചെയ്യുന്നു. വശം A മുഴുവൻ ഇത്രമാത്രം.

വശം B: പിയറിൽ വിദൂര ഗേറ്റ്വേകൾ ഉപയോഗിക്കുക

മറ്റേ പകുതി കണ്ണാടി പ്രതിബിംബമാണ്: VNet1-ൽ നിന്ന് VNet2-ലേക്ക് തിരികെയുള്ള പിയറിംഗിൽ Use remote gateways പ്രവർത്തനക്ഷമമാക്കുക. അതേ ഫ്ലാഗ് രണ്ട് അറ്റത്തും, അല്ലെങ്കിൽ ഒരു അറ്റത്ത് മാത്രം ഓണാക്കിയാൽ പകുതി നിർമ്മിച്ച പാതയും യഥാർത്ഥ ലക്ഷണവും അതേപടി നിലനിൽക്കും. VPN ഗേറ്റ്വേ ഉള്ള നെറ്റ്വർക്ക് മാത്രമാണ് ട്രാൻസിറ്റ് അനുവദിക്കുന്നത്, പിയർ അത് ഉപയോഗിക്കുന്ന വശമാണ്.

അവസാനം തുറന്ന പോർട്ടൽ ബ്ലേഡിനെ വിശ്വസിക്കുന്നതിനുപകരം രണ്ട് നെറ്റ്വർക്കുകളിലും രണ്ട് പ്രോപ്പർട്ടികളും വായിക്കുക.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

ജോടി ഒരുമിച്ച് കാണുന്നത് തലകീഴായ ക്രമീകരണം പിടികൂടാനുള്ള ഏറ്റവും വേഗതയുള്ള വഴിയാണ്. ഗേറ്റ്വേ വശത്ത് AllowGatewayTransit false എന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന പിയറിംഗ് പാക്കറ്റ് പിടിച്ചെടുക്കാതെ തന്നെ മുഴുവൻ പരാജയവും വിശദീകരിക്കുന്നു.

ക്ലയന്റ് ഇപ്പോഴും എന്ത് സ്വീകരിക്കണം

റൂട്ടിംഗ് ആവശ്യമാണ്, പര്യാപ്തമല്ല, കാരണം പോയിന്റ്-ടു-സൈറ്റ് പ്രൊഫൈൽ ട്രാൻസിറ്റ് പ്രവർത്തിച്ചാൽ ഉത്തരം നൽകുന്ന ഒരു DNS വിലാസവും ക്ലയന്റിന് നൽകണം. പ്ലാറ്റ്ഫോം resolver അല്ല ആ വിലാസം: വെർച്വൽ നെറ്റ്വർക്കുമായി ബന്ധിപ്പിച്ച Azure Private DNS സോണുകൾക്ക് അത് ഉത്തരം നൽകുന്നു, എന്നാൽ നിങ്ങളുടെ സ്വന്തം ഡയറക്ടറി സെർവറുകളിൽ ഹോസ്റ്റ് ചെയ്യുന്ന സോണിന് ഒന്നും നൽകുന്നില്ല, ഈ വിന്യാസം അതാണ് ഉപയോഗിക്കുന്നത്. ഒരു ക്ലയന്റിനെ അതിലേക്ക് ചൂണ്ടിക്കാണിച്ചാൽ പൊതു പേരുകൾ സന്തോഷത്തോടെ പരിഹരിക്കപ്പെടും, ആന്തരിക ഹോസ്റ്റ് അജ്ഞാതമായി തുടരും.

മറ്റെന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ബന്ധിപ്പിച്ച ലാപ്ടോപ്പിൽ നിന്ന് resolver-നോട് ചോദിക്കുക.

nslookup dc01.corp.example 10.1.0.4

സമയപരിധി കഴിഞ്ഞു എന്നത് പാത ഇപ്പോഴും ഇല്ലെന്ന് പറയുന്നു. അധികാരമുള്ള ഉത്തരം പ്രശ്നം ക്ലയന്റിലേക്ക് തിരികെ തള്ളുന്നു, സാധാരണയായി ഒരിക്കലും ചേർക്കാത്ത ഒരു പ്രത്യയം, അതിനാൽ ചെറിയ പേരുകൾ അവയെ സന്തോഷത്തോടെ പരാജയപ്പെടുത്തുന്ന പൊതു resolver-ലേക്ക് യാത്ര ചെയ്യുന്നു.

സൈറ്റ്-ടു-സൈറ്റ് വശത്ത് അതേ കരാർ താരതമ്യം ചെയ്യുക

ഇവയൊന്നും പ്രത്യേകിച്ച് ലാപ്ടോപ്പുകളുടേതല്ല. ക്ലയന്റിനെ സൈറ്റ്-ടു-സൈറ്റിലെ ഒരു ശാഖയാക്കി മാറ്റുക, ഇരുവശ ആവശ്യകത തിരികെ വരുന്നു: ശാഖ നേരിട്ട് ഗേറ്റ്വേ നെറ്റ്വർക്കിൽ എത്തുന്നു, രണ്ട് നെറ്റ്വർക്ക് അകലെയുള്ള ഒരു സേവനം ഇപ്പോഴും പിയറിംഗിന് പിന്നിലാണ്.

ട്രാൻസിറ്റ് രണ്ട് പിയറിംഗുകളിലും നൽകണം, അത് നൽകുന്ന സ്വിച്ച് ക്ലയന്റ് തരത്തിലല്ല, പിയറിംഗിലാണ്.

ഗേറ്റ്വേയെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ്

Windows ഓരോ അഡാപ്റ്ററിനും resolver പട്ടിക സൂക്ഷിക്കുന്നു, അതിനാൽ ഗേറ്റ്വേയെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ടണൽ ഇന്റർഫേസിന് യഥാർത്ഥത്തിൽ എന്ത് ലഭിച്ചു എന്ന് ഉറപ്പാക്കുക.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

നെഗറ്റീവ് ഉത്തരം കാഷെയിൽ റൂട്ടിംഗ് പരിഹാരത്തേക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കുന്നു, പഴയ പ്രത്യയ പട്ടിക സോൺ ഒരിക്കലും ഹോസ്റ്റ് ചെയ്യാത്ത സ്ഥലത്തേക്ക് അന്വേഷണങ്ങൾ അയയ്ക്കുന്നത് തുടരുന്നു. ഫ്ലഷ് ചെയ്യുക, വീണ്ടും ചോദിക്കുക, ഏത് സെർവർ ഉത്തരം നൽകുന്നു എന്ന് രേഖപ്പെടുത്തുക.

പാത നിലനിൽക്കുമോ എന്ന് രണ്ട് ചെറിയ വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു: വിലാസ ഇടങ്ങൾ ഒന്നിനുമേൽ ഒന്ന് വരരുത്, കൂടാതെ resolver-ന്റെ സബ്നെറ്റിലെ നെറ്റ്വർക്ക് സുരക്ഷാ ഗ്രൂപ്പ് ക്ലയന്റ് പൂൾ അനുവദിക്കണം, അത് മറ്റൊരു ഉറവിട ശ്രേണി മാത്രമാണ്. VM വശത്തുനിന്നുള്ള ഫലപ്രദ റൂട്ട് പരിശോധനയും ക്ലയന്റിൽ നിന്നുള്ള ഒരു നേരിട്ടുള്ള അന്വേഷണവും കൊണ്ട് അത് തെളിയിക്കുക, അങ്ങനെ സോൺ പ്രശ്നം, പ്രത്യയ പ്രശ്നം അല്ലെങ്കിൽ ഫിൽട്ടർ ഒരിക്കലും കാണാത്ത ട്രാൻസിറ്റ് ആയി തെറ്റിദ്ധരിക്കപ്പെടാതിരിക്കാൻ.