സ്വകാര്യ DNS നാമമോ അതോ വെറും IP യോ? പങ്കിടുന്നതിന് മുമ്പ് തീരുമാനിക്കുക

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

ആദ്യ വ്യവസ്ഥ: ക്ലയന്റുകൾക്ക് ഏത് resolver പാതയുണ്ട്?

ക്ലയന്റിന്റെ resolver അതിന് ഉത്തരം നൽകാൻ കഴിയുമ്പോൾ മാത്രമേ സ്വകാര്യ നാമം പ്രവർത്തിക്കൂ. അതായത് അധികാരമുള്ള ദൂരസ്ഥ ക്ലയന്റ് സോൺ കൈവശം വയ്ക്കുന്ന DNS സെർവറിൽ എത്തണം, ടണലിലൂടെയോ സംഘടന ഇതിനകം ദൂരസ്ഥ ഉപയോക്താക്കൾക്കായി നടത്തുന്ന resolver വഴിയോ. ടണൽ ഒരു വാഹകമാണ്, ഡയറക്ടറിയല്ല. അത് ക്ലയന്റിന് resolver ലേക്കുള്ള പാത നൽകുന്നു, ഏത് സോൺ ചോദിക്കണം എന്ന് പറയുന്നില്ല.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

ലാപ്ടോപ്പ് VPN ലേക്ക് കണക്ട് ചെയ്തതുകൊണ്ട് പൊതു resolver സ്വകാര്യ സോൺ പഠിക്കില്ല.

പ്രത്യയവും അത്രയും ശ്രദ്ധ അർഹിക്കുന്നു. സംഘടന നിയന്ത്രിക്കുന്ന ഡൊമെയ്നിന്റെ ഉപഡൊമെയ്ൻ ഉപയോഗിക്കുക, ഉടമസ്ഥതയും സർട്ടിഫിക്കറ്റ് ആസൂത്രണവും വ്യക്തമായി നിലനിൽക്കട്ടെ. .local ഒഴിവാക്കുക: മൾട്ടികാസ്റ്റ് DNS സ്പെസിഫിക്കേഷൻ ആ പ്രത്യയത്തെ ലിങ്ക്-ലോക്കൽ പരിഹാരവുമായി ബന്ധിപ്പിക്കുന്നു, റൂട്ട് ചെയ്ത ടണൽ ആ പെരുമാറ്റം നിങ്ങൾക്കായി പുനർനിർമ്മിക്കുന്നില്ല.

രണ്ടാം വ്യവസ്ഥ: സേവനം ഏത് ഉറവിടം സ്വീകരിക്കുന്നു?

ആക്സസ് നിയമങ്ങൾ വിലാസങ്ങൾക്കെതിരെ എഴുതപ്പെടുന്നു, അതിനാൽ ഉപയോഗപ്രദമായ ചോദ്യം റൂട്ടിംഗിനും വിവർത്തനത്തിനും ശേഷം സേവനം ഏത് വിലാസം കാണുന്നു എന്നതാണ്. 10.20.30.40 ലെ ഒരു ഉദാഹരണ സേവനത്തിന്, ഓഫീസ് ക്ലയന്റുകൾ 10.20.30.0/24 ൽ നിന്ന് വരുന്നു, ദൂരസ്ഥ ക്ലയന്റുകൾ 10.99.0.0/24 പോലുള്ള വെവ്വേറെ പൂളിൽ നിന്ന് വരുന്നു.

ഒരു പ്രവേശന കവാടം ദൂരസ്ഥ പൂൾ വിവർത്തനം ചെയ്താൽ, സേവനം വിവർത്തകനെ കാണുന്നു, 10.99.0.0/24 നായി എഴുതിയ നിയമം പൊരുത്തപ്പെടില്ല.

ഇത് ക്ലയന്റിന്റെ ഭാഗത്ത് നിന്നല്ല, സേവനത്തിന്റെ ഭാഗത്ത് നിന്ന് വായിക്കുക. സേവന ഹോസ്റ്റിലെ ശ്രോതാവ് ലോഗ് അല്ലെങ്കിൽ പാക്കറ്റ് ക്യാപ്ചർ യഥാർത്ഥത്തിൽ എത്തിയ ഉറവിടം കാണിക്കുന്നു; ക്ലയന്റിന്റെ സ്വന്തം വിലാസം പാതയിൽ അതിജീവിച്ചതിനെക്കുറിച്ചുള്ള ഒരു ഊഹം മാത്രമാണ്.

മൂന്നാം വ്യവസ്ഥ: പേര് സേവനവുമായി ബന്ധപ്പെട്ടതാണോ ഹോസ്റ്റുമായി ബന്ധപ്പെട്ടതാണോ?

ഒരു യന്ത്രത്തിന്റെ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന പേര് ഓരോ ക്ലയന്റിനെയും ആ യന്ത്രവുമായി ബന്ധിക്കുന്നു. ലോഡ് ബാലൻസറിലേക്കോ സ്ഥിരമായ സേവന വിലാസത്തിലേക്കോ ചൂണ്ടുന്ന പേര് അതിന് പിന്നിലെ ഹോസ്റ്റിന്റെ മാറ്റത്തെ അതിജീവിക്കുന്നു. സബോധപൂർവ്വം തിരഞ്ഞെടുക്കുക, കാരണം ഇത് പിന്നീട് മാറ്റുന്നത് ഓരോ ക്ലയന്റിന്റെയും ബുക്ക്മാർക്കുകളും ഓരോ സർട്ടിഫിക്കറ്റിന്റെയും വിഷയവും മാറ്റുന്നു.

ഒരു ആന്തരിക സേവനത്തിന്, നേരിട്ടുള്ള റെക്കോർഡ് സാധാരണയായി മതിയാകും, ചിന്തിക്കാൻ എളുപ്പവുമാണ്.

മാറ്റിസ്ഥാപിക്കപ്പെടുകയോ പുനർനിർമ്മിക്കപ്പെടുകയോ സ്കെയിൽ ചെയ്യപ്പെടുകയോ ചെയ്യുന്ന എന്തിനും, സ്ഥിരമായ മുൻഭാഗം അധിക കോൺഫിഗറേഷന് അർഹതയുള്ളതാണ്. പരിശോധന ലളിതമാണ്: ഉപയോക്താക്കളോട് പറയാതെ നിങ്ങൾക്ക് ബാക്കെൻഡ് മാറ്റിസ്ഥാപിക്കാൻ കഴിയുമെങ്കിൽ, പേര് സേവനവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു; കഴിയുന്നില്ലെങ്കിൽ, അത് ഹോസ്റ്റുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു.

രണ്ട് തീരുമാനങ്ങളും വെവ്വേറെ പരിശോധിക്കുക

ആദ്യം പരിഹരിക്കുക, തുടർന്ന് കണക്ട് ചെയ്യുക. പ്രതീക്ഷിച്ച വിലാസം തിരികെ നൽകുന്ന പരിഹാര പരിശോധന പേരിന്റെ പാത തെളിയിക്കുന്നു, ആക്സസിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. കണക്ഷൻ പരിശോധന പാതയും നിയമവും ഒരുമിച്ച് തെളിയിക്കുന്നു, അതിനാൽ പരിഹാരം വിജയിച്ചതിന് ശേഷം മാത്രം അത് പ്രവർത്തിപ്പിക്കുക.

curl -sv --max-time 5 https://files.corp.example/health

തുടർന്ന് ഒരു വിലക്കപ്പെട്ട ഉറവിടം ഒരിക്കൽ പരിശോധിക്കുക, ഫലം രേഖപ്പെടുത്തുക.

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

തീരുമാനം സാധാരണയായി എവിടെ തെറ്റുന്നു

സാധാരണ പരാജയം, ഓഫീസ് ശൃംഖലയിൽ മാത്രം പരിഹരിക്കപ്പെടുന്ന പേരിന് കീഴിൽ പ്രസിദ്ധീകരിച്ച സേവനവും ഓഫീസ് ശ്രേണി മാത്രം സ്വീകരിക്കുന്ന ആക്സസ് നിയമവുമാണ്. അപ്പോൾ ദൂരസ്ഥ ഉപയോക്താക്കൾ തകർന്ന സേവനത്തെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്യുന്നു, അത് യഥാർത്ഥത്തിൽ രണ്ട് വെവ്വേറെ വീഴ്ചകളാണ്. രണ്ടാമത്തെ സാധാരണ പരാജയം വിപരീതമാണ്: പേരിന്റെ പ്രശ്നം ഒഴിവാക്കാൻ ചേർത്ത വിശാലമായ ആക്സസ് നിയമം, ആരും ഉദ്ദേശിക്കാത്ത ഉറവിടങ്ങളിൽ നിന്ന് സേവനം എത്താവുന്നതായി നിലനിർത്തുന്നു. രണ്ടും കോൺഫിഗറേഷൻ വീഴ്ചകളാണ്, ഉപയോക്താവിന്റെ കസേരയിൽ നിന്ന് അവ ഒരുപോലെ തോന്നുന്നു.

ഒരു വിജയകരമായ പരിശോധനയിൽ നിന്ന് ഒരു തെറ്റും കാണാനാവില്ല. അതുകൊണ്ടാണ് രണ്ട് തീരുമാനങ്ങൾക്കും വെവ്വേറെ റെക്കോർഡുകളും വെവ്വേറെ പരിശോധനകളും അർഹതയുള്ളത്, ഒരേ വ്യക്തി രണ്ടും എടുക്കുമ്പോഴും.

സേവനം പ്രവർത്തനക്ഷമമാകുന്നതിന് മുമ്പ് രണ്ടും എഴുതിവയ്ക്കുക, അടുത്ത മാറ്റത്തെക്കുറിച്ച് ചിന്തിക്കാൻ എളുപ്പമാകും. റെക്കോർഡ് ചെറുതാണ്: പേരിനും അതിന്റെ സോണിനും ഒരു വരി, സ്വീകരിച്ച ഉറവിടങ്ങൾക്കും നിയമത്തിന്റെ ഉടമയ്ക്കും ഒരു വരി.