Pi-hole und Homebridge - DNS-Auflösung (localhost) bricht nach kurzer Zeit zusammen und läuft später wieder

Hallo zusammen,

ich stelle gerade das gleiche Verhalten bei meinem Pi4B fest.
Als Router verwende ich auch eine FritzBox und ich habe vor 1,5 Wochen erst noch einen 3B mit Homebridge und Pihole installiert, habe also die gleichen Anleitungen für den 4B verwendet.
Der 3B lief mit DNS Auflösung des Pi dauerhaft, der 4B bricht nach kurzer Zeit zusammen.

Ich habe die "/etc/hostname" editiert und dort "homebridge" als Hostnamen eingetragen. Dieser wird mir auch in der WebUI angezeigt.
Starte ich den Pi neu, kann ich, nachdem er hochgefahren ist, die WebUI über homebridge.fritz.box/admin aufrufen. Die Homebride selbst rufe ich über homebridge.fritz.box:8080 auf, auch das funktioniert für eine recht kurze Zeit.
Dann plötzlich versuche ich die Seite(n) erneut aufzurufen, aber dann klappt es plötzlich nicht mehr.
Während das zuvor genannte nicht klappt, funktioniert der Aufruf http://pi.hole/admin einwandfrei und durchgändig.
Warte ich wieder einige Zeit, dann kann ich homebridge.fritz.box & homebridge.fritz.box:8080 wieder aufrufen, aber kurz darauf bricht es wieder zusammen.
Und meine als Gateway fungierende FritzBox ist auch nicht mehr als Fritz.box zu erreichen. Sehr dubios, wie ich finde.

Ich beobachte das die ganze Zeit mit "tail -f /var/log/syslog" aber es wirft mir keine Fehlermeldungen aus, die auf etwas hindeuten könnten.

Homebridge Installationsanleitung

Pi-Hole Installationsanleitung
Folgende Versionen sind installiert:

Wäre über jeden Hinweis dankbar!

Vielen Dank!
Heisenberg

Stell uns doch bitte mal ein Debug Log zur Verfügung:

pihole -d

oder über die Web-Oberfläche:
Tools | Generate Debug Log

Anschliessend reicht es, das am Ende angezeigte Token hier zu posten.

(Ohne den Link geöffnet zu haben: Was hat denn das von Dir als
Pi-Hole Installationsanleitung verlinkte https://github.com/ebaauw/homebridge-hue#readme mit Pi-hole zu tun?)

Das Log ist erstellt und hochgeladen.
Token: 88o62ri2k4

Du hast natürlich vollkommen recht, das war der falsche Link, den ich eingefügt habe :smiley:
Hier ist der richtige Link zur Anleitung

Vielen Dank!
Heisenberg

Dein *Debug Log* sieht zunächst unauffällig aus, auch wenn Du Deine FB sich selbst als DNS-Server verteilen lässt (klicken für Log-Auszug):
*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers

   * Received 548 bytes from wlan0:192.168.200.1
     Offered IP address: 192.168.200.54
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 192.168.200.1
      dns-server: 192.168.200.1
      --- end of options ---

Eventuell hat diese (durchaus gültige) Konfigurationsvariante aber mit dem Ausfall von homebridge.fritz.box zu tun.

Ausgeführt auf Deiner Pi-hole-Maschine, was geben die folgenden Kommandos zurück:

nslookup 192.168.200.54 192.168.200.54
nslookup 192.168.200.54 fritz.box
nslookup 192.168.200.54 192.168.200.1

Hm komisch, dass genau die gleiche Konfiguration unter nem Pi3B keine Probleme machte.

Zu 1. 54.200.168.192.in-addr.arpa     name = homebridge.
Zu 2. nslookup: couldn't get address for 'fritz.box': not found
Zu 3. 54.200.168.192.in-addr.arpa     name = C9_3B_D2_DF_26_7C.fritz.box.
      54.200.168.192.in-addr.arpa     name = CC_22_3D_E3_CE_30.fritz.box.

Das könnte bereits ein Hinweis sein.
Bitte noch das dritte Kommando ausführen (hab ich erst später ergänzt :wink: ).

Ist bereits erledigt :wink:

Prima.

Was verwendet Dein RPi4 bzw. 3B denn als interen DNS-Server?
Das findet sich in:

cat /etc/resolv.conf

Da wird mir ausschließlich dieser Inhalt angezeigt.
In der Vergangenheit habe ich da nichts editiert.

nameserver 9.9.9.9
nameserver 149.112.112.112

Gilt oder galt das auch für den 3B (wenn der noch verfügbar ist)?

Das kann ich jetzt leider nicht mehr nachschauen, habe den 3B bereits für einen Kollegen vorbereitet.
Ich kann nur so viel sagen, da ich Pihole auf dem 3B noch nicht installiert habe, dass mir dort die FritzBox als DNS-Server angezeigt wird.
Hab dieses gerade in meinem Gastnetzwerk verbunden.

nameserver 192.168.179.1

Offensichtlich kennt nur Pi-hole die Namensauflösung für homebridge.

Die Beobachtung des Ausfalls von homebridge könnte zwei drei Ursachen haben:

1.) Der Homebridge-Server versucht die Namensauflösung über die in /etc/resolv.conf angegebenen DNS-Server, und diese kennen homebridge natürlich nicht.

Hier sollte Abhilfe zu schaffen sein, wenn Du den Server auf die Fritzbox oder Pi-hole änderst.
Im Falle einer statischen IP-Adressdefinition erledigst Du das auf Deinem RPi über

sudo nano /etc/dhcpcd.conf

Dort änderst Du die DNS-Server auf

domain_name_servers=127.0.0.1 192.168.200.1

Anschliessend solltest Du einen Reboot durchführen.

Da Pi-hole 4 noch standardmässig 127.0.0.1 konfiguriert hat, passt das zu Deiner Aussage, dass es früher funktionierte.

Seit Pi-hole 5 wird resolv.conf nicht mehr angepasst, da dies öfters zu Problemen bei Updates geführt hat und für Pi-hole auch nicht erforderlich ist, siehe Release Notes.

Offen ist dabei die Frage, woher die Einträge für nameserver 9.9.9.9 und 149.112.112.112 kommen.
Pi-hole tut diesbezüglich nichts, und die FB verteilt bei Dir über DHCP ihre eigene IP. Sofern Dein RPI ein (fixes) DHCP-Lease der FB bezieht, würde ich daher 192.168.200.1 in resolv.conf erwarten.

2.) Der DNS-Rebind-Schutz Deiner FB unterbindet die DNS-Antworten für homebridge.

Generell würde sie das für alle DNS-Antworten tun, die eine lokale IP-Adresse enthalten (bei Dir also aus dem Bereich 192.168.200.0/24).

In diesem Fall sollte Pi-hole in der FB als Ausnahme vom DNS-Rebind eingetragen werden.

Diesen Fall halte ich allerdings für wenig wahrscheinlich, da http://pi.hole bei Dir keine Probleme bereitet.

EDIT:
3.) Die Fritzbox kennt eine veraltete IP-Adresse für homebridge

Das haben wir bislang noch nicht geprüft:

nslookup homebridge 192.168.200.1

Da die FB in der Verarbeitungskette zuerst befragt wird, könnte es hier zu Fehlern kommen,.wenn die FB sich aus einer früheren Verwendung (z.B. Deinem 3B?) eine andere IP-Adresse für homebridge gemerkt hat.

Ich weiss für diesen Fall leider nicht, wie man die FB dazu bringen kann, das zu vergessen. :frowning:

Eine Möglichkeit zur Vermeidung wäre dann, Pi-hole als lokalen DNS-Server in der FB zu konfigurieren, damit Pi-hole die Anfragen als erster sieht (siehe z.B. Fritz!Box (DE) - Pi-hole documentation).

Ich würde die Fehlerbehebung also zunächst mit 1) versuchen. :wink:

Danke dir schon mal für deine hilfreiche und vor allem schnelle Fehleranalyse :slightly_smiling_face:
Was mir in der dhcpcd.conf auffällt, dass die Adresse für den wlan0 adapter als statisch eingetragen ist.
Das sollte nicht notwendig sein, da meine FritzBox ja den DHCP-Server bereitstellt und ich dort auch anhand der MAC-Adresse dem Pi die IP zuweise.

Kannst du mir vielleicht einen Hinweis geben, wie ich das wieder auf DHCP umstelle? Vielleicht erledigt sich das Problem dann von allein. Ganz unten ist der statische Eintrag. Reicht hier ein einfaches auskommentieren?
Hier mal meine dhcpcd.conf

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface wlan0
        static ip_address=192.168.200.54/24
        static routers=192.168.200.1
        static domain_name_servers=9.9.9.9 149.112.112.112

Die vier Zeilen löschen oder für eine spätere Wiederverwendung auskommentieren (# voranstellen). Im letzteren Fall würde ich trotzdem die Anpassung der DNS-Server wie von mir vorgeschlagen vornehmen.

Nach einem Neustart sollte der RPi dann seine Adresse von der FB beziehen, wo hoffentlich eine fixe Adresse eingestellt ist ("Diesem Gerät stets dieselbe Adresse zuweisen" o.ä.). :wink:

Danke, das werde ich auf jeden Fall mal auskommentieren und den nameserver wie von dir erwähnt abändern.
Du hast eben erwähnt, dass du dich fragst, woher die Einträge kommen.
Die frische Installation des Pi aus meinem Gastnetzwerk ergibt genau die gleichen Einträge, daher muss das scheinbar durch die Installation kommen oder ich habe beim Setup einen Fehler gemacht, was ich natürlich nicht ausschließen will, nur viel falsch machen kann man ja jetzt nicht :smiley:
dhcpcd.conf aus dem Gastnetzwerk

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface wlan0
        static ip_address=192.168.179.10/24
        static routers=192.168.179.1
        static domain_name_servers=9.9.9.9 149.112.112.112

Ich hab oben noch eine dritte Möglichkeit ergänzt.

Danke dir. Ich habe übrigens Variante 1 schon ausprobiert, das hat leider nicht zum Erfolg geführt.
Deine Idee mit der reservierten IP-Adresse in der FritzBox ist schon nicht schlecht. Ich habe früher dem Pi3B die 192.168.200.54 fest zugewiesen, als ich den dann mit dem 4B abgelöst habe, habe ich natürlich die MAC-Adresse in der Reservierung geändert und als ich dann komische Effekte hatte, habe ich die FritzBox auch mal neugestartet, nachdem die Reservierung des 3B aufgelöst wurde, damit ich sie wieder für den 4B verwenden kann. Das hat schon geholfen.
Die IP hat sich also nicht geändert, nur die MAC.

Folgendes ist auf deinen Punkt 3 herausgekommen.

Server:         192.168.200.1
Address:        192.168.200.1#53

Name:   homebridge.fritz.box
Address: 192.168.200.54
Name:   homebridge.fritz.box
Address: 192.168.200.28

Das ist definitiv der Grund für Deine Probleme.

Der Zugriff auf http:/homebridge funktioniert nur, wenn der Client zufällig die richtige der beiden IP-Adressen verwendet.

Hm, die 192.168.200.28 ist die LAN-Schnittstelle, die ich eigentlich gar nicht verwende.
Kann ich die denn irgendwie da raus löschen oder wie bekomme ich den Eintrag weg?

Tut mir leid:

Alle meine diesbezüglichen Versuche mit meiner FB sind gescheitert.
Einzig den Weg über eine im Abschnitt landevices manipulierte Fritzbox-Export-Datei habe ich noch nicht versucht.

Ich bin jetzt aber erst einmal off.