DNS റീഡയറക്ടിനു ശേഷം dnsmasq അന്വേഷണങ്ങൾ VPN-ൽ നിന്നു പുറത്തുപോകുന്നതെന്തുകൊണ്ട്

LAN ക്ലയന്റ് തന്റെ VPN-ൽ ശരിയായി എത്തുന്നു, എന്നിട്ടും അതിന്റെ DNS അന്വേഷണങ്ങൾ തെറ്റായ മേൽഭാഗ ലിങ്കിൽ പ്രത്യക്ഷപ്പെടുന്നു. ഇത് സാധാരണ അർത്ഥത്തിൽ ഒരു ചോർച്ചയല്ല; റൗട്ടർ അന്വേഷണം കൈമാറ്റം ചെയ്യുന്നത് നിർത്തി സ്വയം ഉത്തരം നൽകുമ്പോൾ സംഭവിക്കുന്നതാണ് ഇത്. ഇടപെടൽ ലക്ഷ്യം ഒരു പ്രാദേശിക സോക്കറ്റിലേക്ക് മാറ്റിഎഴുതുന്നു, തുടർന്ന് റിസോൾവർ സ്വന്തം സ്രോതസ്സ് വിലാസവും സ്വന്തം റൂട്ടിംഗ് തീരുമാനവുമുള്ള രണ്ടാമത്തെ, ബന്ധമില്ലാത്ത സംഭാഷണം തുറക്കുന്നു. ക്ലയന്റിന്റെ ഫ്ലോയിൽ ചേർത്ത അടയാളങ്ങൾ ആദ്യ സംഭാഷണത്തെ വിവരിക്കുന്നു, രണ്ടാമത്തേതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

അടയാളം അന്വേഷണത്തോടൊപ്പം യാത്ര ചെയ്യുന്നില്ല

പാക്കറ്റ് അടയാളങ്ങൾ conntrack എൻട്രിയിലും പറക്കുന്ന പാക്കറ്റിലും ജീവിക്കുന്നു. ഒരു REDIRECT നിയമം ആ യാത്ര അവസാനിപ്പിക്കുന്നു: പേലോഡ് ഒരു പ്രാദേശിക സോക്കറ്റിനു കൈമാറുന്നു, യഥാർത്ഥ എൻട്രി തന്റെ ജോലി ചെയ്തു കഴിഞ്ഞു. അതിനുശേഷം റൗട്ടറിൽ നിന്നു പുറത്തുപോകുന്നത് റിസോൾവർ പ്രോസസ് സൃഷ്ടിച്ച പുതിയ സോക്കറ്റാണ്, അതിന്റെ സ്രോതസ്സ് റൗട്ടറിന്റെ സ്വന്തം വിലാസമാണ്.

അതുകൊണ്ടാണ് LAN ക്ലയന്റിന്റെ വിലാസത്തിൽ കീ ചെയ്ത പോളിസി റൂട്ട് അപ്സ്ട്രീം അന്വേഷണവുമായി ഒരിക്കലും ഒത്തുപോകാത്തത്. പുതിയ സോക്കറ്റ് ക്ലയന്റിന്റേതല്ല, dnsmasq-ന്റേതാണ്, കെർണൽ റൂട്ട് റൗട്ടറിന്റെ സ്വന്തം ട്രാഫിക്കിനായി വിലയിരുത്തുന്നു. സ്രോതസ്സ് നിയമങ്ങൾ, ഇന്റർഫേസ് നിയമങ്ങൾ, അടയാള നിയമങ്ങൾ എല്ലാം വ്യത്യസ്ത tuple കാണുന്നു. അടയാളം പകരുന്നു എന്ന് കരുതുന്നതാണ് ഈ ക്രമീകരണത്തിലെ ഏറ്റവും സാധാരണ തെറ്റ്, ക്ലയന്റ് വശത്തെ ക്യാപ്ചറിൽ അത് കാണാനാവില്ല.

രണ്ടു സംഭാഷണങ്ങളും ഒരു പേരും ഒരു സമയവും പങ്കിടുന്നു, ക്യാപ്ചർ വേഗത്തിൽ നോക്കുമ്പോൾ അവയെ ഒരു ഫ്ലോ പോലെ തോന്നിപ്പിക്കുന്നത് അതാണ്.

എവിടെയാണ് കൈമാറ്റം പ്രാദേശിക പരിഹാരമാകുന്നത്

53-ാം പോർട്ട് റീഡയറക്ട് ചെയ്യപ്പെടുന്നുണ്ടോ, മറ്റൊരു ഹോസ്റ്റിലേക്ക് വിവർത്തനം ചെയ്യപ്പെടുന്നുണ്ടോ, അതോ അതേപടി വിടുന്നുണ്ടോ എന്ന് കണ്ടെത്തിക്കൊണ്ട് തുടങ്ങുക, കാരണം മൂന്നു കേസുകളും വ്യത്യസ്തമായി പെരുമാറുന്നു. പ്രാദേശിക പോർട്ടിലേക്കുള്ള റീഡയറക്ട് കൈമാറ്റം അവസാനിപ്പിക്കുന്നു, മറ്റൊരു യന്ത്രത്തിലേക്കുള്ള വിവർത്തനം പാക്കറ്റിനെ ചലനത്തിൽ നിർത്തുകയും ക്ലയന്റിന്റെ tuple അർത്ഥവത്താക്കി നിർത്തുകയും ചെയ്യുന്നു.

രണ്ടു പ്രോട്ടോക്കോളുകളും നോക്കുക. UDP-യിലും TCP-യിലും എത്താവുന്ന റിസോൾവർ രണ്ടിലും പരീക്ഷിക്കപ്പെടും, UDP മാത്രം ഉൾക്കൊള്ളുന്ന നിയമക്കൂട്ടം വലിയ ഉത്തരങ്ങൾക്കായി ഒരു നിശ്ശബ്ദ ദ്വാരം വിടുന്നു. റൗട്ടറിന്റെ സ്വന്തം കോൺഫിഗറേഷൻ മാനേജർ സൃഷ്ടിക്കുന്ന നിയമങ്ങളും കണക്കാക്കപ്പെടുന്നു, സൃഷ്ടിച്ച ഫയൽ തിരുത്തുന്നത് സാധാരണയായി അടുത്ത റീലോഡിനോട് തോൽക്കുന്നു.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

ആ ഔട്ട്പുട്ടുകൾ ക്രമത്തിൽ മൂന്നു ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു: എന്താണ് അന്വേഷണം വീണ്ടും എഴുതുന്നത്, എന്താണ് അത് സ്വീകരിക്കുന്നത്, ഏത് പ്രോസസാണ് കേൾക്കുന്ന സോക്കറ്റിന്റെ ഉടമ. ഉടമ അറിഞ്ഞുകഴിഞ്ഞാൽ അപ്സ്ട്രീം പോളിസിക്ക് ജീവിക്കാൻ ഒരിടമുണ്ട്.

റിസോൾവർക്ക് അതിന്റേതായ എഗ്രസ് പോളിസി നൽകുക

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

server=/corp.example/10.30.0.53@tun_work
log-queries

മുകളിലെ ഡൊമെയിൻ, വിലാസം, ഇന്റർഫേസ് എന്നിവ നിങ്ങളുടെ സ്വന്തം മൂല്യങ്ങൾക്കുള്ള പ്ലേസ്ഹോൾഡറുകളാണ്. ഡൊമെയിൻ തിരഞ്ഞെടുപ്പും എഗ്രസ് നിയന്ത്രണവും വേറിട്ട തീരുമാനങ്ങളായി തുടരുന്നു: റൂട്ട് നിലനിൽക്കണം, സ്രോതസ്സ് വിലാസത്തിന് അപ്സ്ട്രീം റിസോൾവർ അനുമതി നൽകണം, ഫയർവാൾ ഉത്തരത്തിന് അനുമതി നൽകണം. ഇന്റർഫേസ് മാത്രമുള്ള വഴികാട്ടൽ fail-closed അല്ല, കാരണം അപ്രത്യക്ഷമായ ടണൽ റിസോൾവറെ മറ്റൊരു വഴിയിലേക്ക് വീഴ്ത്തിയേക്കാം. സ്വകാര്യമായി തുടരേണ്ട നാമമേഖലയിൽ നിന്ന് ഏതെങ്കിലും പൊതു ബദൽ അകറ്റി നിർത്തുക.

വരി സൃഷ്ടിച്ച ഫയലിലല്ല, റൗട്ടർ പിന്തുണയ്ക്കുന്ന കോൺഫിഗറേഷൻ ഉടമയിൽ വയ്ക്കുക, അല്ലാത്തപക്ഷം അടുത്ത റീലോഡ് തിരുത്തൽ മായ്ക്കും.

പങ്കിട്ട കാഷെക്ക് സംരക്ഷിക്കാനാവാത്തത്

ഒരു കാഷെയുള്ള ഒരു ഫോർവേഡർ ഓരോ LAN ക്ലയന്റിനെയും സേവിക്കുന്നു, അത് ചില നെറ്റ്വർക്കുകൾക്ക് ആവശ്യമായ ഒരു വേർതിരിവ് തകർക്കുന്നു. രണ്ടു ക്ലയന്റുകൾക്ക് ഒരേ പേര് വ്യത്യസ്തമായി പരിഹരിക്കേണ്ടിവന്നാൽ, ആരാണ് ചോദിച്ചതെന്ന് വീണ്ടെടുക്കാൻ പങ്കിട്ട സോക്കറ്റിന് വഴിയില്ല. ഓരോ ക്ലയന്റിനുമുള്ള പോളിസി വേറിട്ട റിസോൾവർ ഇൻസ്റ്റൻസുകളിലോ ഐഡന്റിറ്റി നിലനിർത്തുന്ന ഫോർവേഡിംഗ് സവിശേഷതയിലോ ജീവിക്കണം.

കാഷെ ചെയ്ത ഉത്തരവും പുതിയ വഴിയെക്കുറിച്ചുള്ള തെളിവല്ല. അപ്സ്ട്രീം റൂട്ട് തകർന്നു കിടക്കുമ്പോൾ ഉത്തരം മെമ്മറിയിൽ നിന്നു വന്നേക്കാം.

53-ാം പോർട്ടിലെ നിയമങ്ങൾ DNS-നെ HTTPS-ലോ TLS-ലോ സംസാരിക്കുന്ന ആപ്ലിക്കേഷനുകളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ആ അന്വേഷണങ്ങൾ റീഡയറക്ടിൽ എത്തുന്നേയില്ല, അതിനാൽ 53-ാം പോർട്ടിൽ മാത്രം കെട്ടിയ പോളിസി ട്രാഫിക്കിന്റെ ഒരു ഉപഗണം മാത്രം വിവരിക്കുന്നു എന്ന് രേഖപ്പെടുത്തേണ്ടതുണ്ട്.

രണ്ടാം സംഭാഷണം പരിശോധിക്കുക, ആദ്യത്തേതല്ല

നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു പേര് ഉപയോഗിച്ച് പരീക്ഷിച്ച് ഇരുവശവും നിരീക്ഷിക്കുക. ക്ലയന്റ് വശത്തെ ക്യാപ്ചർ അന്വേഷണം LAN വിട്ടുവെന്ന് തെളിയിക്കുന്നു; അതിനുശേഷം അത് എവിടെപ്പോയി എന്ന് റൗട്ടർ വശം മാത്രം തെളിയിക്കുന്നു.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

ഓരോ ശ്രമത്തിനും മുമ്പ് കാഷെ ഒഴിവാക്കുക, കാരണം ചൂടുള്ള ഉത്തരം തകർന്ന അപ്സ്ട്രീം മറയ്ക്കുന്നു. TCP-യിൽ ആവർത്തിക്കുക, തുടർന്ന് ടണൽ ഓഫ് ചെയ്ത് ആവർത്തിക്കുക, ഇഷ്ടപ്പെട്ട വഴി പോയാൽ റിസോൾവർ എന്തു ചെയ്യുന്നു എന്ന് കാണാൻ. ആ അവസാന സ്വഭാവമാണ് രൂപകൽപ്പന fail-closed ആണോ വെറും ഭാഗ്യമാണോ എന്ന് തീരുമാനിക്കുന്നത്.