AdGuard Home? Mein Setup mit Sync und Failover

Ich habe lange Zeit zwei Pi-hole-Instanzen mit kaskadiertem UnboundUnbound ist ein DNS-Resolver, der Anfragen selbst auflöst statt sie an externe Server weiterzugeben.

Mehr dazu im IT-Glossar → betrieben: pihole1 auf einem Raspberry Pi 4B und pihole2 als LXCLXC steht für Linux Containers. Dabei laufen mehrere getrennte Systeme leichtgewichtig auf einem gemeinsamen Linux-Kernel.

Mehr dazu im IT-Glossar → auf meinem Proxmox-Host. Ziel war es, auch bei Wartungsarbeiten am Raspberry eine funktionierende DNS-Infrastruktur zu behalten. Denn wer schon einmal ohne funktionierende DNSDNS übersetzt Domainnamen wie kerezovic.de in IP-Adressen, damit Systeme im Netzwerk kommunizieren können.

Mehr dazu im IT-Glossar →-Auflösung dagestanden hat, weiß: DNS ist kritische Core-Infrastruktur.

Eine Synchronisation der Konfiguration war zwingend notwendig, da ich häufig mit lokalen DNS-Einträgen arbeite und Änderungen nicht doppelt pflegen wollte. Gelöst habe ich das zunächst pragmatisch über ein SSH-Skript.

Das lief monatelang stabil – bis pihole1 plötzlich eine dauerhaft hohe CPU-Last entwickelte, verursacht durch pihole-FTL. Die Ursache ließ sich nicht eindeutig nachvollziehen. Der Raspberry lief konstant auf 100 Prozent Auslastung über alle Kerne, was sich auch deutlich durch den Lüfter bemerkbar machte.

Warum AdGuard Home?

Ich wollte eine Lösung, die:

• ressourcenschonend und performant arbeitet,
• sich zuverlässig synchronisieren lässt,
• und echtes Failover ohne Bastellösungen ermöglicht.

Neues Setup

Das neue Setup besteht aus zwei unabhängigen Instanzen:

• adguard (Raspberry Pi 4B, 192.168.2.77)
• adguard2 (Proxmox LXC, 192.168.2.78)

Beide Instanzen laufen autark, werden jedoch synchron gehalten und nutzen jeweils UnboundUnbound ist ein DNS-Resolver, der Anfragen selbst auflöst statt sie an externe Server weiterzugeben.

Mehr dazu im IT-Glossar → als Upstream-Resolver.

Synchronisation

Die Synchronisation erfolgt über adguardhome-sync. Damit bleiben Filterlisten, Einstellungen und DNS-Regeln automatisch identisch.

/etc/adguardhome-sync/config.yaml:

origin:
  url: https://192.168.2.77
  username: adguardadmin
  password: GEHEIM
  insecureSkipVerify: true

replica:
  url: https://192.168.2.78
  username: adguardadmin
  password: GEHEIM
  insecureSkipVerify: true

features:
  generalSettings: true
  filters: true
  services: true
  protectionStatus: true
  dns:
    serverConfig: true
    rewrites: true
    accessLists: true
  dhcp:
    serverConfig: false
    staticLeases: false

Manuelle Konfigurationspflege entfällt damit vollständig.

Failover mit virtueller IP

Für das Failover kommt keepalived mit einer virtuelle IPEine virtuelle IP kann zwischen mehreren Systemen wechseln und wird für Failover und Hochverfügbarkeit genutzt.

Mehr dazu im IT-Glossar → zum Einsatz. Diese wird im Netzwerk als zentraler DNS-Server genutzt.

Das bringt zwei entscheidende Vorteile:

• automatisches FailoverFailover bedeutet, dass ein zweites System automatisch übernimmt, wenn das erste ausfällt – für höhere Verfügbarkeit.
  
  Mehr dazu im IT-Glossar → bei Ausfall einer Instanz
• Kompatibilität mit der Fritzbox, die per DHCPDHCP weist Geräten im Netzwerk automatisch IP-Adressen und weitere Netzwerkeinstellungen zu.
  
  Mehr dazu im IT-Glossar → nur einen DNS-Server verteilen kann

Alle Clients verwenden somit ausschließlich die virtuelle Adresse: 192.168.2.79.

Healthcheck für keepalived

Damit das Failover nicht nur auf Basis der Netzwerkschnittstelle erfolgt, kommt ein eigener Healthcheck zum Einsatz.

Dieser prüft aktiv, ob der lokale DNS-Dienst noch korrekt antwortet:

#!/bin/bash
dig @127.0.0.1 -p 53 kerezovic.de \
  +short +time=2 +tries=1 >/dev/null 2>&1 || exit 1
exit 0

Schlägt die Abfrage fehl, liefert das Skript einen Fehlercode zurück. Die Instanz wird als fehlerhaft markiert und gibt die virtuelle IP frei.

Damit werden nicht nur Systemausfälle erkannt, sondern auch funktionale Probleme im DNS-Dienst selbst.

keepalived-Konfiguration

vrrp_script chk_adguard {
    script "/usr/local/bin/check_adguard.sh"
    interval 2
    weight -60
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150

    advert_int 1

    authentication {
        auth_type PASS
        auth_pass GEHEIM
    }

    virtual_ipaddress {
       192.168.2.79
    }

    track_script {
        chk_adguard
    }
}

Der Healthcheck wird alle zwei Sekunden ausgeführt. Im Fehlerfall sinkt die Priorität, sodass die zweite Instanz automatisch übernimmt.

Das führt in der Praxis zu einem Failover innerhalb weniger Sekunden.

Vorteile des neuen Setups

• keine doppelte Pflege der Konfiguration
• saubere und transparente Redundanz
• identische Konfiguration auf beiden Systemen
• funktionaler Healthcheck statt reinem Netzwerk-Monitoring

Ein stabiles Netzwerk endet nicht beim WLAN-Empfang – auch DNS spielt eine entscheidende Rolle.

Stabile und sichere Infrastruktur ist kein Zufall. Mit Catarix IT helfe ich dabei, solche Setups sauber umzusetzen.

Fazit

Der Wechsel auf AdGuard Home hat sich für mich klar gelohnt. Das Setup ist stabiler, einfacher zu warten und deutlich robuster gegenüber Fehlern geworden.