Nasmerujte klienty OpenVPN na resolver Pi-hole na inom hostiteľovi

Vloženie adresy Pi-hole do profilu OpenVPN nevytvorí cestu k nej, neudelí oprávnenie dopytovať sa jej ani nezaručí, že ju klient použije. Keď Pi-hole beží na samostatnom počítači v LAN, musia sa zísť štyri veci: trasa od klienta, preposielanie z brány, spiatočná cesta do poolu a politika príjmu na samotnom Pi-hole. Každá porucha vyzerá v logu inak. Prejsť ich v tomto poradí je rýchlejšie ako opravovať poslednú ako prvú. Obvyklá skratka, otvorenie rekurzie pre každý zdroj, vymení malý problém za trvalý.

Čo vtláčaná voľba DNS robí a čo nie

Server inzeruje resolver pomocou nižšie uvedenej direktívy za predpokladu, že 192.168.50.53 je hostiteľ Pi-hole. Klient voľbu dostane a, podľa svojej platformy a integrácie resolvera , použije ju na rozhranie tunela alebo ju ignoruje v prospech lokálneho stubu. Riadok trasy je rovnako dôležitý ako riadok DNS, pretože resolver, na ktorý sa klient nedostane, nie je žiadny resolver. Nič z toho nie je zo strany servera vidieť.

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"

Prijať voľbu nie je to isté ako používať ju. Klient Linuxu so správcom resolvera môže vtláčaný server prijať a posielať mu len určité domény; klient, ktorý si DNS spravuje sám, môže nastavenie úplne prepísať. Vtláčané trasy sú na niektorých platformách tiež obmedzené, čo ponechá resolver nedostupný, aj keď bola voľba prijatá. Kontrolujte na klientovi, ktorý server odpovedá, nie na serveri, čo bolo odoslané.

Voľba tiež nič nehovorí o strane servera. Prevádzka DNS musí stále putovať od klienta k bráne a od brány k Pi-hole, kým začne akákoľvek voľba niečo znamenať. Chýbajúca trasa a odmietnutá požiadavka vyzerajú z pohľadu klienta rovnako, preto najprv potvrďte preposielanie na bráne.

Spiatočná cesta z Pi-hole do poolu

Ak zostane zdrojová adresa klienta zachovaná, Pi-hole odpovedá na adresu vnútri poolu VPN. Jeho vlastná smerovacia tabuľka o tomto poole pravdepodobne nič nevie, takže odpoveď ide na jeho predvolenú bránu a zmizne. Protokol dopytov ukazuje požiadavku bez zodpovedajúcej odpovede, čo sa dá ľahko zameniť s problémom brány firewall.

Dajte routeru v LAN statickú trasu do poolu s bránou OpenVPN ako ďalším skokom, alebo preložte zdroj na bráne pred preposlaním do Pi-hole. Prvý variant udržiava adresy jednotlivých klientov viditeľné v protokole dopytov Pi-hole. Druhý odstraňuje požiadavku spiatočnej trasy, ale každý dopyt vyzerá, akoby prišiel z brány. Ani jeden nie je nesprávny; odpovedajú na rôzne otázky.

Ak záleží na reportingu alebo politike pre jednotlivých klientov, statická trasa je lepšou výmenou. Ak LAN spravuje niekto iný a trasa nie je dostupná, preklad je pragmatickou voľbou, so stratou identity klienta zapísanou. Zaznamenajte, ktorú ste zvolili, pretože od toho závisí každá ďalšia otázka k logom.

Režim počúvania Pi-hole pre smerované klienty

Rozbaľovací zoznam správania počúvania rozhraní na stránke nastavení v časti DNS rozhoduje, ktorým zdrojom Pi-hole odpovedá. Najprísnejšia voľba prijíma len klientov v priamo pripojených sieťach; voľba povoľujúca zariadenia najviac jeden skok ďaleko to rozširuje na podsiete za susedným routerom, a tak smerovaný klient VPN vyzerá. Paket na rozhranie LAN skutočne dorazí, ale jeho zdrojová adresa patrí do inej podsiete. Je to odmietnutie politikou, nie zlyhanie smerovania, a ten rozdiel je pri čítaní logov podstatný.

Príručka Pi-hole k počúvaniu oddeľuje lokálne pripojené zdroje od smerovaných pôvodov a rozhranie príchodu nie je kritériom. Zvoľte režim, ktorý povoľuje pool VPN bez povolenia celého internetu, a spojte ho s pravidlom firewallu, ktoré prijíma DNS iba z poolu.

Otvoriť rekurziu všetkým pôvodom, aby prvý dopyt fungoval, je nesprávna oprava. Mení súkromný resolver na otvorený a opravou je obmedzené oprávnenie, nie globálne.

Zlaďte odpoveď s protokolom dopytov

Opýtajte sa klienta, potom skontrolujte server a oba porovnajte. Na klientovi so systemd-resolved nižšie uvedené príkazy hlásia, ktorý resolver vytvoril odpoveď a ktoré servery sú nakonfigurované pre jednotlivé spojenia. Použite meno, ktoré pozná iba Pi-hole, pretože priamy dopyt na adresu Pi-hole dokazuje dosiahnuteľnosť, nie konfiguráciu.

resolvectl query intranet.example.lan
resolvectl dns

Očakávaná odpoveď uvádza 192.168.50.53 ako server a vracia adresu, ktorú by poznal iba tento resolver. Potom sa pozrite na vlastný pohľad Pi-hole: pihole -t sleduje protokol dopytov naživo a každý riadok nesie zdrojovú adresu. Ak je zdrojom adresa tunela klienta, trasa poolu je v poriadku. Ak je to adresa LAN brány, v hre je preklad zdroja a vlastná adresa klienta sa nikdy neobjaví.

Ak sa v logu neobjaví vôbec nič, dopyt sa k Pi-hole nikdy nedostal a ďalšou vecou na kontrolu je preposielanie na bráne. Ak sa dopyt objaví a žiadna odpoveď sa nevracia, problémom je spiatočná cesta, teda predchádzajúca časť. Rozdelenie poruchy týmto spôsobom bráni tomu, aby bola chyba smerovania považovaná za pravidlo firewallu.

Skontrolujte pravidlo preposielania brány

Brána musí preposielať DNS pakety klienta smerom k Pi-hole a pravidlo, ktoré to robí, stojí za prečítanie, nie za predpoklad. Nižšie uvedené príkazy vypisujú pravidlá týkajúce sa portu 53 s počítadlami, na hostiteľovi nftables a na hostiteľovi iptables. Pravidlo, ktoré existuje, ale ukazuje nula zásahov, je signálom, že prevádzka sa zahadzuje skôr, než je preložená.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Čítajte počítadlá, nie len pravidlá. Pravidlo, ktoré nikdy nezodpovedá, znamená, že paket odchádza iným rozhraním alebo že ho klient nikdy neposlal. Pravidlo, ktoré zodpovedá každému dopytu, znamená, že preposielanie funguje a problém je ďalej po ceste.

Nech už hostiteľ používa akýkoľvek nástroj, držte kontrolu úzku: pool ako zdroj, port 53 ako cieľ a Pi-hole ako jediný povolený cieľ. Široké pravidlo preposielania, ktoré povoľuje aj port 80, je iný problém čakajúci na vznik.