OpenVPN പുഷ് ചെയ്ത DNS അവഗണിക്കപ്പെടുന്നു: ഏത് ഘടകമാണ് അത് പ്രയോഗിക്കുന്നത്

പുഷ് ചെയ്ത DNS ഓപ്ഷൻ ക്ലയന്റിലെത്തുന്നത് പരിസ്ഥിതി ചരം ആയി മാത്രമാണ്. Linux, Windows, macOS എന്നിവയിൽ നാമപരിഹാരത്തിന്റെ ഉടമ ആരെന്ന് പരിശോധിച്ച്, പിന്നീട് പാത പരീക്ഷിക്കുക.

സെർവർ പുഷ് ചെയ്ത ഓപ്ഷൻ ലോഗിൽ കാണാം, ടണൽ പ്രവർത്തിക്കുന്നു, എന്നിട്ടും ആന്തരിക നാമങ്ങൾ പരാജയപ്പെടുന്നു. റിസോൾവറിലേക്ക് നേരിട്ടുള്ള ക്വറി ഉത്തരം നൽകുന്നു, അതായത് സെർവർ കുഴപ്പമില്ല, പക്ഷേ ഓരോ അപ്ലിക്കേഷനും പ്രാദേശിക റൂട്ടറിനോട് ചോദിച്ചുകൊണ്ടിരിക്കുന്നു. ക്ലയന്റിലെത്തിയത് ഒരു നിർദ്ദേശമാണ്, റിസോൾവറിലെ മാറ്റമല്ല, നാമപരിഹാരത്തിന്റെ ഉടമസ്ഥതയുള്ള ഘടകം Linux, Windows, macOS എന്നിവയിൽ വ്യത്യസ്തമാണ്. ഓപ്ഷനെ അതിന്റെ ഉടമയിൽ നിന്ന് വേർതിരിച്ചാൽ, നാല് തകരാറുകൾ മിക്കവാറും എല്ലാ റിപ്പോർട്ടുകളെയും ഉൾക്കൊള്ളുന്നു: ഹുക്ക് ഇല്ല, രണ്ട് മത്സരിക്കുന്ന ഹുക്കുകൾ, രൂപകൽപ്പന പ്രകാരം പ്രവർത്തിക്കുന്ന വിഭജിത DNS, അല്ലെങ്കിൽ സെർവറല്ല സഫിക്സ് ആവശ്യമുള്ള ചെറിയ നാമം.

പുഷ് ചെയ്ത ഓപ്ഷൻ ഒരു നിർദ്ദേശമാണ്, ഇൻസ്റ്റലേഷനല്ല

സെർവറിൽ, രണ്ട് നിർദ്ദേശങ്ങൾ ഫലമല്ല, ഉദ്ദേശ്യം വിവരിക്കുന്നു:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

ക്ലയന്റിന് കോൺഫിഗർ ചെയ്ത റിസോൾവർ ലഭിക്കുന്നില്ല. അതിന് പരിസ്ഥിതി ചരങ്ങൾ ലഭിക്കുന്നു, foreign_option_1 ഉം തുടർന്നുള്ളവയും, പുഷ് ചെയ്ത ഓരോ വരിക്കും ഒന്ന് വീതം, പ്രാദേശികമായ എന്തെങ്കിലും അവ വായിച്ച് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ റിസോൾവർ അവസ്ഥ പുനരെഴുതണം. Linux ൽ സ്വതവേ ഒന്നും അത് ചെയ്യുന്നില്ല, അതിനാൽ ശരിയായ സെർവറും കണക്ട് ചെയ്ത ക്ലയന്റും ഇപ്പോഴും LAN വഴി നാമങ്ങൾ പരിഹരിക്കാം.

രണ്ട് അറ്റങ്ങൾക്കിടയിൽ മൂന്ന് ഘട്ടങ്ങളുണ്ട്: പുഷ് എത്തണം, ക്ലയന്റ് അത് വെളിപ്പെടുത്തണം, ഒരു ഹുക്ക് അത് പ്രയോഗിക്കണം. ലോഗിൽ നടുവിലത്തെ ഘട്ടവും റിസോൾവർ അവസ്ഥയിൽ അവസാനത്തേതും വായിക്കുക, ഒരിക്കലും തലതിരിഞ്ഞ് അല്ല, കാരണം ഒരു ലോഗ് വരി ആദ്യ രണ്ടെണ്ണം മാത്രം തെളിയിക്കുന്നു.

പുഷ് എത്തിയെന്ന് ഉറപ്പാക്കി ഉടമയെ കണ്ടെത്തുക

ആരംഭകനെ പേരിട്ട് തുടങ്ങുക: വെറും openvpn കമാൻഡ്, ഒരു systemd ഇൻസ്റ്റൻസ്, NetworkManager അല്ലെങ്കിൽ വെണ്ടർ ക്ലയന്റ്. ഇത് ഹുക്ക് എവിടെ ജീവിക്കാം എന്ന് തീരുമാനിക്കുന്നു. systemd-resolved ഉള്ള ഹോസ്റ്റിൽ, resolvectl status ഓരോ ലിങ്കും അത് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന DNS സെർവറുകളും തിരയൽ ഡൊമെയ്നുകളും സഹിതം ലിസ്റ്റ് ചെയ്യുന്നു, ടണൽ ലിങ്കിന്റെ പേര് എപ്പോഴും tun0 എന്നല്ല.

പുഷ് ചെയ്ത വിലാസം ലോഗിൽ ഉണ്ടെങ്കിലും ഒരു ലിങ്കിലും ഇല്ലെങ്കിൽ സംയോജനം ഇല്ല. അത് ലിങ്കിൽ ഉണ്ടെങ്കിലും ക്വറികൾ ഇപ്പോഴും വേറെ എവിടെയോ പോകുന്നുവെങ്കിൽ, പ്രശ്നം ഇതാണ്, ഏത് ക്വറികൾ ആ ലിങ്ക് തിരഞ്ഞെടുക്കുന്നു. NetworkManager dns=dnsmasq ഫയലിൽ /etc/NetworkManager/NetworkManager.conf പ്രാദേശിക ഫോർവേർഡർ പ്രവർത്തിപ്പിക്കുന്നു, അത് വിഭജിത DNS ബോധപൂർവം നടപ്പാക്കുന്നു: VPN ഡൊമെയ്നിനുള്ളിലെ നാമങ്ങൾ VPN റിസോൾവറിലേക്ക് പോകുന്നു, ബാക്കിയെല്ലാം അതിന്റെ മുൻ പാത നിലനിർത്തുന്നു. എല്ലാ ട്രാഫിക്കും മാറുമെന്ന് പ്രതീക്ഷിച്ചപ്പോൾ ഈ സ്വഭാവം തകരാറായി തോന്നുന്നു; കണക്ഷൻ അനുസരിച്ചുള്ള ക്രമീകരണങ്ങൾ പരിശോധിക്കുക nmcli connection show "My VPN" ഉപയോഗിച്ച്, അവിടെ ipv4.dns ഉം ipv4.dns-search ഉം ഉപകരണം റിപ്പോർട്ട് ചെയ്യുന്നതിന്റെ പിന്നിലുള്ള മൂല്യങ്ങൾ സൂക്ഷിക്കുന്നു, അതിനെ തകർന്നതെന്ന് വിളിക്കുന്നതിന് മുമ്പ്. ഓരോ ക്വറിയും യഥാർത്ഥത്തിൽ VPN റിസോൾവറിലെത്തണമെങ്കിൽ, നീക്കം ചെയ്യുക dns=dnsmasq ഇതിൽ നിന്ന് NetworkManager.conf ഫയലിൽ നിന്ന്, NetworkManager പുനരാരംഭിക്കുക, അത് നാമപരിഹാരം കണക്ഷൻ ക്രമീകരണങ്ങൾക്ക് തിരികെ നൽകുന്നു; അല്ലെങ്കിൽ വിഭജിത DNS നിലനിർത്തി പുഷ് ചെയ്ത ഡൊമെയിൻ പട്ടിക ശരിയാക്കുക.

Linux: ഓപ്ഷനുകൾ റിസോൾവറിന് നൽകുക

ഡിസ്ട്രിബ്യൂഷൻ പാക്കേജുകൾ ഇതിനായി ഒരു ഹുക്ക് നൽകുന്നു, ക്ലയന്റിന് അത് പ്രവർത്തിപ്പിക്കാൻ അനുമതി ഉണ്ടായിരിക്കണം. systemd-resolved ഇല്ലാത്ത ഹോസ്റ്റിലെ സാധാരണ ക്രമീകരണം:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved ഉള്ളപ്പോൾ പഴയ resolv.conf സ്ക്രിപ്റ്റ് പ്രധാനമായ ഒന്നും മാറ്റിയേക്കില്ല, കാരണം stub റിസോൾവർ ലിങ്കിന് അനുസരിച്ച് അവസ്ഥ സൂക്ഷിക്കുന്നു. update-systemd-resolved സഹായി ഉപയോഗിക്കുന്ന ഒരു ഹുക്ക് രൂപം രേഖപ്പെടുത്തുന്നു up-restart ഉം down-pre ഉം, ഇത് ഒരു ഇന്റർഫേസ് ഒരു കണക്ഷൻ ശ്രമത്തേക്കാൾ കൂടുതൽ നിലനിൽക്കുമ്പോൾ പ്രധാനമാണ്. എന്ത് തിരഞ്ഞെടുത്താലും, അവസ്ഥയുടെ ഉടമസ്ഥത ഒരു ഘടകത്തിന് ആയിരിക്കണം. NetworkManager ന് അരികിൽ ബന്ധമില്ലാത്ത ഹുക്ക് ചേർത്താൽ ഒരേ ലിങ്കിന് രണ്ട് എഴുത്തുകാർ ആകും, ഫലം അപ്പോൾ നിങ്ങളുടെ കോൺഫിഗറേഷനെയല്ല, ക്രമത്തെ ആശ്രയിക്കുന്നു.

NetworkManager പുഷ് ചെയ്ത ഓപ്ഷൻ പൂർണ്ണമായി അവഗണിച്ച ഒരു സന്ദർഭവുമുണ്ട്: കണക്ഷന്റെ IPv4 ക്രമീകരണങ്ങളിൽ സെർവർ വിലാസം നൽകുന്നതുവരെ അത് തുടർന്നു, പിന്നീട് റിസോൾവർ അവസ്ഥ അത് ഉപയോഗത്തിലാണെന്ന് കാണിച്ചു. സ്ക്രിപ്റ്റുകൾ പുനരെഴുതുന്നതിന് മുമ്പ് ഇത് പരീക്ഷിക്കാൻ തക്കതാണ്, കാരണം ഇത് പ്രശ്നം ഷെൽ ഹുക്കിൽ നിന്ന് ടണൽ ഇതിനകം വഹിക്കുന്ന കണക്ഷൻ പ്രൊഫൈലിലേക്ക് മാറ്റുന്നു.

Windows ഉം macOS ഉം വ്യത്യസ്ത ഭാഗങ്ങൾ പ്രയോഗിക്കുന്നു

Windows ക്ലയന്റ് VPN അഡാപ്റ്ററിന്റെ DNS സെർവറുകൾ യഥാർത്ഥത്തിൽ സെറ്റ് ചെയ്യുന്നു, പക്ഷേ Windows ഇപ്പോഴും മെട്രിക് പ്രകാരം ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നു, ചെറിയ നാമം വികസിപ്പിക്കാൻ ഇപ്പോഴും സഫിക്സ് വേണം. പ്രൊഫൈലല്ല, അഡാപ്റ്ററിന്റെ അവസ്ഥ ഉറപ്പാക്കുക:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

വിലാസം ഇല്ലെങ്കിൽ ഇത് ഉപയോഗിച്ച് സെറ്റ് ചെയ്യുക Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, പിന്നീട് സഫിക്സ് അഡാപ്റ്ററിന്റെ IPv4 ഗുണങ്ങളിൽ ചേർക്കുക, അങ്ങനെ fileserver ആകും fileserver.corp.example. മെഷീൻ വ്യാപകമായ SearchList മൂല്യം Tcpip\Parameters ന് കീഴിൽ അതേ കാര്യം ചെയ്യുന്നു. ദീർഘ നാമം പരിഹരിക്കപ്പെടുകയും വെറും നാമം പരിഹരിക്കപ്പെടാതിരിക്കുകയും ചെയ്യുന്നിടത്ത് റിസോൾവർ ഇതിനകം ശരിയാണ്, കുറ്റം തിരയൽ പട്ടികയുടേതാണ്. പരിഹാരങ്ങൾ ക്രമത്തിൽ: പുഷ് ചെയ്യുക DOMAIN ക്ലയന്റ് സഫിക്സ് പഠിക്കാൻ, ആ സഫിക്സ് അഡാപ്റ്ററിന്റെയോ കണക്ഷന്റെയോ തിരയൽ പട്ടികയിൽ ചേർക്കുക, താൽക്കാലിക നടപടിയായി നാമം ഇവിടെ ഉറപ്പിക്കുക hosts ഫയലിൽ, അല്ലെങ്കിൽ LMHOSTS ൽ Windows ൽ; NetBIOS ബ്രൗസിംഗ് റൂട്ടറിനെ മറികടക്കുന്നില്ല, അതിനാൽ ഓഫീസ് LAN ൽ ചെറിയ നാമം കണ്ടെത്തുന്ന ബ്രോഡ്കാസ്റ്റ് ഒരിക്കലും ടണൽ ക്ലയന്റിലെത്തുന്നില്ല.

block-outside-dns block-outside-dns Windows ക്ലയന്റിന്റെ സ്വഭാവമാണ്, കൈമാറാവുന്ന പ്രൊഫൈൽ വരിയല്ല, Linux അല്ലെങ്കിൽ macOS പ്രൊഫൈലിലേക്ക് പകർത്തുന്നത് അവിടെ അത് പുനർനിർമ്മിക്കുന്നില്ല. Windows ൽ പൊതു നാമങ്ങൾ പ്രവർത്തിക്കുകയും ആന്തരിക നാമങ്ങൾ പരാജയപ്പെടുകയും ചെയ്താൽ, വിപുലമായ ക്രമീകരണങ്ങൾക്ക് കീഴിലുള്ള അഡാപ്റ്റർ ക്രമം ഇതുമായി താരതമ്യം ചെയ്യുക ipconfig /all. macOS ൽ ഓരോ സേവനത്തിന്റെയും റിസോൾവർ ക്രമം സിസ്റ്റത്തിന്റേതാണ്, അതിനാൽ scutil --dns ഉപയോഗിച്ച് ഏത് ഡൊമെയ്നിന് ഏത് റിസോൾവർ ചോദിക്കപ്പെടുന്നു എന്ന് കാണുക, റിപ്പോർട്ട് ചെയ്യപ്പെട്ട ഏതെങ്കിലും ഒറ്റ പ്രൊഫൈൽ പരിഹാരത്തെ പൊതുവായതല്ല, ക്ലയന്റ് ആശ്രിതമായി കാണുക.

അതേ ലാപ്ടോപ്പിലെ വെർച്വൽ മെഷീൻ ഇതിൽ നിന്ന് ഒന്നും പാരമ്പര്യമായി നേടുന്നില്ല. അതിഥിക്ക് ആന്തരിക ഡൊമെയ്നിനായി സ്വന്തം റിസോൾവർ എൻട്രി നൽകുക, അല്ലെങ്കിൽ ഹൈപ്പർവൈസറിന്റെ NAT അതിന്റെ ക്വറികൾ ഹോസ്റ്റ് വഴി കൈമാറട്ടെ, ഇത് ഹോസ്റ്റിന്റെ ടണൽ പ്രവർത്തിക്കുന്നിടത്തോളം മാത്രം ശരിയാണ്.

ചരിത്രമാണ് മൂന്നാമത്തെ കാരണം. മുൻ പ്രൊഫൈലിലെ DNS സെർവറുകൾ അല്ലെങ്കിൽ സഫിക്സ് ക്രമീകരണങ്ങൾ വീണ്ടും കണക്ട് ചെയ്യലുകളെ അതിജീവിച്ചേക്കാം, അതിനാൽ അഡാപ്റ്റർ ശരിയായി കാണപ്പെടുകയും തിരയലുകൾ ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്താൽ, സജീവമായ അഡാപ്റ്ററിനെ ഇതുമായി താരതമ്യം ചെയ്യുക Get-VpnConnection കൂടാതെ സെർവർ തൊടുന്നതിന് മുമ്പ് കാലഹരണപ്പെട്ട എൻട്രി മായ്ക്കുകയോ മുകളിൽ എഴുതുകയോ ചെയ്യുക.

ക്വറി എവിടെ പോയെന്ന് തെളിയിക്കുക

ഒരു തിരയലിനിടയിലുള്ള ക്യാപ്ചർ തർക്കം തീർക്കുന്നു: tcpdump -ni eth0 port 53 ഭൗതിക ഇന്റർഫേസിൽ ക്വറികൾ കാണിക്കുന്നു, അതായത് അവ ടണലിന് പുറത്തേക്ക് പോകുന്നു, റിസോൾവർ ഒരിക്കലും മാറ്റിയിട്ടില്ല. dig @10.8.0.1 name.corp.example പിന്നീട് ബാക്കിയുള്ള രണ്ട് സന്ദർഭങ്ങളെ വേർതിരിക്കുന്നു. നേരിട്ടുള്ള ക്വറി ഉത്തരം നൽകിയാൽ റിസോൾവർ പ്രവർത്തിക്കുന്നു, ക്ലയന്റ് അത് ഉപയോഗിക്കുന്നില്ല; സമയം കഴിഞ്ഞാൽ റിസോൾവർ ടണൽ വഴി എത്താനാവില്ല, പ്രാദേശിക മാറ്റം സഹായിക്കില്ല.

ഇപ്പോഴും ഉപയോഗിക്കുന്ന റിസോൾവർ ദാതാവ് നൽകിയതാണെങ്കിൽ, ടണൽ ട്രാഫിക് എൻക്രിപ്റ്റ് ചെയ്യുന്നു, പക്ഷേ നാമങ്ങൾ ആ ദാതാവിന് ദൃശ്യമായി തുടരുന്നു. ഇത് പ്രവർത്തനത്തിന്റെയല്ല, ചോർച്ചയുടെ ചോദ്യമാണ്, അതേ ക്യാപ്ചർ അതിന് ഉത്തരം നൽകുന്നു: ഭൗതിക ഇന്റർഫേസിലെ ക്വറി ടണലിന് പുറത്തുള്ള ആരിലേക്കോ പോകുന്നു.

എത്തിച്ചേരൽ VPN ഹോസ്റ്റിലെ ഫയർവാളിനെയും ഉൾക്കൊള്ളുന്നു, അത് പൂളിൽ നിന്ന് UDP ഉം TCP 53 ഉം അനുവദിക്കണം. അടച്ച പോർട്ട് തകർന്ന പുഷ് പോലെ തന്നെ കാണപ്പെടുന്നു, ടണൽ നെറ്റ്വർക്കിന്റെ ഉള്ളിൽ നിന്ന് മാത്രം ഉത്തരം നൽകുന്ന റിസോൾവറും അങ്ങനെ തന്നെ. ഒരിക്കൽ വിച്ഛേദിച്ച് വീണ്ടും കണക്ട് ചെയ്ത ശേഷം ക്യാപ്ചർ ആവർത്തിക്കുക, കാരണം ആദ്യ കണക്ഷനിൽ പ്രത്യക്ഷപ്പെട്ട് രണ്ടാമത്തേതിൽ അപ്രത്യക്ഷമാകുന്ന ക്രമീകരണങ്ങൾ ഹുക്കിലെ ജീവിതചക്ര തകരാറാണ്, കാണാത്ത ഓപ്ഷനല്ല.

ഒരു ഉടമയെ നിലനിർത്തി ക്രമത്തിൽ പരിശോധിക്കുക

അനുമാനിച്ച ടണൽ അവസ്ഥയെ അടിസ്ഥാനമാക്കി അഡാപ്റ്റർ DNS പുനരെഴുതുന്ന സ്ക്രിപ്റ്റ് പ്രൊഫൈൽ ഇതിനകം വഹിക്കുന്ന കോൺഫിഗറേഷൻ ഇരട്ടിപ്പിക്കുന്നു, അനുമാനം ആദ്യമായി തെറ്റുമ്പോൾ നിശബ്ദമായി പരാജയപ്പെടുന്നു. കണക്ഷന്റെ സ്വന്തം DNS ക്രമീകരണങ്ങളോ ഒരു രേഖപ്പെടുത്തിയ ഹുക്കോ തിരഞ്ഞെടുക്കുക, ഏതാണ് തിരഞ്ഞെടുത്തതെന്ന് രേഖപ്പെടുത്തുക, അടുത്തയാൾ രണ്ടാമത്തേത് ചേർക്കാതിരിക്കാൻ.

നാല് പരിശോധനകളാൽ വലയം അടയ്ക്കുക: പുഷ് ചെയ്ത വിലാസം ടണൽ ലിങ്കിൽ ഉണ്ട്, ആന്തരിക നാമം പൂർണ്ണ യോഗ്യതയുള്ള നാമമായി പരിഹരിക്കപ്പെടുന്നു, അതേ നാമം സഫിക്സ് ഇല്ലാതെ പരിഹരിക്കപ്പെടുന്നു, ഒരു വീണ്ടും കണക്ഷന് ശേഷവും രണ്ടും ശരിയാണ്. ഒരു ക്യാപ്ചർ നാലിൽ ഏതാണ് പരാജയപ്പെട്ടതെന്ന് പറയുന്നു. OpenVPN 2.6 കൈപ്പുസ്തകം ലിസ്റ്റ് ചെയ്യുന്നു dhcp-option ഒപ്പം സ്ക്രിപ്റ്റ് നിർദ്ദേശങ്ങളും അവയുടെ പ്ലാറ്റ്ഫോം കുറിപ്പുകളും.

അനുബന്ധ ലേഖനങ്ങൾ