OpenVPN-Clients auf einen Pi-hole-Resolver auf einem anderen Host zeigen

Eine Pi-hole-Adresse in ein OpenVPN-Profil einzutragen schafft noch keinen Pfad dorthin, erteilt keine Berechtigung für Abfragen und stellt nicht sicher, dass der Client sie nutzt. Steht Pi-hole auf einem eigenen LAN-Rechner, müssen vier Dinge zusammenpassen: die Route vom Client, die Weiterleitung am Gateway, der Rückweg zum Pool und die Annahmerichtlinie auf Pi-hole selbst. Jeder Fehler sieht im Protokoll anders aus. Sie in dieser Reihenfolge abzuarbeiten geht schneller, als den letzten zuerst zu beheben. Der übliche Abkürzungsweg, Rekursion für jede Quelle zu öffnen, tauscht ein kleines Problem gegen ein dauerhaftes.

Was die per Push gesetzte DNS-Option tut und was nicht

Der Server gibt mit der folgenden Direktive einen Resolver bekannt, wobei 192.168.50.53 als Pi-hole-Host angenommen wird. Der Client erhält die Option und je nach Plattform und Resolver-Integration , wendet sie auf die Tunnel-Schnittstelle an oder ignoriert sie zugunsten eines lokalen Stubs. Die Route-Zeile zählt genauso viel wie die DNS-Zeile, denn ein Resolver, den der Client nicht erreichen kann, ist überhaupt kein Resolver. Nichts davon ist von der Serverseite aus sichtbar.

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"

Eine Option zu empfangen ist nicht dasselbe wie sie zu nutzen. Ein Linux-Client mit einem Resolver-Manager akzeptiert vielleicht den gepushten Server und schickt nur bestimmte Domains dorthin; ein Client, der DNS selbst verwaltet, überschreibt die Einstellung womöglich vollständig. Gepushte Routen sind auf manchen Plattformen zudem eingeschränkt, wodurch der Resolver unerreichbar bleibt, obwohl die Option akzeptiert wurde. Prüfe am Client, welcher Server antwortet, und nicht am Server, was gesendet wurde.

Die Option sagt außerdem nichts über die Serverseite aus. DNS-Verkehr muss trotzdem erst vom Client zum Gateway und vom Gateway zu Pi-hole gelangen, bevor irgendeine Option zählt. Eine fehlende Route und eine abgelehnte Abfrage sehen vom Client aus gleich aus, also bestätige zuerst die Weiterleitung am Gateway.

Der Rückweg von Pi-hole zum Pool

Bleibt die Quelladresse des Clients erhalten, antwortet Pi-hole an eine Adresse innerhalb des VPN-Pools. Die eigene Routing-Tabelle weiß von diesem Pool wahrscheinlich nichts, also geht die Antwort an ihr Standard-Gateway und verschwindet. Das Abfrageprotokoll zeigt eine Anfrage ohne passende Antwort, was leicht als Firewall-Problem missverstanden wird.

Gib dem LAN-Router eine statische Route für den Pool mit dem OpenVPN-Gateway als nächstem Hop, oder übersetze die Quelle am Gateway, bevor an Pi-hole weitergeleitet wird. Die erste Variante hält die Adressen der einzelnen Clients im Abfrageprotokoll von Pi-hole sichtbar. Die zweite beseitigt die Anforderung einer Rückroute, lässt aber jede Abfrage so aussehen, als käme sie vom Gateway. Keine von beiden ist falsch; sie beantworten unterschiedliche Fragen.

Wenn Berichte oder Richtlinien pro Client wichtig sind, ist die statische Route der bessere Tausch. Wird das LAN von jemand anderem verwaltet und ist keine Route verfügbar, ist die Übersetzung die pragmatische Option, mit dem Verlust der Client-Identität, der dokumentiert gehört. Halte fest, welche Variante du gewählt hast, denn jede spätere Protokollfrage hängt davon ab.

Pi-holes Lauschmodus für geroutete Clients

Das Auswahlfeld für das Lauschverhalten der Schnittstelle auf der Seite Einstellungen unter DNS entscheidet, welchen Quellen Pi-hole antwortet. Die strengste Option akzeptiert nur Clients in direkt angeschlossenen Netzen; die Option, die Geräte höchstens einen Hop entfernt zulässt, dehnt das auf Subnetze hinter einem benachbarten Router aus, und so sieht ein gerouteter VPN-Client aus. Das Paket kommt zwar auf der LAN-Schnittstelle an, aber seine Quelladresse gehört zu einem anderen Subnetz. Das ist eine Richtlinien-Ablehnung und kein Routing-Fehler, und der Unterschied zählt, wenn du Protokolle liest.

Der Pi-hole-Lauschleitfaden trennt lokal angeschlossene Quellen von gerouteten Ursprüngen, und die Ankunftsschnittstelle ist nicht das Kriterium. Wähle einen Modus, der den VPN-Pool zulässt, ohne das ganze Internet zuzulassen, und kombiniere ihn mit einer Firewall-Regel, die DNS nur aus dem Pool akzeptiert.

Rekursion für alle Quellen zu öffnen, damit die erste Abfrage klappt, ist die falsche Reparatur. Sie macht aus einem privaten Resolver einen offenen, und die Lösung ist eine eingegrenzte Berechtigung statt einer globalen.

Die Antwort mit dem Abfrageprotokoll abgleichen

Frage den Client, prüfe dann den Server und vergleiche beides. Auf einem systemd-resolved-Client melden die folgenden Befehle, welcher Resolver eine Antwort erzeugt hat und welche Server pro Link konfiguriert sind. Nutze einen Namen, den nur Pi-hole kennt, denn eine direkte Abfrage an die Pi-hole-Adresse belegt Erreichbarkeit und nicht Konfiguration.

resolvectl query intranet.example.lan
resolvectl dns

Die erwartete Antwort nennt 192.168.50.53 als Server und liefert eine Adresse, die nur dieser Resolver kennen würde. Sieh dir dann Pi-holes eigene Sicht an: pihole -t verfolgt das Abfrageprotokoll live, und jede Zeile trägt die Quelladresse. Ist die Quelle die Tunneladresse des Clients, ist die Pool-Route intakt. Ist es die LAN-Adresse des Gateways, ist Quellübersetzung im Spiel und die eigene Adresse des Clients wird nie erscheinen.

Wenn im Protokoll überhaupt nichts auftaucht, hat die Abfrage Pi-hole nie erreicht, und die Weiterleitung am Gateway ist der nächste Prüfpunkt. Wenn die Abfrage auftaucht und keine Antwort zurückkommt, ist der Antwortpfad das Problem, also der vorige Abschnitt. Den Fehler so aufzuteilen verhindert, dass ein Routing-Fehler für eine Firewall-Regel gehalten wird.

Die Weiterleitungsregel des Gateways prüfen

Das Gateway muss die DNS-Pakete des Clients in Richtung Pi-hole weiterleiten, und die Regel, die das tut, sollte man lesen statt annehmen. Die folgenden Befehle listen die Regeln, die Port 53 berühren, mit Zählern, auf einem nftables-Host und auf einem iptables-Host. Eine Regel, die existiert, aber null Treffer zeigt, ist das Signal dafür, dass Verkehr verworfen wird, bevor er übersetzt wird.

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

Lies die Zähler, nicht nur die Regeln. Eine Regel, die nie trifft, bedeutet, dass das Paket über eine andere Schnittstelle hinausgeht oder der Client es gar nicht erst gesendet hat. Eine Regel, die bei jeder Abfrage trifft, bedeutet, dass die Weiterleitung funktioniert und das Problem weiter hinten auf dem Pfad liegt.

Welches Werkzeug der Host auch nutzt, halte die Prüfung eng: der Pool als Quelle, Port 53 als Ziel und Pi-hole als einziges erlaubtes Ziel. Eine breite Weiterleitungsregel, die auch Port 80 erlaubt, ist ein anderes Problem, das nur darauf wartet zu passieren.