സ്വകാര്യ DNS പേരുകൾ VPN ക്ലയന്റുകളിൽ എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു, എവിടെ പരിശോധിക്കണം

നിങ്ങൾ ഹോട്ടൽ മുറിയിൽ ലാപ്ടോപ്പ് തുറന്ന്, ക്ലയന്റ് സ്റ്റാർട്ട് ചെയ്ത്, ആന്തരിക ഫയൽ സർവറിന്റെ പേര് ടൈപ്പ് ചെയ്യുന്നു, ഒന്നും തിരികെ വരുന്നില്ല. ടണൽ കണക്റ്റ് ചെയ്തതായി പറയുന്നു, അതേ സബ്നെറ്റിലെ വിലാസത്തിന് ping ഇപ്പോഴും മറുപടി നൽകുന്നു, അതിനാൽ ഗതാഗതം തന്നെ ശരിയാണ്. പേര് മാത്രമാണ് പരാജയപ്പെടുന്നത്, ആ വിടവ് പ്രശ്നത്തെ രണ്ട് സ്ഥലങ്ങളിലേക്ക് ചുരുക്കുന്നു: ക്ലയന്റ് ഏത് റിസോൾവറിനോട് ചോദിച്ചു, കിട്ടിയ മറുപടിക്ക് ടണലിലൂടെ തിരികെ വരാനാകുമോ. ഒന്ന് നന്നാക്കി മറ്റൊന്ന് ഒഴിവാക്കിയാൽ, തകരാർ വെറുതെ സ്ഥലം മാറും.

ഏതെങ്കിലും പ്രൊഫൈൽ എഡിറ്റ് ചെയ്യുന്നതിന് മുൻപ് ക്ലയന്റ് പേരിനോട് എന്ത് ചെയ്യുന്നു എന്ന് ഉറപ്പാക്കുക. Linux ൽ resolvectl query files.corp.example ഏത് ലിങ്കും ഏത് റിസോൾവറും മറുപടി നിർമ്മിച്ചു എന്ന് കാണിക്കുന്നു. Windows ൽ Resolve-DnsName files.corp.example മറുപടി നൽകിയ സർവറും അത് തിരികെ നൽകിയ വിലാസവും കാണിക്കുന്നു.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് മറുപടി വായിക്കുക

പേര് കുറച്ച് മില്ലിസെക്കൻഡുകൾക്കുള്ളിൽ NXDOMAIN ആയി തിരികെ വന്നാൽ, ചോദ്യം നിങ്ങളുടെ സോണിൽ എത്തിയിട്ടേയില്ല, ഏതോ പൊതു അല്ലെങ്കിൽ ഹോട്ടൽ റിസോൾവർ മറുപടി നൽകി. നീണ്ട ഇടവേളയ്ക്ക് ശേഷം തിരികെ വന്നാൽ, വഴിയിൽ എന്തോ UDP പോർട്ട് 53 വീഴ്ത്തുന്നു, ക്ലയന്റ് ഒടുവിൽ ബദലിലേക്ക് ഇറങ്ങി. ശരിയായ വിലാസത്തോടെ മറുപടി നൽകുന്നു പക്ഷേ കണക്ഷൻ ഇപ്പോഴും കുടുങ്ങുന്നുവെങ്കിൽ, തിരയൽ ശരിയാണ്, നിങ്ങളുടെ പ്രശ്നം റൂട്ടിംഗിലോ സേവനത്തിലോ ആണ്.

ഈ മൂന്ന് വിഭാഗമായുള്ള വിഭജനം ഒരു മണിക്കൂർ ഊഹം ലാഭിക്കുന്നു. VPN ഇനി തൊടണമോ വേണ്ടയോ എന്നും പറയുന്നു: ശരിയായ സ്വകാര്യ വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെടുന്ന പേര് റിസോൾവറിന്റെ വഴി ഇതിനകം തെളിയിച്ചിട്ടുണ്ട്, അതിനാൽ ബാക്കി ജോലി ഡാറ്റയുടെ വഴിയിലാണ്.

റിസോൾവറിനെ ടണലിനുള്ളിൽ നിന്ന് വിതരണം ചെയ്യുക

ക്ലയന്റുകൾ രണ്ട് ഗ്രൂപ്പുകളായി പിരിയുന്നു. ഒന്നിന് സർവർ കണക്ഷൻ ഉണ്ടാകുമ്പോൾ റിസോൾവർ നൽകാം; മറ്റൊന്ന് ആ ക്രമീകരണം പ്രാദേശിക ഫയലിൽ സൂക്ഷിക്കുന്നു, അത് ഏത് ഗേറ്റ്വേയ്ക്കും ദൂരെ നിന്ന് മാറ്റാനാവില്ല.

OpenVPN ആദ്യ ഗ്രൂപ്പിലാണ്. സർവറിൽ push "dhcp-option DNS 10.8.0.53" ഉം push "dhcp-option DOMAIN corp.example" ഉം നിയന്ത്രണ ചാനലിലൂടെ താഴേക്ക് പോകുന്നു, പക്ഷേ ക്ലയന്റിന്റെ കോൺഫിഗറേഷനിൽ pull ഇപ്പോഴും സജീവമാണെങ്കിൽ മാത്രം. കൈകൊണ്ട് എഡിറ്റ് ചെയ്ത് pull-filter ignore "dhcp-option" വഹിക്കുന്ന ക്ലയന്റ് അവ ഒരിക്കലും കാണില്ല, ആ ഒരു വരി «സർവർ അത് തള്ളുന്നു പക്ഷേ എന്റെ ലാപ്ടോപ്പ് സമ്മതിക്കുന്നില്ല» എന്നതുപോലുള്ള അതിശയകരമായ ഒട്ടേറെ സന്ദർഭങ്ങൾ വിശദീകരിക്കുന്നു.

WireGuard രണ്ടാം ഗ്രൂപ്പിലാണ്, കാരണം പ്രോട്ടോക്കോളിൽ ഓപ്ഷനുകളുടെ ചർച്ചയേ ഇല്ല. റിസോൾവറും തിരയൽ ഡൊമെയ്നും ക്ലയന്റിന്റെ സ്വന്തം [Interface] ബ്ലോക്കിലേക്ക് DNS = 10.8.0.53, corp.example രൂപത്തിൽ പോകുന്നു. wg-quick അത് resolvconf അല്ലെങ്കിൽ systemd-resolved വഴി പ്രയോഗിക്കുന്നു, Windows ൽ ഔദ്യോഗിക ക്ലയന്റ് ടണൽ നിൽക്കുന്നിടത്തോളം മാത്രം നിലനിൽക്കുന്ന NRPT നിയമങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു: Get-DnsClientNrptPolicy അവ ലിസ്റ്റ് ചെയ്യുന്നു, ഇത് ക്ലയന്റ് നിങ്ങളുടെ ഫയൽ എപ്പോഴെങ്കിലും പ്രയോഗിച്ചിട്ടുണ്ടോ എന്ന് കാണാനുള്ള വേഗമാർഗമാക്കുന്നു.

IPsec/IKEv2 ഇടയിലാണ്. strongSwan ന്റെ attr പ്ലഗിൻ കുളത്തിൽ നിന്ന് എടുത്ത DNS സർവർ തിരികെ നൽകാം, Windows ക്ലയന്റ് അത് സാധാരണയായി സ്വീകരിക്കുന്നു, പക്ഷേ സ്വന്തം പേരു സർവറിനെ ഉറപ്പിക്കുന്ന പ്രൊഫൈൽ ഗേറ്റ്വേ നൽകുന്നതെല്ലാം അതിലംഘിക്കുന്നു. Linux ക്ലയന്റിൽ തത്തുല്യമായ കൈപ്പടി resolvectl dns wg0 10.8.0.53 എന്നതും തുടർന്ന് resolvectl domain wg0 '~corp.example' എന്നതുമാണ്; രണ്ടും ഇന്റർഫേസിനൊപ്പം അപ്രത്യക്ഷമാകുന്നു, ഇത് ടണലിന് പരിമിതമായ ക്രമീകരണത്തിന് നിങ്ങൾ ആഗ്രഹിക്കുന്നത് കൃത്യമായി അതാണ്.

ഓരോ ചോദ്യവും വിഴുങ്ങുന്നതിന് പകരം സഫിക്സ് പരിമിതപ്പെടുത്തുക

ക്ലയന്റിന്റെ മുഴുവൻ റിസോൾവർ പട്ടികയും നിങ്ങളുടെ ആന്തരിക സർവറിലേക്ക് തിരിക്കുന്നത് എളുപ്പമാണ്, സാധാരണയായി തെറ്റാണ്. അപ്പോൾ ഓരോ പൊതു പേരും നിങ്ങളുടെ ഡാറ്റാ സെന്ററിന്റെ പുറത്തേക്കുള്ള വഴിയിലൂടെ പരിഹരിക്കപ്പെടുന്നു, CDN-കൾ അകലെയുള്ള വിലാസങ്ങൾ തിരികെ നൽകുന്നു, റിസോൾവറിലെ ഒരു തകരാർ ഉപയോക്താവിന്റെ ബ്രൗസിംഗും കൂടെ കൊണ്ടുപോകുന്നു.

അകത്തേക്ക് സ്വകാര്യ സഫിക്സ് മാത്രം അയക്കുക. systemd-resolved ൽ ~ ൽ തുടങ്ങുന്ന ഡൊമെയ്ൻ റൂട്ടിംഗിന് മാത്രമാണ്, അതിനാൽ ~corp.example എന്നാൽ ആ സഫിക്സിന് കീഴിലുള്ള ചോദ്യങ്ങൾ ആ ലിങ്കിന്റെ സർവറുകളിലേക്ക് പോകുന്നു, ബാക്കിയെല്ലാം ഭൗതിക നെറ്റ്വർക്ക് ഉപയോഗിക്കുന്നു എന്നാണ്. Windows ഇതേ ജോലി പേരിടത്തിന് പരിമിതപ്പെടുത്തിയ NRPT നിയമങ്ങളിലൂടെ ചെയ്യുന്നു, macOS /etc/resolver/ ന് കീഴിൽ അധിക റിസോൾവർ ഫയൽ വഴി ചെയ്യുന്നു.

മൾട്ടികാസ്റ്റ് പേരുകൾ അവയുടെ സ്വന്തം മറുപടിക്ക് അർഹമാണ്. .local പേരുകൾ നിർമ്മാണപരമായി link-local (RFC 6762) ആണ്, പോയിന്റ്-ടു-പോയിന്റ് tun ഇന്റർഫേസ് ആ മൾട്ടികാസ്റ്റ് ഗ്രൂപ്പ് വഹിക്കുന്നില്ല, അതിനാൽ പൊതു റിസോൾവർ ചേർക്കുന്നത് അവ പ്രസിദ്ധീകരിക്കില്ല, ആന്തരിക unicast റിസോൾവറിനോട് അവയെപ്പറ്റി ചോദിച്ചാൽ NXDOMAIN തിരികെ വരുന്നു. avahi പോലുള്ള പ്രതിഫലകം പ്രതിഫലന മോഡിൽ രണ്ട് ഭാഗങ്ങൾ ബന്ധിപ്പിക്കാം, പക്ഷേ അത് സർവർ ഭാഗത്തെ തീരുമാനമാണ്, ഏത് ക്ലയന്റിനും ആവശ്യപ്പെടാനാവില്ല. പ്രിന്റർ അല്ലെങ്കിൽ NAS പേരിൽ എത്തിച്ചേരാവുന്നതായിരിക്കണമെങ്കിൽ, പകരം നിങ്ങളുടെ സോണിൽ അതിന് A റെക്കോർഡ് നൽകുക.

മറുപടിക്ക് തിരികെ വരാനാകുമെന്ന് തെളിയിക്കുക

എത്തിച്ചേരാനാവാത്ത വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന ശരിയായ മറുപടി, നിങ്ങൾ വഴി പരിശോധിക്കുന്നതുവരെ കൃത്യമായി റിസോൾവർ പ്രശ്നം പോലെ തോന്നും. മറുപടി എവിടേക്ക് പോകുമെന്ന് കെർണലിനോട് ചോദിക്കുക: ip route get 10.20.5.20 ഇന്റർഫേസും കൂടുതൽ ഉപയോഗപ്രദമായി അത് ഉപയോഗിക്കുന്ന ഉറവിട വിലാസവും പേരിടുന്നു.

റിസോൾവറിന്റെ വിലാസം തന്നെ ശ്രദ്ധിക്കുക. DNS = 10.8.0.53 നൊപ്പം AllowedIPs = 10.20.0.0/16 ഉള്ള ക്ലയന്റ് തന്റെ ചോദ്യങ്ങൾ ഭൗതിക NIC വഴി പുറത്തേക്ക് അയക്കുന്നു, അവിടെ അവ നിശ്ശബ്ദമായി മരിക്കുന്നു, കാരണം റിസോൾവർ ടണൽ അവകാശപ്പെടുന്ന ഏതെങ്കിലും പ്രിഫിക്സിനുള്ളിലല്ല. ഈ പൊരുത്തക്കേടാണ് ഈ മേഖല മുഴുവൻ ഏറ്റവും സാധാരണ ഏക-കാരണ പരാജയം, DNS ക്രമീകരണം അനുവദിച്ച പ്രിഫിക്സുകളുമായി വരി വരിയായി താരതമ്യം ചെയ്യുന്നതുവരെ ഇത് കാണാനാവില്ല.

അതിവ്യാപിക്കുന്ന ശ്രേണികൾ വിപരീത പരാജയം ഉണ്ടാക്കുന്നു. മറുപടി ശരിയാണ്, വഴിയുണ്ട്, അത് തെറ്റായ ഹോസ്റ്റിലേക്ക് ചൂണ്ടുന്നു, കാരണം വീട്ടിൽ 192.168.0.0/24 അതേ ശ്രേണിയിലേക്കുള്ള ടണൽ വഴിയെക്കാൾ കൂടുതൽ നിർദ്ദിഷ്ടമാണ്. ഒരു വശം പുനർസംഖ്യയിടുക അല്ലെങ്കിൽ ഇടുങ്ങിയ വഴി തള്ളുക, പിന്നീട് സേവന ഹോസ്റ്റിന്റെ ഫയർവാളും തിരികെയുള്ള വഴിയും സ്ഥിരീകരിക്കുക; strongSwan ന്റെ ഫോർവേഡിംഗ് സംബന്ധിച്ച കുറിപ്പുകൾ ആ വഴിയുടെ sysctl വശം ഉൾക്കൊള്ളുന്നു.

സർട്ടിഫിക്കറ്റുകൾ ആളുകൾ DNS മേൽ ആരോപിക്കുന്ന പ്രത്യേക ഐഡന്റിറ്റി പരിശോധനയാണ്. ബ്രൗസർ പരിഹാര പിശകിന് പകരം പേരു പൊരുത്തക്കേട് റിപ്പോർട്ട് ചെയ്താൽ, തിരയൽ ഇതിനകം പ്രവർത്തിച്ചു, സർട്ടിഫിക്കറ്റിലെ SAN ആണ് നന്നാക്കേണ്ടത്. HTTPS പേരിനെതിരെ പരിശോധിക്കുക, ഒരിക്കലും നഗ്നമായ IP-യ്ക്കെതിരെ അല്ല.

ഗേറ്റ്വേയിൽ നിന്നല്ല, ക്ലയന്റിൽ നിന്ന് വീണ്ടും പരിശോധിക്കുക

ഉപയോക്താവ് പരാതിപ്പെടുന്ന ആപ്ലിക്കേഷനുള്ളിൽ തന്നെ പരിശോധിക്കുക, കാരണം കമാൻഡ് ലൈൻ തിരയൽ ബ്രൗസറും അതേ വഴി സ്വീകരിക്കുന്നു എന്ന് തെളിയിക്കുന്നില്ല. Chrome ന്റെ സുരക്ഷിത DNS ഉം Firefox ന്റെ network.trr.mode ഉം സിസ്റ്റം റിസോൾവറിനെ പൂർണ്ണമായി ഒഴിവാക്കാം, അങ്ങനെ ചെയ്യുമ്പോൾ സ്വകാര്യ പേര് ഒന്നുകിൽ പരാജയപ്പെടുന്നു അല്ലെങ്കിൽ പൊതു റിസോൾവറിലേക്ക് ചോരുന്നു. resolvectl query നെ കൈകൊണ്ട് പ്രവർത്തിപ്പിച്ച dig @10.8.0.53 files.corp.example മായി താരതമ്യം ചെയ്യുന്നത് രണ്ടിൽ ഏതാണ് സംഭവിച്ചതെന്ന് പറയും.

പിന്നീട് അത് നന്നാക്കിയതായി പ്രഖ്യാപിക്കുന്നതിന് മുൻപ് കണക്ഷൻ വിച്ഛേദിച്ച് വീണ്ടും ബന്ധിപ്പിക്കുക. ഇന്റർഫേസിൽ കൈകൊണ്ട് വെച്ച ക്രമീകരണങ്ങൾ ഇന്റർഫേസിനൊപ്പം അപ്രത്യക്ഷമാകുന്നു, മറന്നുപോയ പ്രാദേശിക മാറ്റം കാരണം മാത്രം ശരിയായി തോന്നിയ പ്രൊഫൈൽ അടുത്ത തവണ ബൂട്ടിൽ പരാജയപ്പെടും.

അടുത്ത യന്ത്രത്തിനുള്ള ചെറിയ പട്ടിക: പേര് ടണലിന്റെ റിസോൾവർ വഴി പരിഹരിക്കപ്പെടുന്നു, സഫിക്സ് പരിമിതമാണ് ആഗോളമല്ല, റിസോൾവറിന്റെ വിലാസം അനുവദിച്ച പ്രിഫിക്സുകൾക്കുള്ളിലാണ്, മറുപടിയിലെ ഹോസ്റ്റ് സേവന പോർട്ടിൽ മറുപടി നൽകുന്നു, സർട്ടിഫിക്കറ്റ് ഉപയോക്താവ് ടൈപ്പ് ചെയ്ത പേര് ഉൾക്കൊള്ളുന്നു.