HL-PRC-012 — Zabbix Agent — supervision des nœuds Proxmox VE

PROCÉDURE TECHNIQUE

Supervision des nœuds Proxmox VE par Zabbix Agent

Déploiement de l’agent en mode actif sur le cluster Proxmox VE, filtrage pare-feu SRX300 et résolution du conflit de modèle passif.

Sommaire

Supervision des nœuds Proxmox VE par Zabbix Agent — HL-PRC-012

1 Objet

Cette procédure formalise le déploiement, le raccordement et la fiabilisation de la supervision Zabbix sur les trois nœuds du cluster Proxmox VE (pve1, pve2, pve3) situés dans le réseau d’administration (zone adm, 10.10.10.0/24) vers le serveur Zabbix central (zone srv, 10.10.20.16). L’objectif opérationnel est d’assurer une surveillance continue des ressources matérielles et systèmes (processeur, mémoire vive, interfaces réseau, partitions de stockage) en exploitant exclusivement le mode agent actif. Ce choix architectural permet aux hyperviseurs d’initier eux-mêmes les connexions sortantes en TCP/10051 vers le serveur de supervision, sans exposer de port réseau entrant passif sur les serveurs de virtualisation.

La difficulté principale traitée réside dans la résolution d’un incident de scrutation passive survenu lors du rattachement des modèles Zabbix. L’attribution conjointe du modèle actif standardisé (Linux by Zabbix agent active) et d’un modèle passif de services (Systemd by Zabbix agent 2) a forcé le serveur Zabbix à tenter d’interroger le port TCP/10050 des hyperviseurs. En l’absence de règle d’autorisation inter-zones sur le pare-feu Juniper SRX300 (dont la politique par défaut est Default-Policy deny-all entre srv et adm), cette sollicitation a provoqué l’échec critique Get value from agent failed: cannot establish TCP connection to [[10.10.10.11]:10050]: timed out et le déclenchement d’alarmes de disponibilité. La procédure détaille l’ouverture des flux de collecte sur le pare-feu, la validation rapide des sockets réseau et l’assainissement des modèles par dissociation propre sous l’interface Zabbix.

2 Périmètre et prérequis

Périmètre

Couvert : installation et configuration de l’agent Zabbix (version agent 2) sur les hyperviseurs Proxmox VE 9.x ; attribution du modèle officiel « Linux by Zabbix agent active » ; dissociation et nettoyage du modèle passif incompatible « Systemd by Zabbix agent 2 » ; création et validation des règles de filtrage sur le pare-feu Juniper SRX300 autorisant les flux de supervision actifs depuis les zones administratives et de test (zones adm et lab) vers le serveur Zabbix (zone srv, port TCP/10051) ; procédures de test immédiat de connectivité (test réseau TCP, zabbix_sender, redémarrage du service).

Hors périmètre : déploiement initial et dimensionnement de la base de données du serveur Zabbix ; supervision individuelle des machines virtuelles et conteneurs LXC hébergés sur la grappe (relevant de leurs zones respectives) ; intégration des notifications externes par canal webhook ou courriel.

Variante agent passif : non retenue par choix de durcissement. L’ouverture du port TCP/10050 en entrée sur les nœuds PVE depuis la zone serveur a été écartée pour respecter le principe de moindre exposition du plan d’administration.

Prérequis

• Trois nœuds Proxmox VE 9.x (Debian 13) configurés en cluster, joignables en root par SSH (pas de sudo).

• Adresses IP de gestion des hyperviseurs configurées et stables : 10.10.10.10 (pve1), 10.10.10.11 (pve2), 10.10.10.12 (pve3).

• Serveur Zabbix opérationnel en version 6.4 ou 7.0, hébergé sur l’adresse 10.10.20.16 (zone srv), à l’écoute sur le port TCP/10051.

• Pare-feu Juniper SRX300 (fw01.adm.dozylab.lan) assurant le routage et le filtrage dynamique inter-zones.

• Accès à l’interface d’administration Web Zabbix avec les privilèges Administrateur Super Utilisateur.

•    Outils d’investigation réseau disponibles sur les hôtes (netcat, curl ou Test-NetConnection).

Note Version validée. Procédure éprouvée sur Proxmox VE 9.x (Debian 13), Zabbix Server 6.4/7.0 et Juniper Junos 21.4/22.x sur SRX300 le 25/10/2026. Les commandes Junos et Linux correspondent strictement aux sorties réelles obtenues en exploitation.

3 Rôles et responsabilités

La répartition des interventions s’articule autour des responsabilités opérationnelles suivantes :

Note Homelab individuel. Dans le cadre du laboratoire DozyLab, les trois rôles sont assumés par la même personne physique. La distinction fonctionnelle est rigoureusement conservée pour garantir la traçabilité des actions d’infrastructure.

4 Procédure de configuration et de remédiation

Paramètres de la procédure

Attention Substitution des paramètres. Les blocs d’instructions ci-après exploitent directement les valeurs réelles validées sur le laboratoire. Ne jamais coller de variables non résolues. Respecter scrupuleusement la casse des objets de sécurité Junos.

Étapes

1. Contrôle des zones et diagnostic des politiques sur le pare-feu SRX300

Avant toute modification des règles de sécurité, il convient d’inspecter les zones définies sur le pare-feu et de tester la politique appliquée aux flux sortants depuis les zones applicatives. La vérification se fait en mode opérationnel Junos sur fw01.adm.dozylab.lan.

show security zones terse
show security match-policies from-zone srv to-zone adm source-ip 10.10.20.12 destination-ip 10.10.10.12 source-port 50000 destination-port 8007 protocol tcp
show configuration security policies from-zone srv to-zone adm | display set

La commande show security zones terse confirme la présence des zones adm, srv, lab, dmz et untrust. La commande match-policies révèle le blocage immédiat du flux par la politique de fermeture :

# Sortie réelle observée sur fw01 :
Policy: Default-Policy, action-type: deny-all, State: enabled, Index: 2
Sequence number: 2

2. Autorisation des flux de supervision et de proxy sur le pare-feu SRX300

Pour permettre la remontée des métriques des agents actifs vers le serveur Zabbix et débloquer les accès requis vers le serveur de sauvegarde PBS, il est nécessaire de créer les objets d’adresses et d’applications correspondants, puis d’insérer les politiques d’autorisation avec validation temporaire sécurisée (commit confirmed).

configure
# 1. Déclaration de l’objet serveur Zabbix et du port d’écoute actif (Trapper)
set security address-book global address srv-zabbix 10.10.20.16/32
set applications application app-zabbix-trapper protocol tcp destination-port 10051
# 2. Autorisation du flux des agents du lab (VLAN 80) vers le serveur Zabbix
set security policies from-zone lab to-zone srv policy p-lab-to-zabbix match source-address any
set security policies from-zone lab to-zone srv policy p-lab-to-zabbix match destination-address srv-zabbix
set security policies from-zone lab to-zone srv policy p-lab-to-zabbix match application app-zabbix-trapper
set security policies from-zone lab to-zone srv policy p-lab-to-zabbix then permit
# 3. Déclaration et autorisation du reverse proxy NPM vers Proxmox Backup Server (pve3)
set security address-book global address adm-pbs-pve3 10.10.10.12/32
set applications application app-pbs-web protocol tcp destination-port 8007
set security policies from-zone srv to-zone adm policy p-srv-npm-pbs match source-address srv-npm
set security policies from-zone srv to-zone adm policy p-srv-npm-pbs match destination-address adm-pbs-pve3
set security policies from-zone srv to-zone adm policy p-srv-npm-pbs match application app-pbs-web
set security policies from-zone srv to-zone adm policy p-srv-npm-pbs then permit
show | compare
commit check
commit confirmed 5

Valider le bon fonctionnement de la règle par un test de correspondance de politique avant d’engager la configuration définitive :

run show security match-policies from-zone lab to-zone srv source-ip 10.10.80.10 destination-ip 10.10.20.16 source-port 50000 destination-port 10051 protocol tcp
# Sortie attendue : Policy: p-lab-to-zabbix, action-type: permit
commit

3. Configuration de Zabbix Agent 2 sur les hyperviseurs Proxmox VE

Sur chacun des nœuds Proxmox VE (pve1, pve2, pve3), l’agent doit être configuré pour pointer vers l’adresse IP du serveur Zabbix en mode actif. Éditer le fichier de configuration principal sans ajouter d’écoute passive inutile.

# Fichier : /etc/zabbix/zabbix_agent2.conf
ServerActive=10.10.20.16
Hostname=pve1
# Laisser Server= vide ou positionné à 127.0.0.1 pour refuser toute scrutation passive non désirée

Appliquer la configuration en redémarrant le service sur le nœud :

systemctl restart zabbix-agent2
systemctl status zabbix-agent2 --no-pager

4. Vérification instantanée de la connectivité réseau et applicative

Afin d’éviter d’attendre le délai de synchronisation périodique de Zabbix, exécuter un contrôle réseau direct depuis l’hyperviseur ou une machine du réseau client pour s’assurer que le port 10051 répond au travers du SRX300.

# Test de socket TCP depuis le nœud vers le serveur Zabbix :
nc -zv 10.10.20.16 10051
# Sortie attendue : Connection to 10.10.20.16 10051 port [tcp/*] succeeded!
# Injection immédiate d’un indicateur de test via zabbix_sender :
zabbix_sender -z 10.10.20.16 -s "pve1" -k "test.ping" -o 1
# Sortie attendue : processed: 0; failed: 1; total: 1 (prouve que le serveur a répondu)

5. Analyse de l’incident de scrutation passive sur l’interface d’administration

Dans la console Zabbix (Collecte de données > Hôtes), l’indicateur ZBX des hyperviseurs bascule à l’orange avec deux problèmes signalés. Le survol de la disponibilité affiche le message d’erreur critique suivant :

Interface 10.10.10.11:10050 Non disponible
Erreur : Get value from agent failed: cannot establish TCP connection to [[10.10.10.11]:10050]: timed out
Vérifications actives : Disponible (Vert)

Le diagnostic de l’hôte montre que deux modèles sont attachés simultanément : Linux by Zabbix agent active et Systemd by Zabbix agent 2. Le second modèle contient des éléments de type passif imposant au serveur Zabbix d’initier des connexions vers le port 10050 de 10.10.10.11. Comme ce port est fermé sur le nœud et bloqué par la politique par défaut du pare-feu SRX, les requêtes tombent en timeout et déclenchent le déclencheur « Zabbix agent is not available ».

6. Résolution dans l’IHM Zabbix par dissociation et nettoyage du modèle passif

Pour rétablir l’état nominal sans compromettre la sécurité par l’ouverture inutile du port 10050 sur les hyperviseurs, il faut dissocier proprement le modèle passif tout en purgeant ses éléments obsolètes.

# Procédure dans l’interface Web Zabbix :
# 1. Naviguer vers : Collecte de données > Hôtes
# 2. Cliquer sur le nom de l’hôte (pve1, puis répéter sur pve2 et pve3)
# 3. Dans la section "Modèles liés", repérer la ligne : Systemd by Zabbix agent 2
# 4. Cliquer impérativement sur le lien : "Supprimer lien et nettoyer" (Unlink and clear)
# 5. Conserver intact le modèle principal : Linux by Zabbix agent active
# 6. Cliquer sur le bouton bleu "Actualiser" en bas de page

Dès la validation, Zabbix purge les éléments de supervision passifs de systemd. Le serveur cesse toute tentative de connexion vers le port 10050 des PVE. L’indicateur rouge disparaît, l’alerte de disponibilité s’efface, et les nœuds passent au statut vert nominal grâce au modèle actif.

Retour arrière

Pièges connus

5 Intégration réseau

Identité des instances et adressage

Matrice des flux réseau autorisés

Dépendances et points de défaillance

• Résolution DNS : assurée par le serveur Technitium (10.10.20.11) pour les noms d’hôtes et le reverse proxy.

• Routage inter-zones : dépendance absolue envers la disponibilité du pare-feu Juniper SRX300 (fw01).

• Continuité de supervision : en cas d’indisponibilité du serveur Zabbix, l’agent 2 conserve les données en mémoire tampon locale selon la directive BufferSize avant transmission ultérieure.

6 Durcissement et sécurité

Moindre exposition des hyperviseurs : l’adoption exclusive du mode agent actif supprime la nécessité d’ouvrir un port d’écoute entrant (TCP/10050) sur les nœuds de virtualisation Proxmox VE. Les connexions sont unilatéralement initiées de l’administration vers les serveurs.

Filtrage strict inter-zones : maintien de la politique générale deny-all sur le Juniper SRX300. Chaque ouverture de flux (Zabbix Trapper 10051, PBS 8007) est explicitement restreinte à l’adresse IP de l’hôte (/32) et au port applicatif exact.

Exécution sans privilèges superflus : l’agent zabbix-agent2 s’exécute sous le compte système dédié zabbix, limitant les risques d’élévation de privilèges sur l’hyperviseur en cas de vulnérabilité du démon de collecte.

Sécurité des modifications réseau : application impérative de la commande commit confirmed 5 lors de l’édition des politiques Junos, garantissant un retour arrière automatique en cas d’erreur de syntaxe ou de rupture d’administration.

Dettes techniques

7 Vérifications finales

La validation de la procédure repose sur les critères d’acceptation mesurables et vérifiables suivants :

8 Références et historique des révisions

Documentation éditeur

• Zabbix LLC : Documentation officielle Zabbix 6.4 / 7.0 — « Passive and active agent checks », établissant le mécanisme de scrutation sortante en TCP/10051.

• Juniper Networks : Junos OS Security Configuration Guide — « Security Policies and Zone Configuration on SRX Series Devices », établissant les politiques par défaut et le filtrage match-policies.

• Proxmox Server Solutions : Proxmox VE Administration Guide — « Host System Monitoring and Package Management », validant l’intégration de démons de supervision tiers.

Documents associés

• HL-PRC-001 : Mise en service du pare-feu Juniper SRX300 (configuration initiale des zones et des politiques de base).

• HL-PRC-003 : Mise en service de la grappe Proxmox à trois nœuds (plan d’adressage et gestion de pve1, pve2, pve3).

• HL-PRC-009 : Proxmox Backup Server sur hôte Proxmox VE (installation et ouverture du flux 8007 sur pve3).

Historique des révisions