Ich habe eine Fritzbox und einen dedizierten Pi-Hole (inkl. unbound) am laufen.
Jetzt habe ich kürzlich auf einem anderen Pi ne defekte SD Card bekommen und hab überlegt nun zwei Pi-Holes bereitzustellen.
Gibt es ein Best Practise für sowas mit der Fritzbox? Mir würde es ausreichen, hätte ich beide Instanzen laufen und die Clients suchen sich die Instanz aus, aber die Fritzbox kann ja nur einen DNS per DHCP weitergeben - und ich möchte gern die DHCP in der Fritzbox lassen, damit ich deren Funktionen nutzen kann.
Ich kenne diesen "Hochverfügbarkeits"-Thread auf reddit, aber das empfinde ich aktuell als eine viel zu schwere Lösung. Gibts eine eher "handson"-Variante davon?
Du kannst deine Fritz!Box so konfigurieren, das sie sich selber als DNS an die Clients advertised.
Bei der Fritz!Box stellst du wiederum die beiden pi-holes als upstream ein. Hat aber den Nachteil das nur noch deine Fritz!Box als Client im pi-hole auftaucht.
Eine andere Variante die mir einfällt ist, dass du einen pi als DNS-Server für IPv4 und den anderen als DNS-Server für IPv6 advertised.
das ist doof, weil ich Client-Profile im Pi-hole nutze...
glaube, das ist nicht ausreichend. Es sollte ja ein "hot-Standby" oder ähnliches sein. Falls einer ausfällt schauen dann die IPv4-only Clients in die Röhre oder die IPv6...
Naja, die Sorge um einen DNS-Ausfall ist nachvollziehbar, aber mit derselben Logik könnte man sich auch eine zweite DSL-Leitung von einem anderen Provider mieten, falls der aktuelle mal ausfällt, oder einen zweiten Router hinstellen, oder einen zweiten DHCP-Server, oder...
Es gibt sicherlich immer Szenarien, in denen diese zusätzlichen Aufwände gerechtfertigt sind.
Bei der Duplizierung von Pi-hole als DNS-Server im Heimnetz ertappe ich mich allerdings öfter dabei, das zu hinterfragen.
In Deiner jetzigen Konstellation würdest Du sofort und wahrscheinlich unsanft merken, wenn Pi-holes DNS-Server nicht mehr funktioniert.
Wenn Du einen zweiten Pi-hole laufen lässt, merkst Du das erst, wenn beide Pi-holes ausfallen, und damit vielleicht später - aber ebenso unsanft.
Sofern Du nicht zusätzlich zu der Redundanz auch noch einen Eskalationsmechanismus für Ausfälle etablierst (Monitoring, Reporting, Alerting), ändert sich also an der Auswirkung nichts.
Um die 'Nur-1-DNS-Server'-Beschränkung der Fritzbox zu umgehen, könnte man in Deinem Fall z.B. noch eine dritte Maschine aufsetzen, auf der ein DNS-Verteiler (wie z.B. dnsdist) läuft, der DNS-Anfragen an Deine beiden Pi-holes verteilt.
Damit könntest Du den Ausfall eines Pi-holes kompensieren. Wenn jedoch der DNS-Verteiler selbst ausfällt, gibt's auch kein DNS mehr.
Ob der Zugewinn an Ausfallsicherheit den zusätzlichen Installations- und Wartungsaufwand sowie die damit einhergehenden höhere Betriebskosten wert ist, muss jeder für sich selbst entscheiden.
Habe einen Raspberry zero direkt per Lan an die Fritzbox angeschlossen.
Der 2. pihole läuft auf einem Mini PC mit diversen Containern.
Hauptgrund dafür ist, dass ich auf dem Mini PC machen kann was ich möchte, ohne das mich die Familie hängt.
Hab folgende Anleitung genutzt:
Erster Satz ist vollkommen richtig und da wir viel Homeoffice machen, wäre das seeeehr doof. Daher der Gedanke der Redundanz.
Zweiter Satz nicht ganz richtig, ich habe Zabbix als Monitoring laufen und wenn ein Server, eine Komponente, eine Application oder ein Service in meinem Netzwerk ausfällt, krieg ich das mit (ja, auch Zabbix wiederum wird überwacht! ).
hmm.. richtig, wenn der Verteiler ausfällt ist wieder alles weg. Aber schonmal ne Idee, in der ich denken kann, danke!
Das würde bedeuten, den DHCP ebenfalls auszulagern. Damit verliere ich einige Funktionalitäten in der Fritzbox, was ich eigtl. vermeiden möchte. Aber danke für den Link.
Dann hast Du meinen dritten Satz abgedeckt und bereits einen geeigneten Eskalationsmechanismus etabliert.
Ich weiss nicht, warum das in dem verlinkten Artikel nicht gemacht wurde, aber prinzipiell sollte IP-Adressen-Failover über ucarp oder keepalived mit nur einer IP-Adresse funktionieren. Genau diese IP könntest Du dann in der Fritzbox hinterlegen.
).