ഓഫീസ് LAN-ൽ ആന്തരിക നാമം ഉടനടി പ്രതികരിക്കുന്നു. VPN കണക്ട് ചെയ്ത ക്ഷണത്തിൽ അത് പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു, ആപ്ലിക്കേഷൻ ടൈംഔട്ട് റിപ്പോർട്ട് ചെയ്യുന്നു, ടണൽ സ്വയം പരാതിയില്ലാതെ ട്രാഫിക് കടത്തിവിടുന്നു. മാറിയത് റിസോൾവർ ആണ്, ആ റിസോൾവറിന് സ്വകാര്യ വിലാസങ്ങളെക്കുറിച്ച് സ്വന്തം അഭിപ്രായമുണ്ട്.

ഒരു പ്രത്യേക തന്ത്രം തടയാനാണ് റീബൈൻഡ് സംരക്ഷണം ഉള്ളത്. ബോധപൂർവം പ്രസിദ്ധീകരിച്ച സ്വകാര്യ നാമം സംരക്ഷണം പ്രവർത്തിക്കുന്നത്ര സമാനമായി കാണപ്പെടുന്നു.

നയം വായിക്കുന്നതിന് മുമ്പ് ഉത്തരം വായിക്കുക

VPN യഥാർത്ഥത്തിൽ നൽകുന്ന റിസോൾവറിനോട് നാമം ചോദിക്കുക, വീട്ടിൽ നിങ്ങളുടെ ലാപ്ടോപ്പ് ഉപയോഗിക്കുന്ന റിസോൾവറിനോടല്ല. ഉത്തരം നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന റെക്കോർഡുമായി താരതമ്യം ചെയ്യുക, മറുപടി ശൂന്യമാണോ, നിരസിച്ചതാണോ, അതല്ലെങ്കിൽ ആരും ആസൂത്രണം ചെയ്യാത്ത പൊതു വിലാസങ്ങൾ നിറഞ്ഞതാണോ എന്ന് രേഖപ്പെടുത്തുക.

രോഗലക്ഷണങ്ങൾ ഒന്നിനൊന്ന് കവിയുന്നു, അതിനാൽ ഉത്തരത്തിന്റെ രൂപമാണ് രോഗനിർണയം തീരുമാനിക്കുന്നത്. NXDOMAIN എന്നാൽ കാണാത്ത റെക്കോർഡ്, REFUSED എന്നാൽ പ്രവേശന നിയമം, ആന്തരിക നാമത്തിന് പൊതു വിലാസം എന്നാൽ നയം അല്ലെങ്കിൽ split-DNS പിശക്, ക്ലയന്റിന് ഉപയോഗിക്കാനാകാത്ത ശരിയായ സ്വകാര്യ വിലാസം തികച്ചും വേറെ പ്രശ്നമാണ്. നിരസിച്ച കണക്ഷനോ നിശ്ചലമായ അഭ്യർത്ഥനയോ സ്വയം ഒന്നും തെളിയിക്കുന്നില്ല, അതിനാൽ ഇത്തരം ടിക്കറ്റുകളിലെ ആദ്യ കമാൻഡ് റീസ്റ്റാർട്ടല്ല, തിരയലായിരിക്കണം. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഉത്തരം എഴുതിവയ്ക്കുക.

സംരക്ഷണം യഥാർത്ഥത്തിൽ തടയുന്നത്

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

dnsmasq അതേ പെരുമാറ്റം ഡൊമെയിൻ അടിസ്ഥാനത്തിലുള്ള ഒഴിവാക്കലുകൾക്കൊപ്പം രേഖപ്പെടുത്തുന്നു. തന്റെ മാനുവലിൽ അത്തരം വിലാസങ്ങൾ നിയമാനുസൃതമായി തിരികെ നൽകാവുന്ന ഡൊമെയിനുകൾ പേരിടാനുള്ള മാർഗമായി rebind-domain-ok വിശദീകരിക്കുന്നു. ഉദ്ദേശിച്ച പരിഹാരം പരിധിയുള്ള അനുമതിയാണ്, ആഗോള സ്വിച്ചല്ല എന്ന സൂചനയായി അത് വായിക്കുക.

ഒഴിവാക്കൽ നാമസ്പേസിൽ പരിമിതപ്പെടുത്തുക

ആദ്യം നാമസ്പേസ് ശരിയാക്കുക, പിന്നെ ഒഴിവാക്കൽ. പരാജയപ്പെടുന്ന നാമം സംഘടന നിയന്ത്രിക്കുന്ന ഡൊമെയിനിൽ പെടുന്നതും റെക്കോർഡ് ബോധപൂർവം പരിപാലിക്കുന്നതുമാണെന്ന് ഉറപ്പാക്കുക. പരിചിതമായ LAN ശ്രേണിയോട് സാമ്യമുള്ളത് മാത്രമായ അപ്രതീക്ഷിത വിലാസം ഒഴിവാക്കലല്ല, സംശയത്തിന് അർഹമാണ്, അതിനാൽ ഏതെങ്കിലും അനുമതി എഴുതുന്നതിന് മുമ്പ് സോണിന്റെ ഉടമയെ പരിശോധിക്കുക.

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

പിന്നെ ഉദ്ദേശിച്ച നാമങ്ങളെ ഉൾക്കൊള്ളുന്ന ഏറ്റവും ഇടുങ്ങിയ അനുമതി ചേർക്കുക: ഒരു ഡൊമെയിൻ, അല്ലെങ്കിൽ ഒരു ഡെലിഗേറ്റ് ചെയ്ത സബ്ഡൊമെയിൻ, VPN ക്ലയന്റുകൾ ചോദിക്കുന്ന റിസോൾവർ കോൺഫിഗറേഷനിൽ. ആ റിസോൾവറിലെ എല്ലാ നാമത്തിനും സംരക്ഷണം ഓഫാക്കുന്നത് അവയെല്ലാത്തിനും ഒരുമിച്ച് സംരക്ഷണം നീക്കിക്കളയുന്നു, ഒരിക്കലും ആവശ്യമില്ലാത്ത നാമങ്ങൾ ഉൾപ്പെടെ.

Split DNS അതേ തീരുമാനത്തിന്റെ ഭാഗമാണ്. സ്വകാര്യ നാമസ്പേസിന് ആന്തരിക റിസോൾവർ മാത്രം ഉത്തരം നൽകേണ്ടതാണെങ്കിൽ, അവിടെ പ്രസിദ്ധീകരിക്കുകയും പൊതു റിസോൾവറുകളിലേക്ക് ചോരുന്നത് നിർത്തുകയും ചെയ്യുക, അപ്പോൾ ഒഴിവാക്കൽ എല്ലാ പാതയല്ല, ഒരു പാതയെ ഉൾക്കൊള്ളും.

വിഭവവും സംരക്ഷണവും വീണ്ടും പരിശോധിക്കുക

വീണ്ടും ചോദിക്കുക, പിന്നെ സേവനത്തിലേക്ക് കണക്ട് ചെയ്ത് ക്ലയന്റ് കാണുന്നത് പരിശോധിക്കുക. പ്രവർത്തിക്കുന്ന സെഷനോടുകൂടിയ ശരിയായ സ്വകാര്യ ഉത്തരം എന്നാൽ ഒഴിവാക്കൽ പ്രാബല്യത്തിൽ വന്നു. നിശ്ചലമായ സെഷനോടുകൂടിയ ശരിയായ ഉത്തരം എന്നാൽ അടുത്ത സംശയം റൂട്ടോ സേവനത്തിന്റെ ഐഡന്റിറ്റിയോ ആണ്.

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

അതേ റിസോൾവർ വഴി ഒരു പൊതു നാമവും പരിശോധിക്കുക. ഒഴിവാക്കലിന് പുറത്തുള്ള നാമങ്ങൾക്ക് സംരക്ഷണം ഇപ്പോഴും ശരിയായി പ്രവർത്തിക്കണം, ആ പരിശോധന പരാജയപ്പെട്ടാൽ മാറ്റം ഉദ്ദേശിച്ചതിലും വിശാലമായിരുന്നു. സർട്ടിഫിക്കറ്റ് സാധുതാ പരിശോധന ഒടുവിൽ വരെ തൊടാതെ നിലനിർത്തുക, കാരണം ശരിയായി റിസോൾവ് ചെയ്യുന്ന നാമവും സേവനം അവതരിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റുമായി പൊരുത്തപ്പെടണം.

നിരസിച്ച ഉത്തരം, ഡൊമെയിൻ, റിസോൾവർ, നയത്തിന്റെ ഉടമ എന്നിവ ടിക്കറ്റിൽ രേഖപ്പെടുത്തുക. ആ രേഖയാണ് ദുരൂഹമായ ആന്തരിക തകരാറിനെ ആർക്കെങ്കിലും പരിശോധിക്കാവുന്ന കോൺഫിഗറേഷൻ മാറ്റമാക്കി മാറ്റുന്നത്.

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