വിഭജിത DNS-ഉം VPN-ഉം: ഡൊമെയ്ൻ നിയമങ്ങൾ IP റൂട്ടുകളല്ല
വിഭജിത DNS പേരനുസരിച്ച് റിസോൾവർ തിരഞ്ഞെടുക്കുന്നു, ഉത്തരത്തിന് ഇപ്പോഴും പാത വേണം. ഡൊമെയ്ൻ നിയമവും പാതയും വെവ്വേറെ, നിങ്ങൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന പ്ലാറ്റ്ഫോമിൽ പരിശോധിക്കുക.
നിങ്ങളുടെ ലാപ്ടോപ്പ് intranet.corp ടണലിലൂടെ പരിഹരിക്കുമ്പോൾ gitlab.com സേവനദായകരുടെ റിസോൾവറിലേക്ക് തുടർന്നും പോകുന്നു, ഇത് രൂപകൽപ്പന അനുസരിച്ച് പ്രവർത്തിക്കുന്ന ക്രമീകരണമാണ്. രണ്ട് വേർതിരിഞ്ഞ തീരുമാനങ്ങളാണ് ഇത് സൃഷ്ടിച്ചത്: പേര് പൊരുത്തപ്പെടുത്തൽ നിയമം റിസോൾവർ തിരഞ്ഞെടുത്തു, പാത ഉത്തരം തിരികെ കൊണ്ടുവന്നു. ഏതെങ്കിലും ഒന്ന് തകർന്നാൽ ബ്രൗസർ പുറത്തുനിന്ന് ഒരുപോലെ കാണുന്ന പരാജയം കാണിക്കും. വിഭജിത DNS സംബന്ധിച്ച റിപ്പോർട്ടുകളിൽ ഭൂരിഭാഗവും രണ്ടാമത്തെ പരാജയം വിവരിക്കുമ്പോൾ ആദ്യത്തേതിനെക്കുറിച്ചുള്ള തെളിവ് ഉദ്ധരിക്കുന്നു.
രണ്ട് പകുതികളും വ്യത്യസ്ത സ്ഥലങ്ങളിലാണ് ജീവിക്കുന്നത്, സാധാരണയായി വ്യത്യസ്ത ആളുകൾ അവ എഡിറ്റ് ചെയ്യുന്നു. ഒന്ന് VPN പ്രൊഫൈലിൽ ഘടിപ്പിച്ച DNS നയമാണ്, മറ്റൊന്ന് ടണൽ ഇൻസ്റ്റാൾ ചെയ്യുന്നതോ തടഞ്ഞുനിർത്തുന്നതോ ആയ റൂട്ടാണ്. ഏത് പകുതിയാണ് യഥാർത്ഥത്തിൽ നീങ്ങിയതെന്ന് ആരും നിർണ്ണയിക്കാത്തപ്പോൾ ഡീബഗ്ഗിംഗ് നിലയ്ക്കുന്നു.
ഒരു അഭ്യർത്ഥനയിൽ ഒളിഞ്ഞിരിക്കുന്ന രണ്ട് തീരുമാനങ്ങൾ
പേരിന്റെ പകുതി ഒരു നയ വസ്തുവാണ്, റൂട്ടല്ല. Windows-ൽ ഇത് VPN പ്രൊഫൈലിലെ പേര് പരിഹാര നയമാണ്; Apple പ്ലാറ്റ്ഫോമുകളിൽ DNS ക്രമീകരണ വസ്തുവിലെ പൊരുത്തപ്പെടുന്ന ഡൊമെയ്നുകളുടെ കൂട്ടം; Linux-ൽ റൂട്ടിംഗ് ഡൊമെയ്ൻ, വിഭജിത റിസോൾവർ വരി അല്ലെങ്കിൽ പേര് സേവന സ്വിച്ചിന്റെ ക്രമം. പാതയുടെ പകുതി സാധാരണ റൂട്ടിംഗാണ്, ടണലോ കൈകൊണ്ടോ ഇൻസ്റ്റാൾ ചെയ്യുന്നത്, ഹോസ്റ്റ്നാമം എന്താണെന്ന് അതിന് അറിയില്ല. ഒരു പ്രത്യയം അനുവദിക്കുന്ന പ്രൊഫൈൽ ആരാണ് ഉത്തരം നൽകുന്നതെന്ന് മാത്രം തീരുമാനിക്കുന്നു; അത് ഉത്തരം ഒരിക്കലും എത്താവുന്നതാക്കുന്നില്ല.
വേഗത്തിലുള്ള ലക്ഷണ പരിശോധന അവയെ വേർതിരിക്കുന്നു: പേരിന്റെ സ്ഥാനത്ത് ഒരു വിലാസം ഇടുക. വിലാസം പ്രവർത്തിക്കുന്നുവെങ്കിൽ പാത ശരിയാണ്, നിയമം തെറ്റാണ്. വിലാസവും പരാജയപ്പെട്ടാൽ നിയമം ശരിയാകാം, പാത ഇല്ലായിരിക്കാം.
ഓരോ പ്ലാറ്റ്ഫോമും ഒരേ പേര് നിയമം എങ്ങനെ പ്രകടിപ്പിക്കുന്നു
ഉദ്ദേശ്യം ഒന്നുതന്നെ, ഫീൽഡ് നാമങ്ങൾ അല്ല. ഒരു ക്ലയന്റിൽ നിന്ന് മറ്റൊന്നിലേക്ക് പകർത്തിയ ഉദാഹരണം വ്യക്തമായി പാഴ്സ് ചെയ്യപ്പെടുന്നു, ഒരിക്കലും പൊരുത്തപ്പെടുന്നില്ല. മൂന്ന് രൂപങ്ങൾ ഇങ്ങനെയാണ്:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
പൊരുത്തപ്പെടുത്തൽ അല്ലെങ്കിൽ റൂട്ടിംഗ് ഡൊമെയ്ൻ ഒരു പ്രത്യയ പരിശോധനയാണ്, അതിനാൽ intranet.corp git.intranet.corp ഉൾക്കൊള്ളുന്നു, corp.intranet ഉൾക്കൊള്ളുന്നില്ല, അത് തലതിരിച്ച് ചെയ്യുന്നതാണ് മുഴുവൻ ക്രമീകരണത്തിലെയും ഏറ്റവും സാധാരണ തെറ്റ്. Windows മാപ്പിംഗ് പ്രൊഫൈലിൽ ഘടിപ്പിച്ച പേര് പരിഹാര നയമായി വഹിക്കുന്നു, ഇന്റർഫേസിന് ഇതിനകം ഉണ്ടായിരുന്ന ഏതൊരു പ്രത്യയ പട്ടികയ്ക്കുമെതിരെ സ്വന്തം മുൻഗണനാ ക്രമത്തോടെ. Apple പ്ലാറ്റ്ഫോമുകൾ പൊരുത്തപ്പെടുന്ന ഡൊമെയ്നുകൾ നെറ്റ്വർക്ക് എക്സ്റ്റൻഷന്റെ DNS ക്രമീകരണ വസ്തുവിൽ ഘടിപ്പിക്കുന്നു, സിസ്റ്റം അവ ഓരോ പരിധിയുള്ള റിസോൾവറിനും പ്രയോഗിക്കുന്നു. ഈ രൂപങ്ങളിലൊന്നും റൂട്ടല്ല, ഒന്നിനും എത്താൻ കഴിയാത്ത വിലാസത്തെ എത്താവുന്നതാക്കാനാവില്ല. Windows പേര് പരിഹാര നയം റഫറൻസ് ആ പ്ലാറ്റ്ഫോമിന്റെ ഫീൽഡ് നാമങ്ങളും മുൻഗണനാ നിയമങ്ങളും പട്ടികപ്പെടുത്തുന്നു, അവ Apple അല്ലെങ്കിൽ systemd രേഖകൾ ഉപയോഗിക്കുന്ന നിയമങ്ങളല്ല.
ശരിയായ ഉത്തരത്തിനും ഇപ്പോഴും പാത വേണം
റിസോൾവറിന്റെ ഉത്തരം ഒരു വിലാസം മാത്രമാണ്, ആപ്ലിക്കേഷൻ ഇപ്പോഴും അവിടെ എത്തണം. വിഭജിത ടണൽ രൂപകൽപ്പന പലപ്പോഴും 10.20.0.0/16 തള്ളുന്നു, സ്ഥിരസ്ഥിതി റൂട്ട് തടഞ്ഞുനിർത്തുന്നു, അതിനാൽ ആന്തരിക നാമം പരിഹരിക്കപ്പെടുന്നു, പിന്നീട് കണക്ഷൻ തൂങ്ങുന്നു. വിപരീത സാഹചര്യവും അത്രതന്നെ സാധാരണമാണ്: റൂട്ട് ഉണ്ട്, പൊതു റിസോൾവർ സ്വകാര്യ നാമത്തിന് NXDOMAIN നൽകുന്നു, പരാജയം റൂട്ടിംഗ് പ്രശ്നമായി രേഖപ്പെടുത്തുന്നു. ആദ്യം പാത പരിശോധിച്ചാൽ ഒരിക്കലും പരിഹരിക്കപ്പെടാത്ത ഒരു പേരിന്റെ റൂട്ടുകളിലേക്ക് നോക്കിയിരിക്കും.
ഏത് പകുതിയും ഉൾക്കൊള്ളാത്ത മൂന്നാമതൊരു കവാടവുമുണ്ട്. ഗേറ്റ്വേയിലെ ACL, ഫയർവാൾ നിയമം അല്ലെങ്കിൽ ക്ലയന്റ് വശത്തെ നയം രണ്ട് തീരുമാനങ്ങളും ശരിയായതിന് ശേഷവും കണക്ഷൻ വീഴ്ത്താം. പേര് പരിഹരിക്കപ്പെടുകയും റൂട്ട് ഉണ്ടാകുകയും ചെയ്തിട്ടും കണക്ഷൻ സമയം കഴിയുന്നുവെങ്കിൽ DNS പരിശോധിക്കുന്നത് നിർത്തുക.
നിശ്ചിത ക്രമത്തിൽ പേരുകളും പാതകളും പരിശോധിക്കുക
ഒരു ക്രമം തിരഞ്ഞെടുത്ത് അത് പാലിക്കുക, അല്ലാത്തപക്ഷം അവസാനം പരാജയപ്പെട്ട ഘട്ടത്തെ പിന്തുടരും. രേഖപ്പെടുത്തിയ പൂർണ്ണ ആന്തരിക നാമം പരിഹരിക്കുക, ഉത്തരം റൂട്ട് പട്ടിക വഹിക്കാവുന്ന വിലാസമാണെന്ന് ഉറപ്പാക്കുക, പിന്നീട് പൊതു നാമത്തോടെ ആവർത്തിച്ച് ടണൽ എല്ലാം പിടിച്ചില്ലെന്ന് തെളിയിക്കുക. systemd ഹോസ്റ്റിൽ ചോദ്യവും റിസോൾവറിന്റെ റൂട്ടിംഗ് ഡൊമെയ്നും ഒരു കമാൻഡ് അകലെയാണ്:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows ക്ലയന്റ് അതേ രണ്ട് ചോദ്യങ്ങൾ വേറെ cmdlet ഉപയോഗിച്ച് ചോദിക്കുന്നു. രണ്ടാമത്തേത് സിസ്റ്റം യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഇന്റർഫേസ് റിപ്പോർട്ട് ചെയ്യുന്നു:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10തിരയൽ വിലാസം തിരികെ നൽകുകയും പാത പരിശോധന ഭൗതിക ഇന്റർഫേസ് പേരിടുകയും ചെയ്താൽ പേര് നിയമം പ്രവർത്തിച്ചു, റൂട്ട് ഇല്ല. ചെറിയ പേര് പരാജയപ്പെടുകയും പൂർണ്ണ നാമം പരിഹരിക്കപ്പെടുകയും ചെയ്താൽ പ്രത്യയ പട്ടികയാണ് തെറ്റ്, റിസോൾവറല്ല.
താരതമ്യം സാധാരണയായി പിഴയ്ക്കുന്നിടം
ആദ്യ തെറ്റ് ബന്ധമില്ലാത്ത പൊതു റിസോൾവറിനോട് സ്വകാര്യ നാമത്തെക്കുറിച്ച് ചോദിക്കുകയും നിരസിക്കലിനെ VPN-നെക്കുറിച്ചുള്ള തെളിവായി വായിക്കുകയും ചെയ്യുന്നതാണ്. രണ്ടാമത്തേത് പ്രവർത്തിക്കുന്ന പൊതു തിരയൽ ടണലിന്റെ റിസോൾവർ പാത തെളിയിക്കുന്നുവെന്ന് അനുമാനിക്കുന്നതാണ്. മൂന്നാമത്തേത് വിഭജിത ടണലിംഗും വിഭജിത DNS-ഉം ഒരു രൂപകൽപ്പന തീരുമാനമായി കാണുന്നതാണ്, ഒരു വിന്യാസം ഒന്നിൽ ശരിയും മറ്റൊന്നിൽ തകർന്നതുമാകാം. ഓരോ തെറ്റും കുറ്റപ്പെടുത്തിയ ഭാഗം ഒരിക്കലും അഭ്യസിക്കാത്ത ഒരു പരിശോധനയിൽ നിന്ന് ആത്മവിശ്വാസമുള്ള നിഗമനങ്ങൾ നൽകുന്നു.
സ്വന്തം സുരക്ഷിത DNS ഉള്ള ബ്രൗസറിനും സിസ്റ്റം നിയമം മറികടക്കാം, അതുകൊണ്ട് ഒരു ബ്രൗസർ പരാജയപ്പെടുമ്പോൾ മറ്റൊന്ന് വിജയിക്കുന്നത് വൈരുദ്ധ്യമല്ല. ഉത്തരം നൽകിയ റിസോൾവറിനെ താരതമ്യം ചെയ്യുക, പരാതിപ്പെട്ട ബ്രൗസറിനെയല്ല.
രണ്ട് പകുതികളും ദൃശ്യമായാൽ ബാക്കിയുള്ള ചോദ്യം സാങ്കേതികമല്ല, നയപരമാണ്: ഏത് പേരിട മേഖലകളാണ് സംഘടനയുടേത്, ഓരോ ഉത്തരത്തിന്റെയും ഉടമ ആരാണ്, അവയിൽ ഏതാണ് യന്ത്രം വിട്ടുപോകേണ്ടത്. അത് പ്രൊഫൈലിനടുത്ത് എഴുതിവയ്ക്കുക, കാരണം നിയമം തൊടുന്ന അടുത്ത ആൾക്ക് അത് ആവശ്യമാകും.