VPN-ൽ Azure സ്വകാര്യ DNS: റിസോൾവർ എൻഡ്പോയിന്റ് അതോ ഫോർവേഡർ
രണ്ട് ഡിസൈനുകളും ടണലിലൂടെ സ്വകാര്യ സോണുകൾക്ക് ഉത്തരം നൽകുന്നു. മാനേജ്ഡ് ഇൻബൗണ്ട് എൻഡ്പോയിന്റിനെ ഫോർവേഡർ VM-മായി താരതമ്യം ചെയ്ത്, ഇരു സാഹചര്യങ്ങളിലും ഉണ്ടായിരിക്കേണ്ട പാത പരിശോധിക്കുക.
ഓൺ-പ്രെമിസിലെ ഒരു സെർവർ സ്വകാര്യ വിലാസത്തിലൂടെ Azure VM-ൽ എത്തുന്നു, എന്നിട്ടും അതിന്റെ സ്വകാര്യ ഹോസ്റ്റ്നെയിം പരിഹരിക്കാനാകുന്നില്ല, ഇത് ആളുകളെ തകർന്ന ടണൽ തിരയാൻ അയയ്ക്കുന്നു. ടണൽ കുഴപ്പമില്ല. ഇല്ലാത്തത് ഒരു DNS അതിർത്തിയാണ്: ഓൺ-പ്രെമിസ് ഭാഗത്ത് ഒരു നിർദ്ദിഷ്ട Azure സ്വകാര്യ സോണിന് VNet-നുള്ളിലെ റിസോൾവർ ഉത്തരം നൽകണമെന്ന് ആർക്കും അറിയില്ല. രണ്ട് ഡിസൈനുകൾ ഈ വിടവ് അടയ്ക്കുന്നു, അവ അവസാനം നിങ്ങൾ എന്ത് പ്രവർത്തിപ്പിക്കുന്നു എന്നതിൽ വ്യത്യസ്തമാണ്, ക്വറികൾ പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതിലല്ല.
ടണൽ ക്വറികൾ കൊണ്ടുപോകുന്നു, സോൺ അറിവല്ല
സൈറ്റ്-ടു-സൈറ്റ് കണക്ഷൻ പാക്കറ്റുകൾക്ക് രണ്ട് നെറ്റ്വർക്കുകൾക്കിടയിൽ ഒരു റൂട്ട് നൽകുന്നു. ഏത് നെയിംസ്പേസ് Azure-ന്റേതാണ് അല്ലെങ്കിൽ ഏത് വിലാസം ഉത്തരം നൽകണം എന്ന് അത് ഓൺ-പ്രെമിസ് DNS സെർവറിനോട് പറയുന്നില്ല, അതിനാൽ ക്വറി ഒന്നുകിൽ ഇന്റർനെറ്റിലേക്ക് പോയി ശൂന്യമായി മടങ്ങുന്നു, അല്ലെങ്കിൽ ലോക്കൽ റിസോൾവർ ഒരിക്കലും വിടുന്നില്ല.
പരിഹാരത്തിന് എളുപ്പത്തിൽ വേർതിരിക്കാവുന്ന രണ്ട് പകുതികളുണ്ട്. ഒരു പകുതി ടണലിലൂടെ വരുന്ന ക്വറികൾ സ്വീകരിക്കുന്ന VNet-നുള്ളിലെ റിസോൾവർ ആണ്. മറ്റേത് ഓൺ-പ്രെമിസ് ഭാഗത്തുള്ള സോപാധിക ഫോർവേഡർ ആണ്, അത് കൃത്യമായി ഒരു നെയിംസ്പേസ് ആ റിസോൾവറിലേക്ക് അയയ്ക്കുന്നു. ഒരു പകുതിക്കും ഒറ്റയ്ക്ക് പ്രവർത്തിക്കാനാവില്ല.
ഈ വിശദീകരണത്തിന്റെ ബാക്കി ഭാഗത്തിന് സോൺ cloud.corp.example ആണെന്ന് കരുതുക, ഓരോ വിലാസവും ഉദാഹരണമായി കാണുക.
ഓപ്ഷൻ A: മാനേജ്ഡ് ഇൻബൗണ്ട് എൻഡ്പോയിന്റ്
Azure DNS Private Resolver VNet-ന് പുറത്തുനിന്നുള്ള DNS ക്വറികൾ സ്വീകരിക്കുന്ന ഒരു ഇൻബൗണ്ട് എൻഡ്പോയിന്റ് നൽകുന്നു. നിങ്ങൾ അത് സമർപ്പിത ഡെലിഗേറ്റഡ് സബ്നെറ്റിൽ വിന്യസിക്കുന്നു, സ്വകാര്യ സോൺ ആ VNet-മായി ലിങ്ക് ചെയ്യുന്നു, സേവനം നൽകുന്ന ഇൻബൗണ്ട് വിലാസം കുറിച്ചെടുക്കുന്നു.
തുടർന്ന് ഓൺ-പ്രെമിസ് DNS സെർവറിൽ കൃത്യമായ നെയിംസ്പേസിനായി ആ വിലാസത്തിലേക്ക് ഒരു സോപാധിക ഫോർവേഡർ സൃഷ്ടിക്കുന്നു:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft-ന്റെ ഹൈബ്രിഡ് DNS നടപടിക്രമം സോൺ ലിങ്കും ഫോർവേഡർ ഘട്ടവും രേഖപ്പെടുത്തുന്നു. മാനേജ്ഡ് പാതയിൽ പാച്ച് ചെയ്യാൻ DNS സോഫ്റ്റ്വെയർ ബാക്കിയാകുന്നില്ല, എൻഡ്പോയിന്റ് വിലാസം വിഭവത്തിന്റെ മുഴുവൻ ആയുസ്സിലും സ്ഥിരമായി നിലനിൽക്കുന്നു.
വില അതാണ്: ഇപ്പോൾ നിങ്ങൾക്ക് ഒരു റിസോൾവർ വിഭവവും അതിന്റെ സബ്നെറ്റ് ഡെലിഗേഷനും ചെലവും ഉണ്ട്, ക്വറി അളവ് വളരെ കുറവാണെങ്കിലും ഇത് യാഥാർത്ഥ്യമാണ്.
ഓപ്ഷൻ B: VNet-നുള്ളിലെ ഫോർവേഡർ VM
പഴയ ഡിസൈൻ VNet-ലെ സാധാരണ VM-ൽ DNS സോഫ്റ്റ്വെയർ പ്രവർത്തിപ്പിക്കുന്നു: Windows DNS, BIND അല്ലെങ്കിൽ dnsmasq, സ്വകാര്യ സോൺ ഒന്നുകിൽ പ്രാദേശികമായി ഹോസ്റ്റ് ചെയ്യുന്നു, അല്ലെങ്കിൽ 168.63.129.16-ലെ Azure റിസോൾവറിലേക്ക് ഫോർവേഡ് ചെയ്യുന്നു. ഓൺ-പ്രെമിസ് സോപാധിക ഫോർവേഡർ ആ VM-ന്റെ സ്വകാര്യ വിലാസത്തിലേക്ക് ചൂണ്ടുന്നു.
ഇതിനകം DNS സെർവറുകൾ പ്രവർത്തിപ്പിക്കുന്ന ടീമുകൾക്ക് ഈ ഓപ്ഷൻ പരിചിതമാണ്, ലോഗിംഗ് അല്ലെങ്കിൽ സ്പ്ലിറ്റ്-ഹൊറൈസൺ ഉത്തരങ്ങൾ പോലുള്ള അധിക ലോജിക് ഇതിന് വഹിക്കാനാകും. ഒപ്പം DNS സെർവറിന്റെ എല്ലാ പ്രവർത്തന ചുമതലകളും ഇത് അനുഭവിക്കുന്നു: പാച്ചിംഗ്, ലഭ്യതയ്ക്കായി രണ്ടാമത്തെ ഇൻസ്റ്റൻസ്, നിരീക്ഷണം, VM മാറ്റുകയും അതിന്റെ വിലാസം മാറുകയും ചെയ്യുമ്പോൾ പുനർനിർമ്മാണ പാത.
സാധാരണ VNet ഹോസ്റ്റ്, സേവനം ഇൻസ്റ്റാൾ ചെയ്യുകയും ആ ക്ലയന്റുകൾക്ക് ഉത്തരം നൽകാൻ അനുവാദം ലഭിക്കുകയും ചെയ്യുന്നതുവരെ DNS പ്രോക്സി അല്ല, VM ക്ലോൺ ചെയ്യുമ്പോൾ ആളുകൾ ഒഴിവാക്കുന്ന ഘട്ടം അതാണ്.
ഏതാണ് നിങ്ങളുടെ പ്രവർത്തനത്തിന് അനുയോജ്യം
താരതമ്യം ഏത് ഡിസൈൻ വേഗത്തിലാണ് എന്നതല്ല. DNS സോഫ്റ്റ്വെയർ പ്രവർത്തിപ്പിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുണ്ടോ എന്നതും, ക്വറി അളവ് എൻഡ്പോയിന്റും ക്വറിയും അനുസരിച്ച് ബിൽ ചെയ്യുന്ന മാനേജ്ഡ് വിഭവത്തെ ന്യായീകരിക്കുന്നുണ്ടോ എന്നതുമാണ്.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
ഏത് വരി തീരുമാനിച്ചാലും, ഓൺ-പ്രെമിസ് ഫോർവേഡർ നിയമം ഒരുപോലെ കാണപ്പെടുന്നു. ഈ ഭാഗം രണ്ട് ഡിസൈനുകളിലും ഉണ്ടായിരിക്കണം, Azure-നുള്ളിൽനിന്ന് പരിഹാരം പ്രവർത്തിക്കുന്നു പക്ഷേ ഓഫീസിൽനിന്ന് പ്രവർത്തിക്കുന്നില്ല എന്ന് ആരെങ്കിലും റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ഏറ്റവും കൂടുതൽ കാണാതെ പോകുന്ന ഭാഗവും ഇതുതന്നെ.
പാത ക്രമത്തിൽ പരിശോധിക്കുക
സോൺ റിസോൾവർ ഉള്ള VNet-മായി ലിങ്ക് ചെയ്തിട്ടുണ്ടെന്നും ഓൺ-പ്രെമിസ് ഫോർവേഡർ പാരന്റ് ഡൊമെയ്നല്ല, നെയിംസ്പേസ് പേരിടുന്നുണ്ടെന്നും ഉറപ്പാക്കുക. corp.example-നുള്ള ഫോർവേഡർ, റിസോൾവർ തന്നെ ഡെലിഗേറ്റ് ചെയ്യുന്നില്ലെങ്കിൽ cloud.corp.example-മായി പൊരുത്തപ്പെടില്ല, ഈ പൊരുത്തക്കേട് കാണാത്ത റെക്കോർഡ് പോലെ തോന്നിക്കുന്ന വ്യക്തമായ നിഷേധാത്മക ഉത്തരം നൽകുന്നു.
തുടർന്ന് ക്വറി എൻഡ്പോയിന്റിൽ എത്തുന്നുണ്ടെന്ന് പരിശോധിക്കുക: ഓൺ-പ്രെമിസ് ഉറവിടത്തിന് റിസോൾവർ വിലാസത്തിലേക്കുള്ള റൂട്ടും തിരിച്ചുള്ള പാതയും വേണം, നയം അനുവദിക്കുന്നിടത്ത് UDP, TCP എന്നിവയ്ക്ക് പോർട്ട് 53 തുറന്നിരിക്കണം. NSG-ക്ക് കാണാത്ത സോൺ റെക്കോർഡ് നൽകാനാവില്ല, ശരിയായ സോണിനും ഒരിക്കലും എത്താത്ത ക്വറിക്ക് ഉത്തരം നൽകാനാവില്ല.
രോഗനിർണയം നടത്തുമ്പോൾ ആവശ്യപ്പെട്ട FQDN തിരഞ്ഞെടുത്ത റിസോൾവറിന്റെ അടുത്ത് സൂക്ഷിക്കുക, ടൈംഔട്ടും നിഷേധാത്മക ഉത്തരവും വേർതിരിക്കുക. ടൈംഔട്ട് പാതയുടെയോ നയത്തിന്റെയോ പ്രശ്നമാണ്. നിഷേധാത്മക ഉത്തരം എന്നാൽ ക്വറി എത്തി, നെയിംസ്പേസ് പൊരുത്തപ്പെട്ടില്ല. ജോലിയുടെ ക്രമം: സോൺ ലിങ്ക് ചെയ്യുക, സോപാധിക ഫോർവേഡർ ചേർക്കുക, പോർട്ട് 53 ഇരു ദിശകളിലും തുറക്കുക, ഓൺ-പ്രെമിസിൽനിന്ന് ഒരു പേര് പരീക്ഷിക്കുക, അതിനുശേഷം മാത്രം ആപ്ലിക്കേഷന്റെ സ്വന്തം അനുമതി നോക്കുക.