Nach dem erfolgreichen Update auf 5.0 (es gab keinerlei Fehlermeldungen oder Warnungen) komme ich mit keinem Rechner mehr ins Internet.Mir blieb nichts anderes übrig, Pihole als DNS resolver aus der FritzBox rauszunehmen.
Pihole selbst scheint laut Web-Interface einwandfrei zu funktionieren und der Server, auf dem Pihole läuft (Ubuntu 18.04), als auch Pihole selbst kommen ins Internet. Updates sind also möglich. Im Dashbord sind alle Status-LEDs grün.
Was kann die Blockade für alle Clients in meinem Netzwerk bewirken? Mir fällt nichts mehr dazu ein.
Mir fiel auf, dass Verion 5.0 nach dem Update bzw. nach einem Reconfigure nicht mehr anbietet, Firewall-Regeln zu setzen. Dies war in Version 4.x immer der Fall. Kann die Frirewall jetzt "verbogen" sein? Aber eine Abfrage der UFW besagt, dass nur Regeln für die von mir selbst geöffneten Ports für ssh, HTTP und HTTPs existieren. Pihole-Regeln sind demnach nicht vorhanden.
Muss man vielleicht erst im Group-Management Gruppe(n) anlegen und diesen die Clients zuweisen? Wenn ja, wie weise ich der einzigen benötigten Gruppe alle Clients zu, ohne für jeden Client einzeln eine Zeile editieren zu müssen?
Ich wäre Euch sehr dankbar, wenn Ihr meinem Pihole wieder zur Arbeit verhelfen könntet.
Die Konfiguration der Firewall während der Installaton wurde in der Tat entfernt. Das entfernt aber gerade nicht die bereits vorhandenen Regeln (was letztlich die Motivation dafür war, das Installationsskript zu ändern).
Lade doch bitte mal ein Debug Log hoch mittels:
pihole -d
oder über die Web-Oberfläche:
Tools | Generate Debug Log
Anschliessend reicht es, das am Ende angezeigte Token hier zu posten.
Dein Debug Log sieht soweit unauffällig aus.
(Du verwendest zwar einen zweiten Webserver neben lighttpd (deswegen auch der andere Port), aber das hast Du offensichtlich im Griff, wie Dein Screenshot zeigt, weshalb ich die HTTP-Fehler im Log erst einmal ignoriere.)
Zu folgenden Einträgen habe ich Anmerkungen:
*** [ DIAGNOSING ]: Setup variables
IPV4_ADDRESS=192.168.178.121/24
PIHOLE_DNS_1=192.168.178.1
Du hast Deine FB als Upstream-DNS-Server für Pi-hole eingetragen.
Wenn Du gleichzeitig Pi-hole als Upstream-DNS-Server Deiner FB (unter Internet|Zugangsdaten|DNS-Server) eingetragen hast, wäre dadurch eine DNS-Endlosschleife konfiguriert.
Wie hast Du Pi-hole derzeit in Deiner FB eingestellt?
Und sicherheitshalber kannst Du auch überprüfen, ob die in der FB als DNS-Server eingetragene IP-Adresse mit der von Pi-hole übereinstimmt.
Im Anschluss kannst Du mit den folgenden Kommandos die DNS-Auflösung auf einem Client kurz prüfen:
nslookup pi.hole
nslookup flurry.com 192.168.178.121
Ich betreibe meinen eigenen Nextcloud-Server. Da man mit IPv4-Adresse nur einen Server nach draußen aufmachen kann, läuft Pihole mit auf der Nextcloud-Kiste. Vom Konstrukt her gibt es einen Gateway-Host und die einzelnen Anwendungen laufen auf einem virtuellen Host. Mit Pihole in Version 4.x lief das ja einwandfrei. Sofort nach dem Update war das Internet blockiert. Außer dem Update wurde nirgendwo nix verändert.
Meine DNS-Server-Konfiguration in meiner FB sieht wie folgt aus:
und
Die .121 habe ich aber eben nur für den Test eingestellt, weil es damit ja nicht funktioniert. Die 121 ist die Adresse für die Nextcloud, auf der der Pihole läuft.
Wenn ich mit dieser Adresse nslookup pi.hole starte, bekomme ich folgendes:
root@lubox:/home/tino# nslookup pi.hole
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find pi.hole: SERVFAIL
Wenn ich den Pihole wieder rausnehme und die FB als DNS-Server einstelle (192.168.178.1), dann gibt's diesen Fehler:
root@lubox:/home/tino# nslookup pi.hole
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find pi.hole: NXDOMAIN
Das waren nicht ganz die Kommandos, die ich vorgeschlagen hatte.
Und möglicherweise auch nicht ausgeführt auf einem Client, sondern auf der Maschine, auf der auch Pi-hole läuft?
Tut mir leid, mir war irgendwie nicht klar, dass die IP-Adresse meines Servers zum Befehl mit flurry.com gehören sollte. Was genau macht der Befehl?
Allerdings lief der Befehl NICHT auf dem Server mit Pihole, sondern auf meinem Lubuntu-Laptop (root@lubox).
Bevor ich heute zur Arbeit los musste, habe ich die Befehle von meinem Desktop-Rechner wiederholt. Allerdings hatte ich nicht mehr die Zeit, den DNS-Server in der FB wieder auf Pihole umzubiegen, deshalb war die FB selbst der DNS resolver. Vielleicht reicht das? Wenn nicht, führe ich die Befehle nach der Arbeit nochmal mit Pihole als DNS-Server aus.
[tino@arch-box ~]$ nslookup flurry.com 192.168.178.121
;; connection timed out; no servers could be reached
[tino@arch-box ~]$ nslookup pi.hole
Server: 192.168.178.1
Address: 192.168.178.1#53
** server can't find pi.hole: NXDOMAIN
.121 is laut Debug Log die IP Deines Pi-hole. Die Angabe dieser IP mit nslookup bewirkt, dass die DNS-Auflösung über diese IP-Adresse erzwungen wird (siehe auch man nslookup). Fehlt die Angabe, so wird der jeweilige systemseitige DNS-Server verwendet.
Für die ausgeführten Kommandos bedeutet das:
Dein Laptop lubox verwendet einen eigenen DNS-Server auf dem System selbst, Server: 127.0.0.53.
Das ist ungewöhnlich, muss aber nicht zwingend ein Problem sein.
Dein Desktop archbox verwendet, wie von Dir beschrieben, derzeit die FB als DNS-Server, Server: 192.168.178.1.
Da diese pi.hole nicht kennt, ist NXDOMAIN die in diesem Fall zu erwartende und korrekte Antwort.
Die Auflösung über Pi-hole wird sowohl von arch-box (no servers could be reached) als auch von lubox (SERVFAIL) mit einem Fehler quittiert.
Aus dem *Debug Log* wissen wir aber, dass die DNS-Auflösung über Pi-holes IPv4-Adresse grundsätzlich funktioniert: (klicken für Details)
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] tools.pacinocash.com is 0.0.0.0 via localhost (127.0.0.1)
[✓] tools.pacinocash.com is 0.0.0.0 via Pi-hole (192.168.178.121)
[✓] doubleclick.com is 216.58.207.46 via a remote, public DNS server (8.8.8.8)
Wenn das von einem Client aus nicht funktioniert, muss also irgendetwas die Kommunikation zwischen Client und Pi-hole unterbinden. Oft ist das einfach der Fall, wenn Pi-hole noch nicht als DNS-Server verwendet wird.
Da wir aber die DNS-Auflösung über Pi-hole auch erzwungen haben, bestätigt dies Deinen Verdacht, dass die Firewall involviert sein kann.
Ich frage diesbezüglich nochmal bei den Entwicklern an, ob die Regeln ggf. beim Aufruf des Update-Skripts (im Gegensatz zum Installationsskript) angepasst werden.
In der Zwischenzeit solltest Du die Firewall-Regeln Deiner Installation mit der Dokumentation abgleichen. Da Du ufw erwähnt hast, habe ich hier mal direkt die Empfehlungen für ufw verlinkt.
Ich habe jetzt nochmal Pihole als DNS-Server in der FB eingetragen und unter diesen Bedingungen auf meinem Desktop-Rechner die beiden Befehle eingegeben. Ändert sich aber auch nichts im Vergleich zur FB als DNS-Server:
[root@arch-box tino]# nslookup pi.hole
;; connection timed out; no servers could be reached
[root@arch-box tino]# nslookup flurry.com 192.168.178.121
;; connection timed out; no servers could be reached
Problem gelöst! Deine Empfehlungen für ufw brachten die Lösung. Es sind also tatsächlich die fehlenden Rules in der Firewall, die Pihole nach dem Update auf die 5.0er Version nicht setzt.
Nun macht mich aber stutzig, dass diese Regeln in der Firewall für die 4.x-Version nicht enthalten sind. Ich administriere noch eine Kiste für einen Kumpel, auf der das Update noch nicht stattgefunden hat. Und wenn ich mir da mit "ufw status numbered" die Regeln auflisten lasse, fehlen genau die, die ich jetzt für die 5.0er Version hinzugefügt habe.
In der 4.x-Version wurde immer gefragt, ob die Firewall-Regeln gesetzt werden sollen, aber demnach wurden sie nie gesetzt... In der 5.0er Version werden sie gebraucht, aber nicht gesetzt....
Vielen Dank für Deine sehr schnelle Hilfe, das ist Support vom Feinsten 