DNS Rekursion arbeitet nicht wie gewünscht auf allen Interfaces

Help Deutschsprachige Hilfe
1

Hi,

Ich hab ein echt lästigen Bug gefunden. Ich betreibe ein pihole im Netz (ja ist nicht dafür gedachtblabla) hinter einer firewall sodass auch nur die User mein DNS nutzen die ihn auch nutzen dürfen.
Auf dem pihole ist auch ein VPN installiert. Auf dem VPN löst er auch korrekt auch. Auf der öffentlichen IP tut er das leider nicht (firewall Regeln passen zu 10000%)

Auf dem pihole wurde natürlich ein pihole -a -i all ausgeführt und die Kiste auch rebootet.

In der Theorie sollte er nun auf Anfragen aus dem VPN Netz die DNS Auflösen und auch auf der Public IP, sofern die Firewall das zulässt, egal ob nun 1 Hop entfernt oder 20 Hops entfernt, korrekt?

Genau hier liegt der Hund begraben, das tut er nämlich nicht.

Auf der Public IP löst er nix auf was mehr als 1 Hop entfernt ist.
Dafür hier erst mal der Beweis. Ohne VPN Verbindung auf dem Client ein nslookup und tracert:
PS C:\Users\XXX> nslookup www.dl-host.info
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: PUBLIC IP

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.
PS C:\Users\XXX> tracert PUBLIC IP

Routenverfolgung zu FQDN [PUBLIC IP]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms 192.168.1.1
2 1 ms <1 ms <1 ms speedport.ip [192.168.2.1]
3 6 ms 6 ms 9 ms 62.155.243.138
4 8 ms 9 ms 8 ms 217.239.44.26
5 9 ms 8 ms 10 ms 87.190.233.116
6 12 ms 15 ms 14 ms cr03.fra1.de.first-colo.net [212.224.102.133]
7 9 ms 8 ms 8 ms FQDN [PUBLIC IP]

Ablaufverfolgung beendet.

Und hier mit VPN Verbindung ein tracert und nslookup

PS C:\Users\XXX> tracert PUBLIC IP

Routenverfolgung zu FQDN [PUBLIC IP]
über maximal 30 Hops:

1 9 ms 8 ms 9 ms dc01.intern.vpn [10.8.0.1]
2 9 ms 10 ms 10 ms FQDN [PUBLIC IP]

Ablaufverfolgung beendet.
PS C:\Users\XXX> nslookup www.dl-host.info
Server: UnKnown
Address: PUBLIC IP

Nicht autorisierende Antwort:
Name: dl-host.info
Addresses: 2a01:4f8:171:2b0e::4
138.201.169.4
Aliases: www.dl-host.info

Soweit so gut.
Pihole sagt:

pihole -a -i all

[i] Listening on all interfaces, permiting all origins. Please use a firewall!
[✓] Restarting DNS service
~ #

Mein Debug Token hwn02nlpjj

Pihole ist up to date

pihole -up

[i] Checking for updates...
[i] Pi-hole Core: up to date
[i] FTL: up to date
[i] Web Interface: up to date

[✓] Everything is up to date!

In der Version davor auf Debian Jessie funktionierte alles einwandfrei so wie ich es wollte. Auf Stretch nun nix mehr so richtig... Was wurde hier denn geändert?

/etc/pihole/setupVars.conf

WEBPASSWORD=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
TEMPERATUREUNIT=C
WEBUIBOXEDLAYOUT=traditional
API_EXCLUDE_DOMAINS=
API_EXCLUDE_CLIENTS=
API_QUERY_LOG_SHOW=all
API_PRIVACY_MODE=false
DASHBOARD_SHOW_QUERY_TYPES_OVER_TIME=true
DASHBOARD_SHOW_FORWARD_DESTS_OVER_TIME=true
ADMIN_EMAIL=MAIL Adresse
PIHOLE_INTERFACE=eth0
IPV4_ADDRESS=PUBLIC IP/24
IPV6_ADDRESS=PUBLIC IPv6
QUERY_LOGGING=true
INSTALL_WEB=true
LIGHTTPD_ENABLED=1
PIHOLE_DNS_1=8.8.8.8
PIHOLE_DNS_2=8.8.4.4
DNS_FQDN_REQUIRED=true
DNS_BOGUS_PRIV=false
DNSSEC=false
CONDITIONAL_FORWARDING=false
DNSMASQ_LISTENING=all

/etc/dnsmasq.d/01-pihole.conf
addn-hosts=/etc/pihole/gravity.list
addn-hosts=/etc/pihole/black.list
addn-hosts=/etc/pihole/local.list

localise-queries

no-resolv

cache-size=10000

log-queries=extra
log-facility=/var/log/pihole.log

local-ttl=2

log-async
server=8.8.8.8
server=8.8.4.4
domain-needed
except-interface=nonexisting

So wo ist nun genau mein Fehler? :slight_smile:

2

Das klingt ein wenig wie was passiert, wenn in irgendeiner Config die Option local-service aktiviert ist, oder?

local-service: Accept DNS queries only from hosts whose address is on a local subnet, ie a subnet for which an interface exists on the server. This option only has effect if there are no --interface --except-interface, --listen-address or --auth-server options. It is intended to be set as a default on installation, to allow unconfigured installations to be useful but also safe from being used for DNS amplification attacks.

Kannst Du dahingehend mal alle Dateien in /etc/dnsmasq.d/ und auch /etc/dnsmasq.conf überprüfen?

widerspricht meiner Theorie zwar etwas, aber ein Check kann dennoch nicht schaden

3

Das habe ich auch gedacht... /etc/dnsmasq.conf hat gar keinen aktiven Eintrag... Alles was dort drin steht ist auskommentiert.

Jap.
Ich habe nur keine Ahnung was pihole mit dnsmasq genau macht. Wäre ja denkbar das hier irgendwelche Parameter übergeben werden die genau das auslösen.

4

Es werden keine Parameter übergeben. Sämtliche Konfiguration von dnsmasq erfolgt ausschließlich über Konfigurationsdateien im Ordner /etc/dnsmasq.d

Es gibt mindestens eine weitere (englische) Diskussion, wo nach einem Update von PiVPN (vorher lief alles einwandfrei auf dieser Installation) plötzlich ein sehr ähnliches/gleiches Verhalten beschrieben wird. Da sind wir leider auch noch nicht viel weiter gekommen. Da ich auf Dienstreise bin, sind meine Möglichkeiten Zeit zu investieren z.Zt. auch wieder einmal eher überschaubar.

5

Jap das sieht nach genau meinem Problem aus.

Wobei ich extra ne neue KVM Maschine aufgesetzt habe um die neue Version von pihole nutzen zu können. Die alte Maschine war eine Jessie Maschine.

Ich probier mal ein wenig weiter. Vielleicht hilft es ja wenn ich explizit die interfaces in der dnsmasq config und in setupVars.conf angebe.

Das wirklich strange daran ist dass er laut config in den setupVars.conf gar nicht auf tun0 lauschen dürfte sondern nur auf eth0, das tut er allerdings auch nicht so wirklich.

6

Ha! was ein Käse!

Die Lösung:
except-interface=nonexisting <- löschen
in /etc/dnsmasq.d eine neue Datei anlegen
touch /etc/dnsmasq.d/02-pihole-own.conf
Und in dieser Datei dann:
interface=eth0
interface=tun0
interface=lo

eintragen.
In /etc/setupVars.conf beide Interfaces ala
PIHOLE_INTERFACE=eth0
PIHOLE_INTERFACE=tun0

eintragen.
Anschließend hab ich die Kiste rebootet da ein reiner pihole restartdns nicht ausgereicht hat.

Ich geb den Hint auch gleich mal in dem anderen Thread, vielleicht hilft es Ihm ja auch.
Das verhalten ist allerdings schon echt strange!

1 Like
7

Die setupVars.conf Datei ist eigentlich überhaupt nicht von Relevanz und wird nur herangezogen, wenn man z.B. pihole -r nutzt um einmal frischen Wind durch das System zu blasen nachdem man irgendwas umkonfiguriert hat und jetzt nichts mehr geht damit die dann automatisierte Installation Deine bisherigen Einstellungen als vordefinierte Parameter nutzen kann um ein möglichst ähnliches Setup wiederherzustellen.

Hmm, immer noch sehr komisch. Benutzt Du jetzt die Pi-hole beta (FTLDNS)? Wenn nicht, welche Version von dnsmasq verwendest Du?

8

dnsmasq -v
Dnsmasq version 2.76

pihole -v
Pi-hole version is v3.3.1 (Latest: v3.3.1)
AdminLTE version is v3.3 (Latest: v3.3)
FTL version is v3.0 (Latest: v3.0)

Keine FTLDNS

Die Interface Angaben hatte ich heute schon mal drin aber ohne interface=lo und ohne das auch in den setupVars.conf einzutragen. Zudem hatte ich sie in der 01-pihole.conf drin (DAS sollte nun wirklich keinen Unterschied machen aber mit neuer Datei ist es update sicher)

Hier auch noch mal nen Lookup als Beweis :slight_smile:
nslookup status.dl-host.info
Server: FQDN
Address: 185.82.XXXXX

Nicht autorisierende Antwort:
Name: status.dl-host.info
Address: 62.75.146.137

9

Okay, die ist schon von 2016. Ich arbeite z.Zt. mit 2.79, betreibe einen Cisco IPsec VPN Server auf meinem Raspberry und lasse den DNS Server hier mit eben jener Zeile except-interface=nonexisting problemlos überall lauschen.

Ich frage mich ob z.Zt. vielleicht eine aktualisierte Version über irgendwelche Repositories im Umlauf ist, die einen möglicherweise fehlgeschlagenen Patch für irgendetwas enthält was sich dann auf except-interface auswirkt und da für Störungen sorgt.

Ich glaube das auch so :wink: Zumal die Auflistung aller Interfaces gleichwertig ist*.

*) sein sollte....

10

Nach anderen Repos habe ich mir schon einen Wolf gesucht aber die einzige alternative wäre selbst kompilieren und das wäre der etwas unsauberere Weg da hier keine automatischen Updates laufen würden und ich den Overhead dann bei mir hätte.

Ich könnte zwar die Packete selbst kompilieren und in nem eigenen Repo bereitstellen um von dort die updates zu erhalten und das auch automatisiert aber so geht es vermutlich schneller :wink:
Zumindest als Quickwin denn in anbetracht von FTLDNS will ich mir die Arbeit eigentlich nicht machen da die für die Katz wäre früher oder später.

Genau das ist es... sein sollte.

Wenn das bei dem anderen Kollegen auch funktioniert und sein Problem auch behebt, dann liegt die Vermutung eines Bugs in dnsmasq natürlich sehr nahe.

11

Er verwendet aber FTLDNS (was wir zentral und transparent auf dem CI Server kompilieren lassen) und hat somit 1:1 die Version, die ich auch habe... Also damit wären dennoch noch nicht alle Rätsel aufgeklärt.

12

Hmm okay das wäre dann strange es sei denn dieser Bug wäre noch in der aktuellen dnsmasq Version vorhanden (Darauf baut ja FTLDNS auf?) und der Fehler ist somit mit im FTLDNS enthalten.

Dann würde mich allerdings auch interessieren wo genau eventuelle Unterschiede in den einzelnen configs oder Systemen sind. Seine configs etc. sehe ich ja nicht und sein System so auch nicht.

An dem Punkt müsste man sehr tief einsteigen um zu analysieren was dieses "Phänomen" auslöst.

13

Danke für die Tipps!

Mein pi-hole läuft nun wieder! :slight_smile:
Voraussichtlich am Montag schaue ich es mir genauer an.

Viele Grüße

14

Danke. Das macht mir schon einiges an Kopfschmerzen - verwendet Ihr beide PiVPN? Wann wurde das installiert/das letzte mal geupdatet? Gibt es zu dem VPN was Ihr nutzt ein Changelog, sodass man da vielleicht mal reinschauen könnte?

15

Mein Setup:
Debian Stretch KVM
Pihole
openVPN Client zu einem weiteren KVM mit OpenVPN auf Basis Debian Stretch

Installation Pihole: Frische Installation auf ner Debian Stretch KVM Maschine
Alles aus den APT Ressourcen mit Standard Repos. apt-get dist-upgrade aktualisierte alles bevor pihole installiert wurde.
Repos:
deb http://deb.debian.org/debian stretch main contrib non-free
deb-src http://deb.debian.org/debian stretch main contrib non-free

deb http://deb.debian.org/debian stretch-updates main contrib non-free
deb-src http://deb.debian.org/debian stretch-updates main contrib non-free

deb Index of /debian-security stretch/updates main contrib non-free
deb-src Index of /debian-security stretch/updates main contrib non-free

Pihole wurde mit
curl -sSL https://install.pi-hole.net | bash
am 5.4.2018 um 19:32:44 installiert. Die Uhrzeit lass ich mal als optional, keine Ahnung ob die von Bedeutung ist Zwecks Git Repo und was dort zu dem Zeitpunkt drin war / Welche Packete von Pihole verwendet wurden bei der Installation.

Die einzige Anpassung die es am Pihole gab sind die oben genannten Anpassungen damit es überhaupt läuft UND lighttpd weg geworfen und stattdessen nginx installiert. Das sollte hier jedoch irrelevant sein.

Zum VPN, ich verwende hier eigene Infrastruktur und es läuft kein VPN Server auf dem pihole KVM. Dieser ist lediglich ein normaler Client.

Wie ich OpenVPN installiert / konfiguriert habe, habe ich im Groben hier
https://www.sugar-camp.com/anleitung-openvpn-server-auf-debian-7-8-installieren-und-anschliessend-mit-android-ios-oder-windows-verbinden/
und hier
https://www.sugar-camp.com/openvpn-und-ipv6-ein-harter-kampf/
dokumentiert.
Das sind jetzt nicht zu 100% meine aktuellen configs sondern nur die Grundinstallation / config des VPN Servers an sich. Dieser läuft, wie bereits gesagt, auf einer anderen KVM Maschine.

Alle Pakete auf dem Pihole KVM und dem OpenVPN KVM (Debian Stretch Grundsystem) sind stets aktuell mit den offiziellen APT Repos (Ausnahmen wie eigenen OpenVPN Plugins mal ausgenommen, die gibts nicht in den offiziellen Repos).
Dann spielt beim VPN noch ein LDAP / Radius mit rein für die Authentifizierung. Das dürfte aber alles keine Rolle spielen da nichts wirklich in die Pihole Funktionalität reinspielt.

Changelogs kannst du also den offiziellen Quellen entnehmen
https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn24

Was hättest gern noch an Informationen?

16

Ich nutze PiVPN, ja. Das ist, wenn ich das richtig erörtert habe, ein nahezu fertiges OpenVPN-Paket, bei dem man selbst nicht mehr viel konfigurieren muss.
Installiert habe ich es (auf meinen RasPi 3B+ mit aktuellem Debian Stretch, via Raspbian Headless Image mit Standard-Quellen) am 05.04.18, gegen 12 Uhr.
Darin habe ich den auto-update-Modus aktiviert, kann daher leider nicht sagen, ob und was geupdated wurde. Allerdings vermute ich nicht, dass hier etwas passiert ist, da es seiten OpenVPN, meines Wissens nach, auch kein Update gab.
(Anleitung: https://marcstan.net/blog/2017/06/25/PiVPN-and-Pi-hole/) - Hier ist der Punkt "final config" sicher interessant:
Es wird dabei darauf hingewiesen eth0 und tun0 in die setupVars.conf aufzunehmen. Weiterhin eine conf-Datei in dnsmasq.d anzulegen und da die Zeile "interface=tun0" aufzunehmen.

Am 06.04.18 (Uhrzeit weiß ich leider nicht mehr, vermutlich aber zwischen 11 und 14 Uhr) habe ich dann mit pihole -up ein Update durchgeführt und FTL wurde aktualisiert.
Anschließend ging die interne DNS-Auflösung nicht mehr.

Ich vermute, dass das Hauptproblem die nicht explizit aufgeführten Interfaces in den conf-Dateien ist.

(Inwiefern "except-interface=nonexisting" jetzt mit hineinspielt, kann ich leider nicht beurteilen, da ich den Befehl nicht interpretieren kann und ihn einfach mal, wie empfohlen, auskommentiert habe)

Übrigens: in den Einstellungen des Webinterface steht nun "Pi-hole Ethernet Interface: tun0". Vor diesen config-Änderungen stand es auf eth0 (wie es wohl auch sein müsste).

Viele Grüße

17

--except-interface=
Do not listen on the specified interface. Note that the order of --listen-address --interface and --except-interface options does not matter and that --except-interface options always override the others.

Wenn du die Zeile nicht auskommentierst dann werden die "interface" Angaben überschrieben.
Diese Angabe sagt eigentlich er soll auf allen interfaces lauschen ohne das man manuell angeben muss welche.

Die Final config besagt man solle nur tun0 einfügen aber dann fehlt die die eth0 Schnittstelle. Pihole selbst setzt diese nämlich nicht (jedenfalls bei mir in noch keiner dnsmasq config aufgetaucht).
Auch die fehlende lo ist kurios dann denn ohne die wird local resolve nicht mehr gehen.

18

Ich habe es (nach unserer Diskussion hier) nun so bei mir lösen können:

  • die Datei 02-ovpn.conf in /etc/dnsmasq.d/ löschen
  • sicherstellen, dass “except-interface=nonexisting” in 01-pihole.conf in /etc/dnsmasq.conf/ nicht auskommentiert ist
  • in /etc/pihole/setupVars die Zeile PIHOLE_INTERFACE=eth0 stehen haben (ohne zusätliches Interface)

Das ist in dem Tutorial, welches ich verlinkt habe, falsch beschrieben bzw. nicht mehr auf dem aktuellen Stand.

Viele Grüße

19

Hmm.. wenn ich das tue geht die Auflösung wieder nur im VPN... eine o2-ovpn.conf habe ich nicht da ich kein PiVPN einsetze.
Sobald ich die interface Angaben rausnehme und die ehemals except-interface Angabe drin habe wars das.

Aus Spaß hab ich nun auf 7 KVM Maschinen Pihole aufgesetzt und alle mit dem gleichen Ergebnis.

20

Klingt für mich danach, dass deine VPN-Lösung ihr Interface tun0 fälschlicherweise bei pi-hole überschreibt.
In /etc/dnsmasq.d/ hast du sonst keine weitere Datei, oder?