pi-hole “high availability” bzw. failover

gegen geschwaetzige geraete in meinem boesen multimedia vlan und nervige werbung im allgemeinen nutze ich pi-hole. das ist zwar kein allheilmittel, aber sorgt schonmal fuer eine solide basis im kampf gegen nerver und datensammler. fuer das finetuning kann man in pi-hole seine eigenen black- und whitelists pflegen. obendrein bietet die schicke weboberflaeche einiges an moeglichkeiten zur auswertung und administration.

im eigenen heimnetz bin ich gerne um ausfallsicherheit bemueht. an einigen stellen habe ich dafuer sorge getragen, an anderen muss ich noch etwas schrauben. unter anderem an der dns aufloesung ueber den pi-hole. wenn der mal aus irgendwelchen gruenden nicht will, hat man gleich kein funktionierendes netz mehr (also netz schon, aber ohne namensaufloesung wirds doof.)

abhilfe schafft man natuerlich mit einem zweiten pi-hole. dazu muesste man seinen geraeten zwei dns server bekannt machen. entweder per konfiguration im dhcp server oder bei geraeten mit fest eingetellter IP einen zweiten dns server eintragen. nun gibt es dhcp server implementierungen in irgendwelchen plaste routern, die nur das setzen eines dns servers erlauben. genauso habe ich geraete im hardware zoo, denen man nur einen dns server in der statischen netzwerk konfiguration eintragen kann.
selbst wenn diese beiden probleme nicht hat und zwei pi-hole’s gleichzeitig betreibt, bleiben unzulaenglichkeiten bei der administration. zum einen muss man die konfiguration auf beiden gleich halten, was man mit einem cronjob und rsync oder scp hin bekommt. zum anderen verteilen sich natuerlich auch die dns anfragen der clients auf zwei pi-holes, was dann die schicken statistik bildchen und auswertungen unbrauchbar macht.

auf der suche nach einer loesung bin ich auf einen artikel auf adminforge.de gestossen. da ist beschrieben, wie man unter linux mit “keepalived” eine art hochverfuegbarkeit mit einer virtuellen failover-ip macht. diese failover-ip ist die, die man dann in der dhcp config und in den statisch konfigurierten geraeten als dns server eintraegt. eine der beiden pi-hole instanzen laeuft immer als “master” und beantwortet alle anfragen. sobald dieser nicht verfuegbar ist, schnappt sich der “slave” diese virtuelle failover-ip und beantwortet die dns anfragen.

damit hat man zwar immernoch das problem mit dem synchronisieren der config dateien und auch den verfaelschten statistiken und auswertungen, was aber wenigstens nur im ernstfall eintritt, solange der master nicht erreichbar ist. sobald er wieder erreichbar ist, wird die ip auf diesen zurueck geschwenkt.

ich war mal so frei und hab die konfiguration auf o.g. webseite fast genauso uebernommen:

1 . um zu erlauben, dass ip-adressen auch auf nicht lokale schnittstellen zugewiesen werden duerfen, ist eine kleine anpassung auf maste und slave node notwendig:

echo "net.ipv4.ip_nonlocal_bind = 1" >> /etc/sysctl.conf
sysctl -p

2. auf beiden nodes das paket “keepalived” installieren und sicherstellen, dass der auch nach einen boot startet:

apt-get install keepalived
systemctl enable keepalived.service

3. keepalived konfiguration master (datei /etc/keepalived/keepalived.conf)

global_defs {
        notification_email {
                alerts@domain.de                                # Benachrichtigungs Zieladresse(n)
        }
        notification_email_from keepalived@pihole1.domain.de    # Benachrichtigungs Quelladresse
        smtp_server localhost                                   # SMTP Serveradresse
        smtp_connect_timeout 30                                 # Timeout zum SMTP Server
        router_id pihole1                                       # Eindeutige ID wie z.B. HOSTNAME
        script_user root                                        # Benutzer der Notify Scripte
        enable_script_security                                  # Script Sicherheit einschalten
}
 
vrrp_instance PIHOLE {
        state MASTER
        interface wlan0                                         # Genutztes Interface
        virtual_router_id 51                                    # ID der Route
        priority 150                                            # Master Prio 150, Backup Prio 50
        advert_int 5                                            # Intervall der VRRP Pakete
        smtp_alert                                              # E-Mail Benachrichtigung aktiviren
 
        unicast_src_ip 192.168.1.x                              # Unicast Quelladresse
        unicast_peer {
                192.168.1.x                                     # Unicast Zieladresse(n)
        }
 
        authentication {
                auth_type PASS                                  # Authentifizierungs Typ
                auth_pass xxxxxxxxxxxx                          # Authentifizierungs Passwort
        }
 
        virtual_ipaddress {
                  192.168.1.10/24                               # Virtuelle Failover IP-Adresse
        }
 
#       notify_master ""                                        # Notify Script für den Master Status (einkommentieren, wenn genutzt wird)
#       notify_backup ""                                        # Notify Script für den Backup Status (einkommentieren, wenn genutzt wird)
#       notify_fault ""                                         # Notify Script für den Fehler Status (einkommentieren, wenn genutzt wird)
}

4. keepalived konfiguration slave (datei /etc/keepalived/keepalived.conf)

global_defs {
        notification_email {
                alerts@domain.de                                # Benachrichtigungs Zieladresse(n)
        }
        notification_email_from keepalived@pihole2.domain.de    # Benachrichtigungs Quelladresse
        smtp_server localhost                                   # SMTP Serveradresse
        smtp_connect_timeout 30                                 # Timeout zum SMTP Server
        router_id pihole2                                       # Eindeutige ID wie z.B. HOSTNAME
        script_user root                                        # Benutzer der Notify Scripte
        enable_script_security                                  # Script Sicherheit einschalten
}
 
vrrp_instance PIHOLE {
        state BACKUP
        interface wlan0                                         # Genutztes Interface
        virtual_router_id 51                                    # ID der Route
        priority 50                                             # Master Prio 150, Backup Prio 50
        advert_int 5                                            # Intervall der VRRP Pakete
        smtp_alert                                              # E-Mail Benachrichtigung aktiviren
 
        unicast_src_ip 192.168.1.x                              # Unicast Quelladresse
        unicast_peer {
                192.168.1.x                                     # Unicast Zieladresse(n)
        }
 
        authentication {
                auth_type PASS                                  # Authentifizierungs Typ
                auth_pass xxxxxxxxxxxx                          # Authentifizierungs Passwort
        }
 
        virtual_ipaddress {
                  192.168.1.10/24                               # Virtuelle Failover IP-Adresse
        }
 
#       notify_master ""                                        # Notify Script für den Master Status (einkommentieren, wenn genutzt wird)
#       notify_backup ""                                        # Notify Script für den Backup Status (einkommentieren, wenn genutzt wird)
#       notify_fault ""                                         # Notify Script für den Fehler Status (einkommentieren, wenn genutzt wird)
}

5. testen der installation

dazu erstmal auf beiden nodes den dienst neu starten:

systemctl restart keepalived.service
ip a ls
...
    inet 192.168.1.10/24 scope global secondary wlan0
       valid_lft forever preferred_lft forever
...

dann auf dem master den keepalived stoppen:

systemctl stop keepalived.service

die ip-adresse sollten dann sofort auf dem slave verfuegbar sein. in meinem netz habe ich beim pingen der failover-ip ca 4 bis 5 verlorene pakete. das sollte verschmerzbar sein.

08. January 2019 by sd
Categories: Uncategorized | Leave a comment

Leave a Reply

Required fields are marked *