VPN-ൽ ആന്തരിക ഹോസ്റ്റ്നാമങ്ങൾ dig-ൽ എന്തുകൊണ്ട് പരിഹരിക്കപ്പെടുന്നു എന്നാൽ curl-ൽ പരാജയപ്പെടുന്നു
dig മറുപടി നൽകുന്നു, പക്ഷേ curl ഹോസ്റ്റ് പരിഹരിക്കാനാകുന്നില്ലെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. രണ്ട് തിരയൽ ശൃംഖലകളും താരതമ്യം ചെയ്ത്, പിന്നീട് nsswitch, ലിങ്ക് അനുസരിച്ചുള്ള DNS അല്ലെങ്കിൽ തെറ്റായ തിരയൽ പ്രത്യയം ശരിയാക്കുക.
നിങ്ങളുടെ ലാപ്ടോപ്പ് VPN-ലാണ്, dig service.internal.example 10.x വിലാസത്തോടെ മറുപടി നൽകുന്നു, curl ഇപ്പോഴും Could not resolve host ഉപയോഗിച്ച് പുറത്തുവരുന്നു. ടണൽ പ്രശ്നമല്ല: അത് dig ചോദ്യം പരാതിയില്ലാതെ എത്തിച്ചു. വ്യത്യാസം ചോദ്യം ആര് ചോദിക്കുന്നു എന്നതിലാണ്. dig നിങ്ങൾ പേരിടുന്ന ഒരു സെർവറിലേക്ക് ഒരു ചോദ്യം അയയ്ക്കുന്നു, എന്നാൽ curl ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ തിരയൽ ശൃംഖലയിലൂടെ കടന്നുപോകുന്നു, ആ ശൃംഖലയ്ക്ക് ഏത് സെർവറിനോട് ചോദിക്കണം എന്നതിനെക്കുറിച്ച് സ്വന്തം നിയമങ്ങളുണ്ട്.
ഒരേ പേരിനായി രണ്ട് തിരയലുകൾ
dig അതിന്റേതായ stub resolver ആണ്. അത് /etc/resolv.conf വായിക്കുന്നു, ഒരു നെയിം സെർവർ തിരഞ്ഞെടുക്കുന്നു, ഒരു A അല്ലെങ്കിൽ AAAA ചോദ്യം അയച്ച് മറുപടി പ്രിന്റ് ചെയ്യുന്നു. അത് nsswitch പൂർണ്ണമായും ഒഴിവാക്കുന്നു, systemd-resolved അല്ലെങ്കിൽ NetworkManager ആ ഫയലിന് പുറത്ത് സൂക്ഷിക്കുന്ന ലിങ്ക് അനുസരിച്ചുള്ള അവസ്ഥയെക്കുറിച്ച് ഒന്നുമറിയില്ല, അതുകൊണ്ടാണ് dig മറുപടി ശരിയായിരിക്കാമെങ്കിലും നിങ്ങളുടെ അപ്ലിക്കേഷൻ എന്ത് കാണും എന്നതിനെക്കുറിച്ച് ഒന്നും പറയാതിരിക്കുന്നത്.
അപ്ലിക്കേഷനുകൾ getaddrinfo വിളിക്കുന്നു, getaddrinfo നീണ്ട ശൃംഖലയിലൂടെ കടന്നുപോകുന്നു: nsswitch മൊഡ്യൂളുകളുടെ ക്രമം, പിന്നീട് പേര് കൈകാര്യം ചെയ്യുന്ന മൊഡ്യൂൾ, അവസാനം നിലവിലെ ലിങ്ക് കോൺഫിഗറേഷനിൽ നിന്ന് നിർമ്മിച്ച resolver. systemd യന്ത്രത്തിൽ ചോദ്യം 127.0.0.53-ലേക്ക് പോകുന്നു, tun ഇന്റർഫേസുമായി ബന്ധിപ്പിച്ച റൂട്ടിംഗ് ഡൊമെയ്ൻ അടിസ്ഥാനമാക്കി systemd-resolved ഓരോ ലിങ്കിനും മുകളിലെ സെർവർ തിരഞ്ഞെടുക്കുന്നു.
രണ്ട് കമാന്റുകൾ ഈ പാളികളെ ഊഹിക്കാതെ വേർതിരിക്കുന്നു:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent curl സ്വീകരിക്കുന്ന അതേ വഴി സ്വീകരിക്കുന്നു, അതിനാൽ പ്രവർത്തിക്കുന്ന dig-ന്റെ അടുത്ത് getent പരാജയപ്പെടുന്നത് തകരാറിനെ പാക്കറ്റ് റൂട്ടിംഗിലല്ല, തിരയൽ നയത്തിൽ കണ്ടെത്തുന്നു. resolvectl query മറുപടി നൽകിയ ഇന്റർഫേസും മുകളിലെ സെർവറും പ്രിന്റ് ചെയ്യുന്നു, ഇത് ടണലിന്റെ ലിങ്കോ ഭൗതിക ലിങ്കോ വിജയിച്ചു എന്ന് കാണിക്കുന്നു.
അപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന resolver വായിക്കുക
/etc/resolv.conf മിക്ക ഡെസ്ക്ടോപ്പുകളിലും ഉത്പാദിപ്പിക്കപ്പെടുന്നു, VPN ക്ലയന്റിന് അത് കൈകാര്യം ചെയ്യാൻ മൂന്ന് വഴികളുണ്ട്: നെയിം സെർവർ മുന്നിൽ ചേർക്കുക, ഫയൽ മുകളിൽ എഴുതുക, അല്ലെങ്കിൽ അതിന്റെ സെർവറുകൾ NetworkManager-ന് നൽകി ഡീമണിനെ വീണ്ടും എഴുതാൻ അനുവദിക്കുക. മൂന്നാമത്തെ മാതൃക മാത്രമാണ് ലിങ്ക് അനുസരിച്ചുള്ള DNS സംരക്ഷിക്കുന്നത്, കാരണം സെർവറുകൾ ഒരു ആഗോള പട്ടികയിൽ പരന്നുപോകുന്നതിനുപകരം ഇന്റർഫേസുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു.
NetworkManager സിസ്റ്റങ്ങളിൽ ഫലം /etc/NetworkManager/NetworkManager.conf-ലെ backend-നെ ആശ്രയിച്ചിരിക്കുന്നു:
[main]
dns=systemd-resolveddns=default ഉപയോഗിച്ച് ക്ലയന്റിന്റെ സെർവറുകൾ വിജയിക്കുന്ന ക്രമത്തിൽ resolv.conf-ലേക്ക് ലയിക്കുന്നു, സ്വകാര്യ ചോദ്യം ഇപ്പോഴും പൊതു resolver-ലേക്ക് പോകാം. ലിങ്കുകൾ മനസ്സിലാക്കുന്ന backend ഉപയോഗിച്ച്, systemd-resolved അല്ലെങ്കിൽ dnsmasq, ടണലിന്റെ സെർവറുകൾ ടണലിൽ പരിമിതപ്പെടുന്നു, അതിന്റെ റൂട്ടിംഗ് ഡൊമെയ്നുമായി പൊരുത്തപ്പെടുന്ന പേരുകൾ മാത്രം അങ്ങോട്ട് പോകുന്നു. ഈ പരിമിതിയാണ് പ്രായോഗികമായി split DNS എന്നതിനർത്ഥം, ഒരു ക്ലയന്റ് അതിനെ പിന്തുണയ്ക്കുന്നു എന്ന് അവകാശപ്പെടുമ്പോൾ പലപ്പോഴും ഇല്ലാതാകുന്ന ഭാഗം അതാണ്.
എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് അവസ്ഥ വായിക്കുക:
resolvectl status
resolvectl dns tun0tun ഇന്റർഫേസ് DNS സെർവറും സ്വകാര്യ പ്രത്യയത്തിനുള്ള റൂട്ടിംഗ് ഡൊമെയ്നും സഹിതം ലിസ്റ്റ് ചെയ്യപ്പെട്ട്, ~internal.example ആയി കാണിക്കപ്പെടണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്നു. ലിങ്കിൽ സെർവർ ഇല്ലാതിരിക്കുക എന്നത് ക്ലയന്റ് ഒന്നും അയച്ചിട്ടില്ല എന്നാണ്. ഡൊമെയ്ൻ ഇല്ലാത്ത സെർവർ എന്നത് ചോദ്യങ്ങൾ എല്ലാം അങ്ങോട്ട് പോകുന്നു അല്ലെങ്കിൽ ഒന്നും പോകുന്നില്ല എന്നാണ്, ക്ലയന്റിനെ ആശ്രയിച്ച്, രണ്ടും split DNS അല്ല.
nsswitch തിരയൽ നേരത്തെ അവസാനിപ്പിക്കുന്നിടം
ഡെസ്ക്ടോപ്പിന്റെ സാധാരണ വരി ഇങ്ങനെ കാണപ്പെടുന്നു:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal മൾട്ടികാസ്റ്റ് DNS കൈകാര്യം ചെയ്യുന്നു, .local-ൽ അവസാനിക്കുന്ന എല്ലാ പേരുകൾക്കും അവകാശം പറയുന്നു. api.infra.svc.cluster.local പോലുള്ള Kubernetes സേവനവും .local-ൽ അവസാനിക്കുന്നു. mDNS മൊഡ്യൂൾ NOTFOUND റിപ്പോർട്ട് ചെയ്യുമ്പോൾ, [NOTFOUND=return] പ്രവർത്തനം dns മൊഡ്യൂളിലേക്ക് തുടരുന്നതിനുപകരം മുഴുവൻ തിരയലും അവസാനിപ്പിക്കുന്നു, അതിനാൽ പേര് ഒരിക്കലും VPN resolver-ലേക്ക് അയയ്ക്കപ്പെടുന്നില്ല. dig ഫയൽ പൂർണ്ണമായും ഒഴിവാക്കുന്നു, അതുകൊണ്ടാണ് രണ്ട് ഉപകരണങ്ങൾ യോജിക്കാത്തത്.
ഇതാണ് ഈ പ്രശ്നത്തിലെ ഏറ്റവും മൂർച്ചയുള്ള വൈരുദ്ധ്യം, അത് നിങ്ങളുടെ VPN-നേക്കാൾ പഴക്കമുള്ള കോൺഫിഗറേഷൻ ഫയലിലെ ഒരു വാക്കിൽ നിൽക്കുന്നു. പ്രവർത്തനം [NOTFOUND=continue] ആക്കി മാറ്റിയാൽ പ്രിന്ററുകൾക്കും പ്രാദേശിക ഉപകരണങ്ങൾക്കും mDNS നിലനിൽക്കും, DNS പേര് കാണാനും കഴിയും. വരി hosts: files dns ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നതും പ്രവർത്തിക്കുന്നു, കൂടുതൽ പരുക്കനാണ്: നിങ്ങൾ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന പ്രിന്ററിനുള്ള .local പരിഹാരം ഉപേക്ഷിക്കുന്നു.
കൃത്യമായി ഒരു നെറ്റ്വർക്കിൽ ജീവിക്കുന്ന പേരുകൾ
സ്വകാര്യ മേഖലകൾ കൃത്യമായി ഒരിടത്ത് മാത്രം അധികാരമുള്ളവയാണ്. ip-10-0-4-31.eu-west-1.compute.internal പോലുള്ള AWS പേര് ആ പ്രദേശത്തിന്റെ VPC resolver വഴി മറുപടി നൽകുന്നു, നിങ്ങളുടെ VPN എൻഡ്പോയിന്റ് വിഭവം ഉള്ള അതേ പ്രദേശത്തുള്ളിടത്തോളം മാത്രം. ഫ്രാങ്ക്ഫർട്ട് എൻഡ്പോയിന്റിലേക്ക് കണക്ട് ചെയ്ത്, അയർലൻഡിലെ compute.internal പേര് ചോദിച്ചാൽ, ഒരു പ്രാദേശിക ക്രമീകരണവും സഹായിക്കില്ല: റെക്കോർഡ് സൂക്ഷിക്കുന്ന മേഖല അവിടെ നിന്ന് എത്താനാവാത്തതാണ്.
തിരയൽ ഡൊമെയ്നുകൾ വിപരീത ചിത്രം ഉണ്ടാക്കുന്നു. വെറും service resolver ബാധകമെന്ന് കരുതുന്ന പ്രത്യയം കൊണ്ട് പൂർത്തിയാക്കുന്നു, VPN ലിങ്കുള്ളപ്പോൾ പ്രാദേശിക ഡൊമെയ്ന് കോർപ്പറേറ്റ് ഡൊമെയ്നിനെ തോൽപ്പിക്കാം. ഊഹം ഒഴിവാക്കാൻ അവസാനം ബിന്ദുവോടെ ചോദിക്കുക, getent ahosts service.internal.example., അത് പ്രവർത്തിച്ച് ചെറിയ പേര് പരാജയപ്പെട്ടാൽ, തിരുത്ത് ടണലിലെ തിരയൽ ഡൊമെയ്ൻ ആണ്, സെർവർ വിലാസമല്ല.
നിർവ്വഹിത ക്ലയന്റുകൾ സിസ്റ്റം resolver-ന് മുകളിൽ മൂന്നാം പാളി ചേർക്കുന്നു. Windows VPN പ്രൊഫൈലിന് അതിന്റേതായ പേര് പരിഹാര നയവും ഓരോ ആപ്പിനുമുള്ള നിയമങ്ങളും ടണൽ ഓഫ് ആയിരിക്കുമ്പോഴും ബാധകമാകുന്ന NRPT പട്ടികയും വഹിക്കാം. സ്വന്തം DNS കാഷുള്ള അപ്ലിക്കേഷനുകൾ, .NET, Java റൺടൈമുകളിൽ സാധാരണമാണ്, ശൃംഖല ശരിയാക്കിയതിന് ശേഷവും പഴയ പരാജയം ദീർഘനേരം സൂക്ഷിക്കുന്നു. Apple ക്ലയന്റുകൾ split DNS DNS ക്രമീകരണങ്ങളിലെ പൊരുത്തപ്പെടുന്ന ഡൊമെയ്നുകളിലൂടെ സജ്ജമാക്കുന്നു, resolv.conf-ലൂടെയല്ല, Chromium അല്ലെങ്കിൽ Firefox സുരക്ഷിത DNS മോഡിൽ പൊതു പേരുകൾക്കായി സിസ്റ്റം resolver ഒഴിവാക്കാം. VPN പേര് പരിഹാരത്തെക്കുറിച്ചുള്ള Microsoft റഫറൻസ് ആ നയ പാളിയുടെ Windows വശം വിവരിക്കുന്നു.
ഏത് പാളി ശരിയാക്കണം എന്ന് തീരുമാനിക്കുക
തിരുത്തലുകൾ ക്രമത്തിൽ പരീക്ഷിക്കുന്നതിനുപകരം ലക്ഷണത്തിൽ നിന്ന് പാളിയിലേക്ക് പോകുക:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
രണ്ട് വരികൾ കൂടുതൽ ഭാരം വഹിക്കുന്നു. ടൈംഔട്ട് എത്തിച്ചേരൽ പ്രശ്നമാണ്: സ്വകാര്യ resolver ടണലിലൂടെ മറുപടി നൽകുന്നില്ല, അതിനാൽ അതിന്റെ വിലാസത്തിലേക്കുള്ള വഴിയും ലിങ്കിലെ DNS സെർവർ നിങ്ങൾ കരുതുന്നതാണോ എന്നും പരിശോധിക്കുക. NXDOMAIN അധികാര പ്രശ്നമാണ്: എന്തോ മറുപടി നൽകി, അതിന് പേര് അറിയില്ല, ഇത് മേഖല, പ്രദേശം അല്ലെങ്കിൽ ഈ ചോദ്യം ഒരിക്കലും സ്വീകരിക്കാൻ പാടില്ലാത്ത resolver-ലേക്ക് സൂചന നൽകുന്നു.
അവസാന വരി ആളുകൾ ഒഴിവാക്കുന്നതാണ്, കാരണം രണ്ട് പകുതിയും വിജയം പോലെ തോന്നുന്നു. FQDN-ൽ നിന്ന് വ്യത്യസ്തമായി പരിഹരിക്കപ്പെടുന്ന ചെറിയ പേര് പ്രത്യയ പൊരുത്തക്കേടാണ്, ടണൽ വീണ്ടും ബന്ധിപ്പിക്കുന്നത് ക്ലയന്റ് ഏത് പ്രത്യയം അയയ്ക്കുന്നു എന്നത് മാറ്റില്ല.
കോൺഫിഗറേഷൻ ഫയൽ തിരുത്തുന്നതിന് മുമ്പ് അവസ്ഥ രേഖപ്പെടുത്തുക, തിരുത്ത് എന്തെങ്കിലും ചെയ്തോ എന്ന് പറയാൻ കഴിയും:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtപരിശോധനകൾ ഈ ക്രമത്തിൽ പ്രവർത്തിപ്പിച്ച് ആദ്യ പരാജയത്തിൽ നിർത്തുക. getent-ഉം resolvectl query-യും യോജിക്കണം; getent പരാജയപ്പെട്ട് dig മറുപടി നൽകുന്നുണ്ടെങ്കിൽ, തിരയൽ ശൃംഖലയിൽ തുടരുക, റൂട്ടിംഗ് തൊടരുത്. resolvectl status tun ഇന്റർഫേസിൽ DNS സെർവറും റൂട്ടിംഗ് ഡൊമെയ്നും കാണിക്കണം. nsswitch പരിശോധിക്കുന്ന പ്രത്യയത്തിന് NOTFOUND-ൽ നേരത്തെ മടങ്ങരുത്. പേര് നിങ്ങളുടെ എൻഡ്പോയിന്റ് ബന്ധിപ്പിച്ചിരിക്കുന്ന നെറ്റ്വർക്കിൽ അധികാരമുള്ളതായിരിക്കണം, അവസാനം ബിന്ദുവോടെ പരിശോധിച്ചത്. അപ്ലിക്കേഷൻ സ്വന്തം കാഷോ സുരക്ഷിത DNS ഓവർറൈഡോ സൂക്ഷിക്കരുത്.
പരാജയപ്പെടുന്ന ആദ്യ പാളി മാത്രം ശരിയാക്കി, പിന്നീട് അതേ കമാന്റുകൾ വീണ്ടും പ്രവർത്തിപ്പിക്കുക. ഒരേ സമയം രണ്ട് മാറ്റങ്ങൾ ഏതാണ് പ്രധാനമായിരുന്നത് എന്ന് പറയാൻ അനുവദിക്കില്ല, അടുത്ത തകരാർ അന്വേഷണം പൂജ്യത്തിൽ നിന്ന് തുടങ്ങുന്നു.