OpenVPN-clients naar een Pi-hole-resolver op een andere host laten wijzen

Een Pi-hole-adres in een OpenVPN-profiel zetten maakt nog geen pad ernaartoe, geeft geen toestemming om hem te bevragen en garandeert niet dat de client hem gebruikt. Staat Pi-hole op een aparte LAN-machine, dan moeten vier dingen kloppen: de route vanaf de client, de doorsturing vanaf de gateway, het retourpad naar de pool en het ontvangstbeleid op Pi-hole zelf. Elke storing ziet er anders uit in een log. Ze in die volgorde afwerken gaat sneller dan de laatste als eerste repareren. De gebruikelijke sluiproute, recursie openzetten voor elke bron, ruilt een klein probleem in voor een permanent probleem.

Wat de gepushte DNS-optie wel en niet doet

De server adverteert een resolver met de onderstaande richtlijn, ervan uitgaand dat 192.168.50.53 de Pi-hole-host is. De client ontvangt de optie en, afhankelijk van zijn platform en resolverintegratie , past hem toe op de tunnelinterface of negeert hem ten gunste van een lokale stub. De routelijn is net zo belangrijk als de DNS-regel, want een resolver die de client niet kan bereiken is helemaal geen resolver. Niets hiervan is vanaf de serverzijde zichtbaar.

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"

Een optie ontvangen is niet hetzelfde als hem gebruiken. Een Linux-client met een resolverbeheerder accepteert de gepushte server misschien en stuurt alleen bepaalde domeinen ernaartoe; een client die DNS zelf beheert, kan de instelling volledig overschrijven. Gepushte routes zijn op sommige platforms ook beperkt, waardoor de resolver onbereikbaar blijft ook al is de optie geaccepteerd. Controleer op de client welke server antwoordt, niet op de server wat er is verstuurd.

De optie zegt ook niets over de serverzijde. DNS-verkeer moet nog steeds van de client naar de gateway en van de gateway naar Pi-hole reizen voordat welke optie dan ook telt. Een ontbrekende route en een geweigerde query zien er vanaf de client hetzelfde uit, dus bevestig eerst de doorsturing op de gateway.

Het retourpad van Pi-hole naar de pool

Blijft het bronadres van de client behouden, dan antwoordt Pi-hole naar een adres binnen de VPN-pool. Zijn eigen routingtabel weet waarschijnlijk niets van die pool, dus het antwoord gaat naar zijn standaardgateway en verdwijnt. Het querylog toont een verzoek zonder bijpassend antwoord, wat makkelijk als firewallprobleem te lezen is.

Geef de LAN-router een statische route voor de pool met de OpenVPN-gateway als volgende hop, of vertaal de bron op de gateway voordat er naar Pi-hole wordt doorgestuurd. De eerste houdt de adressen per client zichtbaar in het querylog van Pi-hole. De tweede haalt de eis van een retourroute weg, maar laat elke query lijken alsof hij van de gateway komt. Geen van beide is fout; ze beantwoorden verschillende vragen.

Als rapportage of beleid per client belangrijk is, is de statische route de betere ruil. Wordt het LAN door iemand anders beheerd en is er geen route beschikbaar, dan is vertaling de pragmatische optie, met het verlies van clientidentiteit opgeschreven. Leg vast welke je hebt gekozen, want elke latere logvraag hangt daarvan af.

De luistermodus van Pi-hole voor gerouteerde clients

De vervolgkeuzelijst voor luistergedrag van interfaces, op de instellingenpagina onder DNS, bepaalt aan welke bronnen Pi-hole antwoordt. De strengste optie accepteert alleen clients op direct aangesloten netwerken; de optie die apparaten op hoogstens één hop afstand toestaat, breidt dat uit naar subnetten achter een aangrenzende router, en zo ziet een gerouteerde VPN-client eruit. Het pakket komt wel aan op de LAN-interface, maar het bronadres hoort bij een ander subnet. Dat is een beleidsweigering en geen routingfout, en het verschil is van belang wanneer je logs leest.

De luistergids van Pi-hole scheidt lokaal aangesloten bronnen van gerouteerde herkomsten, en de aankomstinterface is niet de toets. Kies een modus die de VPN-pool toestaat zonder het hele internet toe te staan, en combineer die met een firewallregel die DNS alleen uit de pool accepteert.

Recursie voor alle herkomsten openzetten om de eerste query werkend te krijgen is de verkeerde reparatie. Het maakt van een privéresolver een open resolver, en de oplossing is een beperkte toestemming in plaats van een globale.

Het antwoord aan het querylog koppelen

Vraag het de client, controleer dan de server en vergelijk de twee. Op een systemd-resolved-client melden de onderstaande commando's welke resolver een antwoord heeft geproduceerd en welke servers per link zijn geconfigureerd. Gebruik een naam die alleen Pi-hole kent, want een directe query naar het Pi-hole-adres bewijst bereikbaarheid en niet configuratie.

resolvectl query intranet.example.lan
resolvectl dns

Het verwachte antwoord noemt 192.168.50.53 als server en geeft een adres terug dat alleen die resolver zou kennen. Kijk dan naar de eigen weergave van Pi-hole: pihole -t volgt het querylog live, en elke regel draagt het bronadres. Is de bron het tunneladres van de client, dan is de poolroute intact. Is het het LAN-adres van de gateway, dan is bronvertaling in het spel en zal het eigen adres van de client nooit verschijnen.

Als er helemaal niets in het log verschijnt, heeft de query Pi-hole nooit bereikt en is de doorsturing op de gateway het volgende om te controleren. Verschijnt de query wel en komt er geen antwoord terug, dan is het retourpad het probleem, dus de vorige sectie. De storing zo splitsen voorkomt dat een routingfout voor een firewallregel wordt aangezien.

De doorstuurregel van de gateway controleren

De gateway moet de DNS-pakketten van de client richting Pi-hole doorsturen, en de regel die dat doet is het lezen waard in plaats van aan te nemen. De onderstaande commando's tonen de regels die poort 53 raken, met tellers, op een nftables-host en op een iptables-host. Een regel die bestaat maar nul treffers toont, is het signaal dat verkeer wordt weggegooid voordat het wordt vertaald.

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

Lees de tellers, niet alleen de regels. Een regel die nooit treft, betekent dat het pakket via een andere interface vertrekt, of dat de client het nooit heeft verstuurd. Een regel die bij elke query treft, betekent dat de doorsturing werkt en dat het probleem verderop in het pad zit.

Welk hulpmiddel de host ook gebruikt, houd de controle nauw: de pool als bron, poort 53 als bestemming en Pi-hole als het enige toegestane doel. Een brede doorstuurregel die ook poort 80 toestaat, is een ander probleem dat staat te wachten om te gebeuren.