Pi-hole v6 WireGuard ക്ലയന്റുകളുടെ DNS അന്വേഷണങ്ങൾ എന്തുകൊണ്ട് അവഗണിക്കുന്നു

Pi-hole v6 പോർട്ട് 53-ൽ ഒരു DNS അന്വേഷണം സ്വീകരിച്ച്, എത്തിയ പാക്കറ്റിന് ഉത്തരം നൽകാൻ അനുവാദമുണ്ടോ എന്ന് തീരുമാനിക്കുന്നു. WireGuard ഹോസ്റ്റിൽ ഈ രണ്ടാം തീരുമാനമാണ് സാധാരണയായി ക്ലയന്റിന് ടൈംഔട്ട് ലഭിക്കാനുള്ള കാരണം, അതേസമയം LAN-ൽ നിന്ന് റിസോൾവർ ആരോഗ്യകരമായി കാണുന്നു. പോർട്ട് തുറന്നിരിക്കുന്നു, FTL പ്രവർത്തിക്കുന്നു, എന്നിട്ടും 10.90.0.1-ൽ നിന്ന് ഒന്നും തിരികെ വരുന്നില്ല. ഉത്തരം പുറപ്പെടുന്നതിന് മുൻപ് മൂന്ന് കാര്യങ്ങൾ പരസ്പരം സ്വാധീനിക്കുന്നു: dns.interface, dns.listeningMode എന്നിവയും രണ്ടിനും മുന്നിലുള്ള ഫയർവാളും.

ശ്രവണ സോക്കറ്റ് ആർക്ക് ഉത്തരം ലഭിക്കുമെന്ന് തീരുമാനിക്കുന്നില്ല

FTL പോർട്ട് 53-ൽ UDP, TCP ശ്രോതാക്കളെ തുറക്കുന്നു. സ്ഥിരസ്ഥിതി കോൺഫിഗറേഷനിൽ സോക്കറ്റ് പലപ്പോഴും wildcard ആണ്, അതിനാൽ ss -lunp | grep :53 VPN ക്ലയന്റുകൾക്ക് സേവനം നൽകുന്നോ ഇല്ലയോ എന്നത് കൂടാതെ 0.0.0.0:53, [::]:53 എന്നിവ കാണിക്കുന്നു. wildcard സോക്കറ്റ് പാക്കറ്റ് സ്വീകരിക്കുന്നു, പിന്നീട് FTL ഉത്തരം നൽകുന്നതിന് മുൻപ് തന്റെ ഇന്റർഫേസ്, ഉറവിട നിയമങ്ങൾ പ്രയോഗിക്കുന്നു. അതുകൊണ്ടാണ് "പോർട്ട് ശ്രവിക്കുന്നു" എന്ന പ്രയോഗം ഒരു ടണൽ ക്ലയന്റിനെക്കുറിച്ച് വളരെ കുറച്ച് മാത്രം തെളിയിക്കുന്നത്.

നിങ്ങൾ സജീവമെന്ന് കരുതുന്ന ഫയലിന് പകരം പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷൻ വായിക്കുക. pihole-FTL --config dns.interface കൂടാതെ pihole-FTL --config dns.listeningMode യഥാർത്ഥ മൂല്യങ്ങൾ അച്ചടിക്കുന്നു, കണ്ടെയ്നർ, പരിസ്ഥിതി ചരം അല്ലെങ്കിൽ വിന്യാസ മാനേജർ ആ ക്രമീകരണം കൈവശം വയ്ക്കുമ്പോൾ അവ ഹോസ്റ്റ് ഫയലിൽ നിന്ന് വ്യത്യസ്തമായേക്കാം. Pi-hole FTL കോൺഫിഗറേഷൻ റഫറൻസ് മോഡുകളും അവയിൽ ഏതാണ് ഇന്റർഫേസിനെ ആശ്രയിക്കുന്നത് എന്നും പട്ടികപ്പെടുത്തുന്നു.

LOCAL ഏത് സബ്നെറ്റ് എന്ന് ചോദിക്കുന്നു, SINGLE ഏത് ഇന്റർഫേസ് എന്ന് ചോദിക്കുന്നു

LOCAL, സ്ഥിരസ്ഥിതി, ഉറവിട വിലാസം ഹോസ്റ്റിന്റെ ഒരു ഇന്റർഫേസിൽ ക്രമീകരിച്ച സബ്നെറ്റിൽ പെടുന്ന അന്വേഷണങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. 10.90.0.1/24 ഉള്ള ലളിതമായ wg0 ഈ പരിശോധന പാസാകുന്നു, കാരണം 10.90.0.2-ലെ ക്ലയന്റ് ടണൽ സബ്നെറ്റിനുള്ളിലാണ്. പീയറിന്റെ മറുവശത്ത് റൂട്ട് ചെയ്ത ക്ലയന്റ്, അല്ലെങ്കിൽ മറ്റൊരു പ്രിഫിക്സിൽ NAT-ന് പിന്നിൽ ഒളിച്ചിരിക്കുന്ന ക്ലയന്റ്, പാക്കറ്റ് wg0-ൽ എത്തിയാലും അത് പാസാകുന്നില്ല, ലോഗിൽ ഒരു അന്വേഷണവും പ്രത്യക്ഷപ്പെടുന്നില്ല.

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

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND സോക്കറ്റ് മാറ്റുന്നു, അതിന് വിലയുണ്ട്

BIND wildcard സോക്കറ്റ് ഫിൽട്ടർ ചെയ്യുന്നില്ല; പേരിട്ട ഇന്റർഫേസിൽ നിലനിൽക്കുന്ന വിലാസങ്ങളിലേക്ക് മാത്രം പോർട്ട് 53 ബന്ധിക്കുന്നു, അതിനാൽ കെർണൽ മറ്റെവിടെ നിന്ന് വരുന്ന പാക്കറ്റുകൾ നിരസിക്കുന്നു. ഇത് SINGLE-നേക്കാൾ കർശനമാണ്, അതിന്റെ പര്യായമല്ല. FTL ആരംഭിക്കുമ്പോൾ wg0 ഉയർന്നിട്ടില്ലെങ്കിൽ ബന്ധിക്കാൻ വിലാസം ഉണ്ടാകണമെന്നില്ല, ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെട്ട് FTL വീണ്ടും ആരംഭിക്കുന്നതുവരെ റിസോൾവർ ശ്രോതാവില്ലാതെ പ്രവർത്തിച്ചേക്കാം എന്നതാണ് ബൂട്ടിൽ കാണുന്ന വില.

ആരംഭ ക്രമം നിങ്ങൾ നിയന്ത്രിക്കുമ്പോൾ BIND തിരഞ്ഞെടുക്കുക, ഉദാഹരണത്തിന് WireGuard ഇന്റർഫേസിന് ശേഷം ക്രമീകരിച്ച systemd യൂണിറ്റ്, കൂടാതെ FTL കാണുന്നതിന് മുൻപ് അലഞ്ഞുതിരിയുന്ന പാക്കറ്റുകൾ കെർണൽ വലിച്ചെറിയണമെന്ന് ആഗ്രഹിക്കുമ്പോൾ. ടണൽ വന്നും പോയും ഇരിക്കുമ്പോൾ, അല്ലെങ്കിൽ FTL-ന് ശേഷം ആരംഭിക്കുന്ന ഉപകരണം ഇന്റർഫേസ് സൃഷ്ടിക്കുമ്പോൾ SINGLE തിരഞ്ഞെടുക്കുക.

ഫയർവാൾ രണ്ടാമത്തെ കവാടമാണ്

ശരിയായ FTL മോഡും ഹോസ്റ്റ് ഫയർവാൾ wg0-ൽ പോർട്ട് 53 വലിച്ചെറിയുന്നുവെങ്കിൽ പരാജയപ്പെടും. രണ്ട് പ്രോട്ടോക്കോളുകൾക്കും VPN ഉറവിട ശ്രേണി അനുവദിക്കുകയും ഇന്റർനെറ്റ് വശം അടച്ചിടുകയും ചെയ്യുക. inet filter പട്ടികയിലെ നിലവിലുള്ള input ശൃംഖലയുള്ള nftables-ൽ നിയമങ്ങൾ ഇങ്ങനെ കാണുന്നു:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

ടണൽ IPv6 വഹിക്കുന്നുവെങ്കിൽ യോജിക്കുന്ന IPv6 നിയമങ്ങൾ ചേർക്കുക, ശൃംഖലയുടെ drop നയത്തിന് മുൻപ് അവ ഇടുക. ഹോസ്റ്റ് ufw അല്ലെങ്കിൽ firewalld ഉപയോഗിക്കുന്നുവെങ്കിൽ ഉപകരണങ്ങൾ കൂട്ടിക്കലർത്തുന്നതിന് പകരം അതേ മാനേജറിൽ അതേ പൊരുത്തം പ്രകടിപ്പിക്കുക. ഇന്റർനെറ്റ് റൗട്ടറിൽ നിന്ന് പോർട്ട് 53 ഫോർവേഡ് ചെയ്യരുത്; ക്ലയന്റുകൾ ടണലിലൂടെ റിസോൾവറിന്റെ VPN വിലാസത്തിൽ എത്തണം.

രണ്ട് പാതകൾ വേർതിരിഞ്ഞു നിൽക്കുന്നു. ക്ലയന്റ് അന്വേഷണങ്ങൾ FTL-ൽ അവസാനിക്കുന്നു. FTL-ന്റെ സ്വന്തം അപ്സ്ട്രീം തിരച്ചിലുകൾ ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് പട്ടിക പ്രകാരം പുറപ്പെടുന്നു, അത് ടണൽ ഉപയോഗിച്ചേക്കാം ഇല്ലായിരിക്കാം, അതിനാൽ ഉത്തരം നൽകുകയും എന്നാൽ ഉപയോഗപ്രദമായ ഒന്നും തിരികെ നൽകാതിരിക്കുകയും ചെയ്യുന്ന റിസോൾവർ അപ്സ്ട്രീം പ്രശ്നമാണ്. വെബ് അഡ്മിനും API-യും സ്വന്തം പോർട്ടുകളിൽ ശ്രവിക്കുന്നു, സ്വന്തം നിയന്ത്രണം ആവശ്യമാണ്.

ഉത്തരവും നിരസിക്കലും പരിശോധിക്കുക

VPN ക്ലയന്റിൽ നിന്ന്, രണ്ട് പ്രോട്ടോക്കോളുകളിലും റിസോൾവറിന്റെ വിലാസം ചോദിക്കുക: dig @10.90.0.1 example.com കൂടാതെ dig +tcp @10.90.0.1 example.com. പിന്നീട് അഡ്മിൻ ഇന്റർഫേസിലെ അന്വേഷണ ലോഗ് പരിശോധിച്ച് FTL അന്വേഷണം രേഖപ്പെടുത്തിയെന്ന് ഉറപ്പാക്കുക. ലോഗ് എൻട്രിയില്ലാതെ ക്ലയന്റ് ടൈംഔട്ട് ഫയർവാളിനെയോ ഇന്റർഫേസ് ഫിൽട്ടറിനെയോ സൂചിപ്പിക്കുന്നു; ഉത്തരമില്ലാത്ത ലോഗ് എൻട്രി അപ്സ്ട്രീം പരിഹാരത്തെ സൂചിപ്പിക്കുന്നു.

VPN-ന് പുറത്തുള്ള ഹോസ്റ്റിൽ നിന്ന് നെഗറ്റീവ് പാത പരീക്ഷിക്കുക. dig @10.90.0.1 example.com ടൈംഔട്ട് ആകണം, കൂടാതെ ss -lunp റിസോൾവറിൽ പോർട്ട് 53 പൊതു വിലാസത്തിൽ ബന്ധിച്ചതായി കാണിക്കരുത്. സേവനം ഒരിക്കൽ പുനരാരംഭിക്കുക, പിന്നീട് ഹോസ്റ്റ് റീബൂട്ട് ചെയ്ത് wg0 വീണ്ടും പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷവും റിസോൾവർ ഉത്തരം നൽകുന്നുവെന്ന് ഉറപ്പാക്കുക. അടുത്ത റീബൂട്ട് വരെ മാത്രം പ്രവർത്തിക്കുന്ന അന്വേഷണം പൂർത്തിയായ മാറ്റമല്ല.