OpenVPN ക്ലയന്റുകളെ മറ്റൊരു ഹോസ്റ്റിലെ Pi-hole റിസോൾവറിലേക്ക് വിടുക
തള്ളിവിട്ട DNS ഓപ്ഷൻ ഒരു സർവറിനെ പേരിടുന്നു. VPN ഗേറ്റ്വേയ്ക്ക് ഫോർവേഡിംഗ് വേണം, Pi-hole-ന് തിരിച്ചുവരുന്ന പാതയും ശരിയായ ശ്രവണ രീതിയും വേണം, ക്ലയന്റ് അത് ഉപയോഗിക്കണം.
OpenVPN പ്രൊഫൈലിൽ Pi-hole വിലാസം ഇടുന്നത് അതിലേക്ക് ഒരു പാത സൃഷ്ടിക്കുന്നില്ല, അത് ചോദിക്കാൻ അനുമതി നൽകുന്നില്ല, ക്ലയന്റ് അത് ഉപയോഗിക്കുമെന്ന് ഉറപ്പും നൽകുന്നില്ല. Pi-hole വേറെ LAN യന്ത്രത്തിലിരിക്കുമ്പോൾ നാലു കാര്യങ്ങൾ ഒത്തുചേരണം: ക്ലയന്റിൽ നിന്നുള്ള പാത, ഗേറ്റ്വേയിൽ നിന്നുള്ള ഫോർവേഡിംഗ്, പൂളിലേക്കുള്ള തിരിച്ചുവരവ് പാത, Pi-hole-ൽ തന്നെയുള്ള സ്വീകരണ നയം. ഓരോ പരാജയവും ലോഗിൽ വ്യത്യസ്തമായി കാണാം. അവ ഈ ക്രമത്തിൽ കൈകാര്യം ചെയ്യുന്നത് അവസാനത്തേത് ആദ്യം നന്നാക്കുന്നതിനേക്കാൾ വേഗമേറിയതാണ്. സാധാരണ കുറുക്കുവഴി, ഓരോ ഉറവിടത്തിനും ആവർത്തനം തുറക്കുക, ചെറിയ പ്രശ്നത്തെ സ്ഥിരമായ പ്രശ്നമാക്കി മാറ്റുന്നു.
തള്ളിവിട്ട DNS ഓപ്ഷൻ എന്ത് ചെയ്യുന്നു, എന്ത് ചെയ്യുന്നില്ല
സർവർ താഴെയുള്ള നിർദ്ദേശത്തോടെ ഒരു റിസോൾവർ പ്രഖ്യാപിക്കുന്നു, 192.168.50.53 Pi-hole ഹോസ്റ്റ് എന്ന് കരുതി. ക്ലയന്റ് ഓപ്ഷൻ സ്വീകരിച്ച്, തന്റെ പ്ലാറ്റ്ഫോമും റിസോൾവർ സംയോജനവും അനുസരിച്ച്, അത് ടണൽ ഇന്റർഫേസിൽ പ്രയോഗിക്കുന്നു അല്ലെങ്കിൽ പ്രാദേശിക സ്റ്റബിന് അനുകൂലമായി അവഗണിക്കുന്നു. റൂട്ട് വരി DNS വരിയോളം പ്രധാനമാണ്, കാരണം ക്ലയന്റ് എത്തിച്ചേരാത്ത റിസോൾവർ ഒരു റിസോൾവറുമല്ല. ഇതിൽ ഒന്നും സർവർ വശത്തുനിന്ന് കാണാനാവില്ല.
server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"
ഒരു ഓപ്ഷൻ സ്വീകരിക്കുന്നത് അത് ഉപയോഗിക്കുന്നതിന് തുല്യമല്ല. റിസോൾവർ മാനേജർ ഉള്ള Linux ക്ലയന്റ് തള്ളിവിട്ട സർവർ സ്വീകരിച്ച് ചില ഡൊമെയിനുകൾ മാത്രം അതിലേക്ക് അയയ്ക്കാം; DNS സ്വയം കൈകാര്യം ചെയ്യുന്ന ക്ലയന്റ് ക്രമീകരണം പൂർണ്ണമായി മേലെഴുതാം. തള്ളിവിട്ട റൂട്ടുകൾ ചില പ്ലാറ്റ്ഫോമുകളിൽ പരിമിതമാണ്, ഇത് ഓപ്ഷൻ സ്വീകരിച്ചാലും റിസോൾവറെ ലഭ്യമല്ലാതാക്കുന്നു. ഏത് സർവർ ഉത്തരം നൽകുന്നു എന്ന് ക്ലയന്റിൽ പരിശോധിക്കുക, സർവറിൽ എന്ത് അയച്ചു എന്നല്ല.
ഓപ്ഷൻ സർവർ വശത്തെക്കുറിച്ചും ഒന്നും പറയുന്നില്ല. DNS ട്രാഫിക് ഇപ്പോഴും ക്ലയന്റിൽ നിന്ന് ഗേറ്റ്വേയിലേക്കും ഗേറ്റ്വേയിൽ നിന്ന് Pi-hole-ലേക്കും സഞ്ചരിക്കണം, ഏതെങ്കിലും ഓപ്ഷൻ അർത്ഥവത്താകുന്നതിന് മുമ്പ്. നഷ്ടപ്പെട്ട പാതയും നിരസിക്കപ്പെട്ട ചോദ്യവും ക്ലയന്റിൽ നിന്ന് ഒരുപോലെ കാണാം, അതിനാൽ ആദ്യം ഗേറ്റ്വേയിൽ ഫോർവേഡിംഗ് സ്ഥിരീകരിക്കുക.
Pi-hole-ൽ നിന്ന് പൂളിലേക്കുള്ള തിരിച്ചുവരവ് പാത
ക്ലയന്റിന്റെ ഉറവിട വിലാസം സംരക്ഷിക്കപ്പെട്ടാൽ, Pi-hole VPN പൂളിനുള്ളിലെ ഒരു വിലാസത്തിന് ഉത്തരം നൽകുന്നു. അതിന്റെ സ്വന്തം റൂട്ടിംഗ് പട്ടിക ഈ പൂളിനെക്കുറിച്ച് ഒന്നും അറിയാൻ സാധ്യതയില്ല, അതിനാൽ ഉത്തരം അതിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേയിലേക്ക് പോയി അപ്രത്യക്ഷമാകുന്നു. ചോദ്യ ലോഗ് പൊരുത്തപ്പെടുന്ന ഉത്തരമില്ലാത്ത ഒരു അഭ്യർത്ഥന കാണിക്കുന്നു, ഇത് ഫയർവാൾ പ്രശ്നമായി തെറ്റിദ്ധരിക്കാൻ എളുപ്പമാണ്.
LAN റൗട്ടറിന് പൂളിനായി ഒരു സ്ഥിര റൂട്ട് നൽകുക, OpenVPN ഗേറ്റ്വേ അടുത്ത ഹോപ്പായി, അല്ലെങ്കിൽ Pi-hole-ലേക്ക് ഫോർവേഡ് ചെയ്യുന്നതിന് മുമ്പ് ഗേറ്റ്വേയിൽ ഉറവിടം വിവർത്തനം ചെയ്യുക. ആദ്യത്തേത് ഓരോ ക്ലയന്റിന്റെയും വിലാസങ്ങൾ Pi-hole ചോദ്യ ലോഗിൽ കാണാവുന്നതായി നിർത്തുന്നു. രണ്ടാമത്തേത് തിരിച്ചുവരവ് റൂട്ട് ആവശ്യകത നീക്കുന്നു പക്ഷേ ഓരോ ചോദ്യവും ഗേറ്റ്വേയിൽ നിന്ന് വന്നതായി കാണിക്കുന്നു. ഒന്നും തെറ്റല്ല; അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു.
ക്ലയന്റ് അടിസ്ഥാനമാക്കിയ റിപ്പോർട്ടിംഗോ നയമോ പ്രധാനമെങ്കിൽ സ്ഥിര റൂട്ടാണ് മികച്ച കൈമാറ്റം. LAN മറ്റൊരാൾ കൈകാര്യം ചെയ്യുകയും റൂട്ട് ലഭ്യമല്ലെങ്കിലും, വിവർത്തനമാണ് പ്രായോഗിക ഓപ്ഷൻ, ക്ലയന്റ് ഐഡന്റിറ്റി നഷ്ടപ്പെടുന്നത് രേഖപ്പെടുത്തി. നിങ്ങൾ ഏതാണ് തിരഞ്ഞെടുത്തതെന്ന് എഴുതുക, കാരണം തുടർന്നുള്ള ഓരോ ലോഗ് ചോദ്യവും അതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
റൂട്ട് ചെയ്ത ക്ലയന്റുകൾക്കുള്ള Pi-hole ശ്രവണ രീതി
DNS-ന് കീഴിലുള്ള ക്രമീകരണ പേജിലെ ഇന്റർഫേസ് ശ്രവണ സ്വഭാവത്തിന്റെ ഡ്രോപ്പ്ഡൗൺ Pi-hole ഏത് ഉറവിടങ്ങൾക്ക് ഉത്തരം നൽകണം എന്ന് തീരുമാനിക്കുന്നു. ഏറ്റവും കർശനമായ ഓപ്ഷൻ നേരിട്ട് ബന്ധിപ്പിച്ച നെറ്റ്വർക്കുകളിലെ ക്ലയന്റുകളെ മാത്രം സ്വീകരിക്കുന്നു; ഉപകരണങ്ങൾക്ക് പരമാവധി ഒരു ഹോപ്പ് ദൂരം അനുവദിക്കുന്ന ഓപ്ഷൻ അത് അടുത്തുള്ള റൗട്ടറിന് പിന്നിലെ ഉപനെറ്റ്വർക്കുകളിലേക്ക് വ്യാപിപ്പിക്കുന്നു, റൂട്ട് ചെയ്ത VPN ക്ലയന്റ് കൃത്യമായി അങ്ങനെയാണ് കാണപ്പെടുന്നത്. പാക്കറ്റ് യഥാർത്ഥത്തിൽ LAN ഇന്റർഫേസിൽ എത്തുന്നു, പക്ഷേ അതിന്റെ ഉറവിട വിലാസം മറ്റൊരു ഉപനെറ്റ്വർക്കിന്റേതാണ്. ഇത് നയത്തിന്റെ നിരസിക്കലാണ്, റൂട്ടിംഗ് പരാജയമല്ല, ലോഗുകൾ വായിക്കുമ്പോൾ ഈ വ്യത്യാസം പ്രധാനമാണ്.
Pi-hole-ന്റെ ശ്രവണ ഗൈഡ് പ്രാദേശികമായി ബന്ധിപ്പിച്ച ഉറവിടങ്ങളെ റൂട്ട് ചെയ്ത ഉറവിടങ്ങളിൽ നിന്ന് വേർതിരിക്കുന്നു, ആഗമന ഇന്റർഫേസ് മാനദണ്ഡമല്ല. മുഴുവൻ ഇന്റർനെറ്റിനും അനുമതി നൽകാതെ VPN പൂളിന് അനുമതി നൽകുന്ന ഒരു രീതി തിരഞ്ഞെടുക്കുക, തുടർന്ന് അത് പൂളിൽ നിന്ന് മാത്രം DNS സ്വീകരിക്കുന്ന ഫയർവാൾ നിയമവുമായി ജോടിയാക്കുക.
ആദ്യ ചോദ്യം പ്രവർത്തിക്കാൻ എല്ലാ ഉറവിടങ്ങൾക്കും ആവർത്തനം തുറക്കുന്നത് തെറ്റായ അറ്റകുറ്റപ്പണിയാണ്. അത് സ്വകാര്യ റിസോൾവറെ തുറന്നതാക്കി മാറ്റുന്നു, തിരുത്തൽ പരിമിതമായ അനുമതിയാണ്, ആഗോളമല്ല.
ഉത്തരം ചോദ്യ ലോഗുമായി ചേർക്കുക
ക്ലയന്റിനോട് ചോദിക്കുക, തുടർന്ന് സർവർ പരിശോധിച്ച് രണ്ടും താരതമ്യം ചെയ്യുക. systemd-resolved ക്ലയന്റിൽ താഴെയുള്ള കമാൻഡുകൾ ഏത് റിസോൾവർ ഉത്തരം ഉണ്ടാക്കി, ഓരോ ലിങ്കിനും ഏത് സർവറുകൾ കോൺഫിഗർ ചെയ്തിട്ടുണ്ട് എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. Pi-hole മാത്രം അറിയുന്ന ഒരു പേര് ഉപയോഗിക്കുക, കാരണം Pi-hole വിലാസത്തിലേക്കുള്ള നേരിട്ടുള്ള ചോദ്യം എത്തിച്ചേരൽ തെളിയിക്കുന്നു, കോൺഫിഗറേഷനല്ല.
resolvectl query intranet.example.lan
resolvectl dns
പ്രതീക്ഷിക്കുന്ന ഉത്തരം 192.168.50.53-നെ സർവറായി പേരിടുകയും ആ റിസോൾവർ മാത്രം അറിയുന്ന ഒരു വിലാസം തിരികെ നൽകുകയും ചെയ്യുന്നു. തുടർന്ന് Pi-hole-ന്റെ സ്വന്തം കാഴ്ച നോക്കുക: pihole -t ചോദ്യ ലോഗ് നേരിട്ട് പിന്തുടരുന്നു, ഓരോ വരിയും ഉറവിട വിലാസം വഹിക്കുന്നു. ഉറവിടം ക്ലയന്റിന്റെ ടണൽ വിലാസമാണെങ്കിൽ പൂൾ പാത കേടുകൂടാതെയിരിക്കുന്നു. അത് ഗേറ്റ്വേയുടെ LAN വിലാസമാണെങ്കിൽ ഉറവിട വിവർത്തനം നടക്കുന്നു, ക്ലയന്റിന്റെ സ്വന്തം വിലാസം ഒരിക്കലും കാണപ്പെടില്ല.
ലോഗിൽ ഒന്നും കാണാനില്ലെങ്കിൽ ചോദ്യം ഒരിക്കലും Pi-hole-ൽ എത്തിയിട്ടില്ല, അടുത്ത പരിശോധന ഗേറ്റ്വേയിലെ ഫോർവേഡിംഗാണ്. ചോദ്യം കാണുകയും ഉത്തരം തിരികെ വരാതിരിക്കുകയും ചെയ്താൽ പ്രശ്നം തിരിച്ചുവരവ് പാതയിലാണ്, അതായത് മുൻ വിഭാഗത്തിൽ. പരാജയം ഇങ്ങനെ വിഭജിക്കുന്നത് റൂട്ടിംഗ് പിശകിനെ ഫയർവാൾ നിയമമായി തെറ്റിദ്ധരിക്കുന്നത് തടയുന്നു.
ഗേറ്റ്വേയുടെ ഫോർവേഡിംഗ് നിയമം പരിശോധിക്കുക
ഗേറ്റ്വേ ക്ലയന്റിന്റെ DNS പാക്കറ്റുകൾ Pi-hole-ലേക്ക് ഫോർവേഡ് ചെയ്യണം, അത് ചെയ്യുന്ന നിയമം ഊഹിക്കാതെ വായിക്കണം. താഴെയുള്ള കമാൻഡുകൾ പോർട്ട് 53-ൽ സ്പർശിക്കുന്ന നിയമങ്ങൾ കൗണ്ടറുകളോടെ പട്ടികപ്പെടുത്തുന്നു, ഒരു nftables ഹോസ്റ്റിലും ഒരു iptables ഹോസ്റ്റിലും. നിലവിലുണ്ടെങ്കിലും പൂജ്യം പൊരുത്തങ്ങൾ കാണിക്കുന്ന നിയമം, ട്രാഫിക് വിവർത്തനത്തിന് മുമ്പ് തള്ളപ്പെടുന്നു എന്നതിന്റെ സൂചനയാണ്.
sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53
കൗണ്ടറുകൾ വായിക്കുക, നിയമങ്ങൾ മാത്രമല്ല. ഒരിക്കലും പൊരുത്തപ്പെടാത്ത നിയമം അർത്ഥമാക്കുന്നത് പാക്കറ്റ് മറ്റൊരു ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു, അല്ലെങ്കിൽ ക്ലയന്റ് അത് ഒരിക്കലും അയച്ചിട്ടില്ല. ഓരോ ചോദ്യത്തിലും പൊരുത്തപ്പെടുന്ന നിയമം അർത്ഥമാക്കുന്നത് ഫോർവേഡിംഗ് പ്രവർത്തിക്കുന്നു, പ്രശ്നം പാതയിൽ കൂടുതൽ മുന്നിലാണ്.
ഹോസ്റ്റ് ഏത് ഉപകരണം ഉപയോഗിച്ചാലും പരിശോധന ഇടുങ്ങിയതായി നിർത്തുക: പൂൾ ഉറവിടമായി, പോർട്ട് 53 ലക്ഷ്യമായി, Pi-hole ഏക അനുവദനീയ ലക്ഷ്യമായി. പോർട്ട് 80-നും അനുമതി നൽകുന്ന വിശാല ഫോർവേഡിംഗ് നിയമം സംഭവിക്കാൻ കാത്തിരിക്കുന്ന മറ്റൊരു പ്രശ്നമാണ്.