ആന്തരിക നാമങ്ങൾ VPN-ൽ പരാജയപ്പെടുന്നു, പൊതു സൈറ്റുകൾ തുറക്കുന്നു

ഒരു ഉപയോക്താവ് റിപ്പോർട്ട് ചെയ്യുന്നത് VPN-ൽ ഇന്ട്രാനെറ്റ് ഹോസ്റ്റ്നെയിം പരിഹരിക്കപ്പെടുന്നില്ല എന്നാണ്. അതേ ലാപ്ടോപ്പിൽ നിന്നുള്ള രണ്ടാമത്തെ റിപ്പോർട്ട്, ലീക്ക് ടെസ്റ്റ് ഇപ്പോഴും പ്രാദേശിക റിസോൾവർ ഉത്തരം നൽകുന്ന ചോദ്യങ്ങൾ കാണിക്കുന്നു എന്ന് പറയുന്നു. അവ ഒരു പ്രശ്നം പോലെ തോന്നുമെങ്കിലും രണ്ടാണ്, വ്യത്യസ്ത തെളിവുകളോടെ, ഒന്നാമത്തേതിനുള്ള സാധാരണ പരിഹാരം രണ്ടാമത്തേതിനെ മോശമാക്കുന്നു. ഏതെങ്കിലും ക്രമീകരണം തൊടുന്നതിന് മുമ്പ് അവ വേർതിരിക്കുക.

ഒരു തകരാറല്ലാത്ത രണ്ട് ലക്ഷണങ്ങൾ

ആന്തരിക നാമം പരിഹരിക്കാനാകാത്തത് എന്നാൽ ചോദ്യം അതിന് ഉത്തരമില്ലാത്ത എവിടെയോ പോയി എന്നാണ്. ടണലിൽ നിന്ന് പുറത്തുപോകുന്ന ചോദ്യങ്ങൾ എന്നാൽ ഉത്തരം ലഭ്യമായിരുന്നിട്ടും ചോദ്യം തെറ്റായ സ്ഥലത്ത് പോയി എന്നാണ്. അവ വിപരീത തകരാറുകളാണ്: ഒന്ന് കാണാതായ ഉത്തരമാണ്, മറ്റൊന്ന് അധിക ലക്ഷ്യസ്ഥാനമാണ്.

കെണി എന്നത് ഓഫീസ് റിസോൾവർ എല്ലായിടത്തും ചേർക്കുന്നത് ഒന്നാമത്തേത് ശരിയാക്കുകയും രണ്ടാമത്തേത് ഉറപ്പാക്കുകയും ചെയ്യുന്നു എന്നതാണ്. പൊതു റിസോൾവർ എല്ലായിടത്തും ചേർക്കുന്നത് വിപരീതം ചെയ്യുന്നു.

രണ്ട് നിരീക്ഷണങ്ങളും സമയമുദ്രയോടെ എഴുതി, തുടർന്ന് താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക.

ഏത് അഡാപ്റ്ററിന്റെ റിസോൾവർ ചോദ്യം സ്വീകരിക്കുന്നു

Windows-ൽ DNS ക്ലയന്റ് അഡാപ്റ്റർ ബൈൻഡിംഗ് ക്രമം അനുസരിച്ച് സെർവറുകൾ തിരഞ്ഞെടുക്കുന്നു, ടണൽ അഡാപ്റ്റർ സ്വയമേവ ആദ്യത്തേതല്ല. അഡാപ്റ്ററിന്റെ വിപുലമായ ക്രമീകരണങ്ങൾ തുറന്ന് റിമോട്ട് ആക്സസ് കണക്ഷൻ ഫിസിക്കൽ അഡാപ്റ്ററിന് മുകളിലേക്ക് നീക്കി, മാറ്റം പുതിയ സെഷനിൽ ബാധകമാകാൻ വീണ്ടും കണക്ട് ചെയ്യുക.

ബൈൻഡിംഗ് ക്രമം ആദ്യ പകുതി മാത്രമാണ്. ഏത് നാമങ്ങൾ ആ അഡാപ്റ്ററിന് സ്വന്തമാണെന്ന് ക്ലയന്റിന് അറിയണം, അത് ക്രമത്തിന്റെയല്ല സഫിക്സിന്റെ ചോദ്യമാണ്.

ടണൽ ഓണായിരിക്കുമ്പോൾ എടുത്ത പ്രവർത്തിക്കുന്ന മെഷീന്റെ ipconfig /all ലാപ്ടോപ്പിന്റേതിന് അടുത്ത് വയ്ക്കുക. പ്രവർത്തിക്കുന്ന മെഷീൻ അതിന്റെ ഓഫീസ് അഡാപ്റ്ററിൽ കണക്ഷൻ-നിർദ്ദിഷ്ട DNS സഫിക്സ് കാണിക്കും, ലാപ്ടോപ്പ് ടണലിൽ ഒന്നും കാണിക്കണമെന്നില്ല. ആ വ്യത്യാസം സെർവർ അവിടെത്തന്നെയുണ്ട്, പക്ഷേ നാമം ഇപ്പോഴും പരാജയപ്പെടുന്നു എന്ന റിപ്പോർട്ടുകളുടെ ഒരു മുഴുവൻ വിഭാഗത്തെ വിശദീകരിക്കുന്നു, കാരണം സഫിക്സ് ഇല്ലാതെ ചെറിയ നാമം ഓഫീസ് റിസോൾവർ നൽകുന്ന സോണിലേക്ക് ഒരിക്കലും പൂർത്തിയാകുന്നില്ല.

ചെറിയ നാമത്തിന് ആദ്യം സഫിക്സ് വേണം, പിന്നെ റൂട്ട്

യോഗ്യതയില്ലാത്ത ഹോസ്റ്റ്നെയിം ടൈപ്പ് ചെയ്യുന്നത് റിസോൾവറിനോട് ഒരു ഡൊമെയ്ൻ ഊഹിക്കാൻ ആവശ്യപ്പെടുന്നു. ഊഹം കണക്ഷനോട് ബന്ധിപ്പിച്ച സഫിക്സ് പട്ടികയിൽ നിന്ന് വരുന്നു, ആ പട്ടിക ശൂന്യമാണെങ്കിൽ ചോദ്യം ഒരു ലേബലായി പുറത്തുപോകുന്നു, അതിന് ഒരു സ്വകാര്യ സോണും പൊരുത്തപ്പെടില്ല.

പ്രവർത്തിക്കുന്ന മെഷീന്റെ സഫിക്സ് DNS ടാബിലെ VPN അഡാപ്റ്ററിന്റെ IPv4 പ്രോപ്പർട്ടികളിലേക്ക് പകർത്തി വീണ്ടും കണക്ട് ചെയ്യുക. Linux-ൽ തത്തുല്യമായത് ടണൽ ലിങ്കിലെ സെർച്ച് ഡൊമെയ്നാണ്, systemd-resolved അത് ആഗോളമായല്ല ഓരോ ലിങ്കിനും വെവ്വേറെ കാണിക്കുന്നു.

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

റിസോൾവറിനോട് നേരിട്ട് ചോദിക്കുക, പിന്നെ നാമത്തോട്

ഓഫീസ് റിസോൾവറിലേക്കുള്ള നേരിട്ടുള്ള ചോദ്യം പേരിന്റെ പ്രശ്നത്തെ പാതയുടെ പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കുന്നു, കാരണം അത് ക്ലയന്റിന്റെ റിസോൾവർ തിരഞ്ഞെടുപ്പിനെ പൂർണ്ണമായും ഒഴിവാക്കുന്നു.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

ആദ്യ കമാൻഡ് ഒരു നിർദ്ദിഷ്ട സെർവറിനോട് പൂർണ്ണമായി യോഗ്യതയുള്ള നാമം ആവശ്യപ്പെടുന്നു. അത് ഉത്തരം നൽകിയാൽ റിസോൾവറും അതിലേക്കുള്ള പാതയും കുഴപ്പമില്ല, തകരാർ തിരഞ്ഞെടുപ്പിലോ സഫിക്സിലോ ആണ്. സമയം കഴിഞ്ഞാൽ വിലാസം തെറ്റാണ് അല്ലെങ്കിൽ എത്തിച്ചേരാനാവില്ല, പ്രശ്നം DNS അല്ല റൂട്ടിംഗ് ആണ്. രണ്ടാം കമാൻഡ് ചെറിയ നാമത്തിൽ എന്ത് സംഭവിക്കുന്നു എന്ന് കാണിക്കുന്നു, മൂന്നാമത്തേത് systemd ഹോസ്റ്റിൽ ഓരോ ലിങ്കിന്റെയും റിസോൾവർ കോൺഫിഗറേഷൻ പ്രിന്റ് ചെയ്യുന്നു.

അജ്ഞാത നാമങ്ങൾക്ക് ചില നെറ്റ്വർക്കുകൾ നൽകുന്ന വൈൽഡ്കാർഡ് ഉത്തരങ്ങൾ ശ്രദ്ധിക്കുക. സത്യസന്ധമായി തോന്നുന്ന ഉത്തരം ഉദ്ദേശിച്ച സെർവർ ഉത്തരം നൽകി എന്നതിന്റെ തെളിവല്ല, അതിനാൽ തിരികെ ലഭിച്ച വിലാസം ആന്തരിക സേവനം യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്നതുമായി താരതമ്യം ചെയ്യുക. വിലാസം ഒരു പാർക്കിംഗ് പേജിന്റേതോ പ്രോക്സിയുടേതോ ആണെങ്കിൽ റിസോൾവർ ഉത്തരം നൽകി, പക്ഷേ ഉത്തരം ഒരിക്കലും നിങ്ങളുടേതായിരുന്നില്ല. ആ വ്യത്യാസം മുഴുവൻ സമയവും പ്രവർത്തിച്ചിരുന്ന ഒരു ടണലിനെ പിന്തുടരാൻ ഒരു മണിക്കൂർ ലാഭിക്കുന്നു.

Linux-ൽ /etc/resolv.conf മാറ്റിയെഴുതുന്ന VPN ക്ലയന്റ് പ്രാദേശിക റിസോൾവറുകൾ പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കുന്നു. vpnc അത് തടയാൻ DNSUpdate no നൽകുന്നു, systemd-resolved ലിസ്റ്റ് ചെയ്ത ഡൊമെയ്നുകൾ മാത്രം ടണൽ ലിങ്കിലേക്ക് റൂട്ട് ചെയ്യാം. രണ്ട് സമീപനങ്ങളും പൊതു നാമങ്ങൾ പ്രാദേശിക റിസോൾവറിൽ നിർത്തി ആന്തരിക നാമങ്ങൾ ഓഫീസിലേക്ക് അയയ്ക്കുന്നു.

ചോർച്ച ഒരു നിയമമാണ്, ഒരു ചെക്ക്ബോക്സല്ല

നാമ പരിഹാരം പോർട്ട് 53-ലേക്കുള്ള UDP കൈമാറ്റമാണ്, അതിനാൽ വെബ് ട്രാഫിക് കൊണ്ടുപോകുന്നുവെങ്കിലും UDP അല്ലാത്ത ടണൽ ചോദ്യം ഫിസിക്കൽ പാതയിൽ വിടുന്നു. ഒരു പൊതു നാമം പരിഹരിക്കുമ്പോൾ ഫിസിക്കൽ NIC-യിൽ ക്യാപ്ചർ ചെയ്ത് അത് തെളിയിക്കുക. ആ ഇന്റർഫേസിൽ വായിക്കാവുന്ന രൂപത്തിൽ ചോദ്യം കാണുന്നത് ടണൽ അത് കൊണ്ടുപോകുന്നില്ല എന്നാണ്.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

ആ ഇന്റർഫേസിൽ വായിക്കാവുന്ന രൂപത്തിൽ ചോദ്യം പ്രത്യക്ഷപ്പെട്ടാൽ ടണൽ അത് കൊണ്ടുപോകുന്നില്ല. പരിഹാരം VPN അയച്ച റിസോൾവറിന് മാത്രം പോർട്ട് 53 അനുവദിക്കുകയും മറ്റ് ലക്ഷ്യസ്ഥാനങ്ങൾ ഒഴിവാക്കുകയും ചെയ്യുന്ന ഒരു നിയമമാണ്, കൂടെ അയച്ച ഓപ്ഷൻ നിശബ്ദമായി ഒഴിവാക്കാത്ത ക്ലയന്റ് കോൺഫിഗറേഷനും.

ആ അവസാന ഭാഗം കാണുന്നതിലും പ്രധാനമാണ്. OpenVPN route-nopull ഉപയോഗിച്ച് ആരംഭിക്കുകയാണെങ്കിൽ അയച്ച DNS ഓപ്ഷൻ റൂട്ടുകളോടൊപ്പം അപ്രത്യക്ഷമാകും, അത് നിലനിർത്താൻ പുൾ ഫിൽട്ടർ വിശാലമാക്കിയില്ലെങ്കിൽ. dhcp-option DNS അവഗണിക്കുന്ന ക്ലയന്റ് മുമ്പ് ഉണ്ടായിരുന്നത് തുടർന്നും ഉപയോഗിക്കും. സെർവർ വശത്തുള്ള ഏത് മാറ്റവും പ്രാബല്യത്തിൽ വരാൻ പുതിയ സെഷൻ ആവശ്യപ്പെടുന്നു, കാരണം ടണൽ ഉയരുമ്പോൾ റിസോൾവർ പട്ടിക നൽകുന്നു, കാലഹരണപ്പെട്ട സെഷൻ പഴയ അവസ്ഥ തുടർന്നും കാണിക്കുന്നു.

ടിക്കറ്റ് അടയ്ക്കുന്നതിന് മുമ്പ് ഏത് തകരാർ യഥാർത്ഥത്തിൽ നിരീക്ഷിച്ചു എന്ന് രേഖപ്പെടുത്തുക. കാണാതായ ആന്തരിക ഉത്തരവും ടണലിൽ നിന്ന് രക്ഷപ്പെടുന്ന ചോദ്യവും വ്യത്യസ്ത പരിഹാരങ്ങൾ ആവശ്യപ്പെടുന്നു, ഒന്നാമത്തേത് ശരിയാക്കുന്ന സഫിക്സ് മാറ്റം രണ്ടാമത്തേതിനെ നിശബ്ദമായി മോശമാക്കാം. ടിക്കറ്റ് ഏറ്റെടുക്കുന്ന അടുത്തയാൾ ലേബൽ വിശ്വസിക്കും, അതിനാൽ ലേബൽ കൃത്യമാക്കുക.