Nasměrujte klienty OpenVPN na resolver Pi-hole na jiném hostiteli

Vložení adresy Pi-hole do profilu OpenVPN nevytvoří cestu k ní, neudělí oprávnění dotazovat se jí ani nezaručí, že ji klient použije. Když Pi-hole běží na samostatném počítači v LAN, musí se sejít čtyři věci: trasa od klienta, předávání z brány, zpáteční cesta do poolu a politika příjmu na samotném Pi-hole. Každá porucha vypadá v logu jinak. Projít je v tomto pořadí je rychlejší než opravovat poslední jako první. Obvyklá zkratka, otevření rekurze pro každý zdroj, vymění malý problém za trvalý.

Co vtlačená volba DNS dělá a co ne

Server inzeruje resolver pomocí níže uvedené direktivy za předpokladu, že 192.168.50.53 je hostitel Pi-hole. Klient volbu obdrží a, podle své platformy a integrace resolveru , použije ji na rozhraní tunelu, nebo ji ignoruje ve prospěch místního stubu. Řádek trasy je stejně důležitý jako řádek DNS, protože resolver, na který se klient nedostane, není žádný resolver. Nic z toho není ze strany serveru vidět.

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"

Přijmout volbu není totéž jako ji používat. Klient Linuxu se správcem resolveru může vtlačený server přijmout a posílat mu jen určité domény; klient, který si DNS spravuje sám, může nastavení zcela přepsat. Vtlačené trasy jsou na některých platformách také omezené, což ponechá resolver nedostupný, i když byla volba přijata. Kontrolujte na klientovi, který server odpovídá, ne na serveru, co bylo odesláno.

Volba také nic neříká o straně serveru. Provoz DNS musí stále putovat od klienta k bráně a od brány k Pi-hole, než začne jakákoli volba něco znamenat. Chybějící trasa a odmítnutý dotaz vypadají z pohledu klienta stejně, proto nejprve potvrďte předávání na bráně.

Zpáteční cesta z Pi-hole do poolu

Zůstane-li zdrojová adresa klienta zachována, Pi-hole odpovídá na adresu uvnitř poolu VPN. Jeho vlastní směrovací tabulka o tomto poolu pravděpodobně nic neví, takže odpověď jde na jeho výchozí bránu a zmizí. Protokol dotazů ukazuje požadavek bez odpovídající odpovědi, což lze snadno zaměnit za problém brány firewall.

Dejte routeru v LAN statickou trasu do poolu s bránou OpenVPN jako dalším skokem, nebo přeložte zdroj na bráně před předáním do Pi-hole. První varianta udržuje adresy jednotlivých klientů viditelné v protokolu dotazů Pi-hole. Druhá odstraňuje požadavek zpáteční trasy, ale každý dotaz vypadá, jako by přišel z brány. Ani jedna není špatná; odpovídají na různé otázky.

Pokud záleží na reportingu nebo politice pro jednotlivé klienty, je statická trasa lepší výměnou. Pokud LAN spravuje někdo jiný a trasa není k dispozici, je překlad pragmatickou volbou, se ztrátou identity klienta zapsanou. Zaznamenejte, kterou jste zvolili, protože na tom závisí každá další otázka k logům.

Režim naslouchání Pi-hole pro směrované klienty

Rozbalovací seznam chování naslouchání rozhraní na stránce nastavení v části DNS rozhoduje, kterým zdrojům Pi-hole odpovídá. Nejpřísnější volba přijímá jen klienty v přímo připojených sítích; volba povolující zařízení nejvýše jeden skok daleko to rozšiřuje na podsítě za sousedním routerem, a tak směrovaný klient VPN vypadá. Paket na rozhraní LAN skutečně dorazí, ale jeho zdrojová adresa patří do jiné podsítě. Je to odmítnutí politikou, nikoli selhání směrování, a ten rozdíl je při čtení logů podstatný.

Průvodce Pi-hole k naslouchání odděluje lokálně připojené zdroje od směrovaných původů a rozhraní příchodu není kritériem. Zvolte režim, který povoluje pool VPN, aniž by povoloval celý internet, a spojte ho s pravidlem firewallu, které přijímá DNS pouze z poolu.

Otevřít rekurzi všem původům, aby první dotaz fungoval, je špatná oprava. Mění soukromý resolver na otevřený a opravou je omezené oprávnění, nikoli globální.

Slaďte odpověď s protokolem dotazů

Zeptejte se klienta, pak zkontrolujte server a oba porovnejte. Na klientu se systemd-resolved níže uvedené příkazy hlásí, který resolver vytvořil odpověď a které servery jsou nakonfigurovány pro jednotlivá spojení. Použijte jméno, které zná jen Pi-hole, protože přímý dotaz na adresu Pi-hole dokazuje dosažitelnost, ne konfiguraci.

resolvectl query intranet.example.lan
resolvectl dns

Očekávaná odpověď uvádí 192.168.50.53 jako server a vrací adresu, kterou by znal jen tento resolver. Pak se podívejte na vlastní pohled Pi-hole: pihole -t sleduje protokol dotazů živě a každý řádek nese zdrojovou adresu. Je-li zdrojem adresa tunelu klienta, je trasa poolu v pořádku. Je-li to adresa LAN brány, je ve hře překlad zdroje a vlastní adresa klienta se nikdy neobjeví.

Pokud se v logu neobjeví vůbec nic, dotaz se k Pi-hole nikdy nedostal a další věcí ke kontrole je předávání na bráně. Pokud se dotaz objeví a žádná odpověď se nevrací, problémem je zpáteční cesta, tedy předchozí část. Rozdělení poruchy tímto způsobem brání tomu, aby byla chyba směrování považována za pravidlo firewallu.

Zkontrolujte pravidlo předávání brány

Brána musí předávat DNS pakety klienta směrem k Pi-hole a pravidlo, které to dělá, stojí za přečtení, ne za předpoklad. Níže uvedené příkazy vypisují pravidla týkající se portu 53 s počítadly, na hostiteli nftables a na hostiteli iptables. Pravidlo, které existuje, ale ukazuje nula zásahů, je signálem, že provoz je zahazován dřív, než je přeložen.

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

Čtěte počítadla, ne jen pravidla. Pravidlo, které nikdy neodpovídá, znamená, že paket odchází jiným rozhraním, nebo že ho klient nikdy neposlal. Pravidlo, které odpovídá každému dotazu, znamená, že předávání funguje a problém je dál po cestě.

Ať hostitel používá jakýkoli nástroj, držte kontrolu úzkou: pool jako zdroj, port 53 jako cíl a Pi-hole jako jediný povolený cíl. Široké pravidlo předávání, které povoluje i port 80, je jiný problém čekající na vznik.