Zabbix Proxy einrichten: Zweiter Standort, Docker auf Unraid, PSK und warum SNMP durch den Tunnel nicht ging

Mein Zabbix-Server steht in einem Rechenzentrum. Die Access Points stehen an zwei anderen Standorten, hinter NAT, hinter einem Bonding-Tunnel, hinter allem Möglichen. Der Server kann sie nicht erreichen. Er soll sie trotzdem überwachen.

Dafür gibt es den Zabbix Proxy: ein kleiner Dienst am entfernten Standort, der die Geräte dort abfragt, die Ergebnisse sammelt und gebündelt zum Server schickt. Der Server braucht keinen Zugang zum Standort, der Proxy baut die Verbindung auf. Fällt die Leitung aus, puffert der Proxy und liefert nach.

Aktiv oder passiv, zum Zweiten

Wie beim Agent gibt es den Proxy in zwei Betriebsarten. Aktiv heißt: Der Proxy verbindet sich zum Server auf Port 10051, holt seine Konfiguration und schickt Daten. Hinter NAT ist das der einzige Weg. Passiv heißt: Der Server verbindet sich zum Proxy. Das braucht einen erreichbaren Proxy und ist nur im eigenen Netz sinnvoll.

Ich nutze aktive Proxys. Beide stehen hinter NAT.

Proxy 1: Docker-Container auf Unraid

Der erste Standort hat einen Unraid-Server. Dort läuft der Proxy als Container, Image zabbix/zabbix-proxy-sqlite3. SQLite reicht für einen Proxy völlig, er hält nur die Konfiguration und den Puffer.

Vorbereitung auf dem Unraid, in der Shell:

mkdir -p /mnt/user/appdata/zabbix-proxy/db /mnt/user/appdata/zabbix-proxy/enc
openssl rand -hex 32 > /mnt/user/appdata/zabbix-proxy/enc/proxy.psk
chown -R 1997:1995 /mnt/user/appdata/zabbix-proxy

Die UID 1997 ist der zabbix-Benutzer im offiziellen Image. Ohne das chown kann der Proxy seine Datenbank nicht anlegen.

Der Container, entweder in der Unraid-Oberfläche oder direkt:

docker run -d --name zabbix-proxy --network host --restart unless-stopped \
  -e ZBX_HOSTNAME=proxy-home \
  -e ZBX_SERVER_HOST=203.0.113.10 \
  -e ZBX_PROXYMODE=0 \
  -e ZBX_TLSCONNECT=psk \
  -e ZBX_TLSPSKIDENTITY=proxy-home \
  -e ZBX_TLSPSKFILE=/var/lib/zabbix/enc/proxy.psk \
  -e ZBX_CONFIGFREQUENCY=60 \
  -e ZBX_PROXYOFFLINEBUFFER=24 \
  -v /mnt/user/appdata/zabbix-proxy/db:/var/lib/zabbix/db \
  -v /mnt/user/appdata/zabbix-proxy/enc:/var/lib/zabbix/enc:ro \
  zabbix/zabbix-proxy-sqlite3:ubuntu-7.4-latest

Zeile für Zeile:

• --network host: Der Proxy soll das Heimnetz direkt sehen, für SNMP und Discovery. Mit Bridge-Netzwerk sieht er nur Docker-Netze.
• ZBX_PROXYMODE=0: aktiv.
• ZBX_TLS*: PSK-Verschlüsselung. Der Proxy spricht über das Internet mit dem Server, unverschlüsselt kommt nicht in Frage.
• ZBX_CONFIGFREQUENCY=60: alle 60 Sekunden holt der Proxy neue Konfiguration. Standard sind 10 Sekunden, das ist unnötig.
• ZBX_PROXYOFFLINEBUFFER=24: 24 Stunden Puffer, wenn der Server nicht erreichbar ist.

Die Image-Version 7.4 muss zur Server-Version passen. Ein 7.0-Proxy an einem 7.4-Server wird abgelehnt.

Wer in Unraid ein Template für die Oberfläche will, legt eine XML unter /boot/config/plugins/dockerMan/templates-user/ an. Dann lässt sich der Container dort bearbeiten wie jeder andere.

Proxy in Zabbix registrieren

Administration → Proxies → Create proxy:

• Proxy name: exakt wie ZBX_HOSTNAME, also proxy-home
• Proxy mode: Active
• Encryption: Connections from proxy → PSK, Identity proxy-home, PSK der Inhalt der Datei

Nach einer Minute steht in der Liste „Last seen“ mit wenigen Sekunden. Steht dort „Never“, ist meistens der Name falsch oder der PSK stimmt nicht. Das Container-Log zeigt es: docker logs zabbix-proxy.

Hosts und Discovery dem Proxy zuweisen

Jeder Host hat ein Feld „Monitored by“: Server oder Proxy. Hosts am entfernten Standort bekommen den Proxy. Dasselbe gilt für Discovery-Regeln: Die Regel für das Heimnetz läuft über proxy-home, und Hosts, die sie anlegt, werden automatisch von diesem Proxy überwacht.

Agents am entfernten Standort zeigen mit ServerActive= auf den Proxy statt auf den Server. Der Proxy nimmt aktive Checks an und leitet sie weiter. Mein Unraid-Agent zeigt allerdings direkt auf den Server, weil er vor dem Proxy da war und läuft. Beides geht.

Proxy 2: Paket auf Debian

Der zweite Standort hat keinen Docker-Host, aber einen VPS, der den Tunnel zum Standort terminiert. Dort als Paket:

apt install zabbix-proxy-sqlite3 zabbix-sql-scripts

In /etc/zabbix/zabbix_proxy.conf:

Server=203.0.113.10
Hostname=proxy-bonding
DBName=/var/lib/zabbix/zabbix_proxy.db
ProxyOfflineBuffer=24
ConfigFrequency=60
StartDiscoverers=3

Die SQLite-Datei legt der Proxy beim ersten Start selbst an. mkdir -p /var/lib/zabbix && chown zabbix:zabbix /var/lib/zabbix, dann systemctl enable --now zabbix-proxy. Im Log steht nach dem Start „proxy not found“, bis der Proxy in Zabbix angelegt ist. Danach läuft es.

Dieser Proxy spricht mit dem Server über ein VPN, deshalb ohne PSK. Über das offene Internet immer mit.

Warum SNMP durch den Tunnel nicht ging

Das ist der Teil, den ich eigentlich nicht erzählen wollte, der aber am lehrreichsten ist.

Der zweite Standort hängt über einen Bonding-Tunnel (OpenMPTCProuter) an einem VPS. Mein Zabbix-Server ist über ein VPN mit diesem VPS verbunden, und der VPS gibt das Standort-Netz als Route frei. Der Zabbix-Server konnte den Standort anpingen. Also, dachte ich, braucht es keinen Proxy, der Server macht die SNMP-Discovery selbst.

Ergebnis: Ping ging, SNMP nicht. Manchmal kamen Pakete durch, meistens nicht. Ich habe eine Stunde mit tcpdump auf dem VPS verbracht. Die UDP-Pakete kamen auf dem VPN-Interface an und verschwanden. Keine Firewall-Regel, die sie blockte, kein Conntrack-Eintrag, nichts im Log. Zwei VPN-Schichten mit Policy-Routing und Masquerading übereinander, und irgendwo dazwischen gingen UDP-Pakete verloren, ICMP aber nicht.

Ich habe es nicht gelöst. Ich habe den Proxy auf den VPS gesetzt, der den Tunnel terminiert. Von dort geht SNMP in den Standort über genau einen Hop, und es funktionierte auf Anhieb. Die Discovery fand sechs Geräte beim ersten Lauf.

Die Lehre: Ein Proxy gehört so nah wie möglich an die Geräte, die er abfragt. Nicht, weil es anders unmöglich wäre, sondern weil jede Netzwerkschicht dazwischen ein Ort ist, an dem man Stunden verliert.

Wenn es keinen Proxy-Host gibt

Am zweiten Standort selbst gibt es nur den Bonding-Router, eine OpenWrt-VM mit 190 MB freiem Speicher. Ein Zabbix Proxy läuft dort nicht, es gibt kein Paket und die Bibliotheken fehlen. Ein Agent schon, als statische Binärdatei, das steht im Agent-Artikel. Der Proxy auf dem VPS ist ein Kompromiss: Fällt der Tunnel, sind die Standortgeräte unerreichbar. Ein echter lokaler Proxy wäre ein kleiner LXC-Container auf dem dortigen Proxmox. Das steht auf meiner Liste.

Proxy-Gesundheit überwachen

Der Proxy selbst sollte im Dashboard stehen. Das Item zabbix[proxy,proxy-home,lastaccess] auf dem Host „Zabbix server“ liefert den Zeitpunkt des letzten Kontakts, ein Trigger darauf meldet, wenn der Proxy länger als fünf Minuten schweigt. Ich habe für beide Proxys eine Kachel auf der Inventar-Seite des Dashboards.

Was man außerdem beobachten sollte: die Proxy-Queue. Wächst sie, kommt der Proxy mit dem Senden nicht nach, meist weil die Leitung zu dünn ist oder der Server zu langsam antwortet.

Zusammenfassung

Im nächsten Teil wechseln wir die Ebene: Proxmox mit Zabbix überwachen, über die API, ohne Agent in jeder VM.