Sur les reseaux segmentes, le probleme est rarement le GLPI Agent lui-meme, mais la route. Les agences sans VPN, les DMZ, les reseaux OT/ICS et les laboratoires n'ont souvent qu'une sortie HTTP et jamais de chemin direct vers le serveur d'inventaire. Quand nous maintenons des parcs GLPI pour des clients, c'est la que le mode proxy du GLPI Agent cesse d'etre une curiosite de la documentation pour devenir une architecture de production: un agent par reseau concentre l'inventaire des voisins et le transmet a GLPI par un unique canal controle.
Ou le mode proxy aide vraiment (et ou il n'aide pas)
Le mode proxy n'existe pas pour "economiser des agents". Il existe pour reduire N regles de pare-feu a une seule. Sans proxy, chaque poste d'une agence devrait atteindre le serveur GLPI, ce qui signifie ouvrir tout le parc vers le centre de donnees, ou dependre d'un VPN qui couvre rarement le reseau des imprimantes, les automates de l'usine ou le segment invites. Avec un proxy, seul le concentrateur parle a GLPI. La ou nous l'adoptons:
- Agences sans VPN direct vers le centre de donnees, avec seulement la navigation web autorisee.
- Reseaux isoles: DMZ, OT/ICS (atelier), laboratoire, segment invites.
- Pare-feu restrictifs ou seul le trafic sortant HTTP/HTTPS passe par un proxy d'entreprise.
- Sites distants a lien instable, ou concentrer et renvoyer en local reduit la retransmission sur le WAN.
La ou ce n'est pas rentable: un reseau plat qui voit deja GLPI, ou un petit parc derriere un VPN stable. La, le proxy ne fait qu'ajouter un point de defaillance. La regle que nous appliquons en conseil est simple: proxy quand la barriere est de routage/pare-feu, pas quand elle est d'echelle.
Architecture: un concentrateur par domaine reseau
[Postes Agence A] --HTTP--> [GLPI Agent Proxy A :62354] --+
[Postes Agence B] --HTTP--> [GLPI Agent Proxy B :62354] --+--HTTPS 443--> [Serveur GLPI]
[Reseau OT/ICS] --HTTP--> [GLPI Agent Proxy C :62354] --+ (glpi.votreentreprise.com)Chaque reseau a un agent avec le serveur HTTP local active (le role proxy). Les agents des postes ne connaissent pas GLPI: ils publient leur inventaire sur le proxy de leur propre reseau. Le proxy le transmet au serveur GLPI par une unique connexion TLS. En pratique, la carte du pare-feu du client cesse d'avoir des dizaines de sources pour n'avoir qu'une ligne par reseau.
Configuration reelle mise en production
Sur GLPI Agent 1.x la configuration reside dans des fichiers .cfg et le service expose les taches HTTP sur le port 62354. Le concentrateur a besoin de deux choses: la tache de serveur local activee et une liste de confiance (httpd-trust) restreinte a la plage du reseau, jamais ouverte.
1. Agent concentrateur (proxy du reseau)
# /etc/glpi-agent/conf.d/proxy.cfg (agent concentrateur)
# Ou les inventaires collectes sont transmis:
server = https://glpi.votreentreprise.com/front/inventory.php
# Active le serveur HTTP embarque et la tache de relais:
tasks = inventory, remoteinventory
# Confiance: SEULE la plage du reseau local peut publier sur le proxy
httpd-trust = 192.168.10.0/24
# Port du listener local (defaut GLPI Agent):
httpd-port = 62354
# Ne pas inventorier le concentrateur en double:
no-task = collect2. Agents des postes (pointent vers le proxy, pas vers GLPI)
# /etc/glpi-agent/conf.d/local.cfg (postes de l'agence)
# Le "server" ici est le proxy du reseau, pas GLPI:
server = http://proxy-agence-a.local:62354
# Frequence de renvoi (secondes). 86400 = 1 fois par jour:
delaytime = 86400
# Evite que tous se declenchent au meme instant (fenetre aleatoire):
lazy = 13. Validation rapide sur le concentrateur
# Le listener a-t-il repondu?
curl -sS http://localhost:62354/ | head -n 5
# Forcer une execution et observer le renvoi vers GLPI:
glpi-agent --debug --force
# Sur le serveur: l'inventaire est-il arrive via le proxy?
tail -f /var/log/glpi-agent/glpi-agent.log | grep -i "success"Ce que NexTool a appris sur le terrain
Un detail qui n'apparait qu'en maintenance quotidienne: quand httpd-trust est trop large (ou pointe vers un proxy d'entreprise qui fait du SNAT), tous les postes atteignent le concentrateur avec la meme IP source, celle du proxy d'entreprise. Si vous avez fait confiance a l'IP du proxy d'entreprise au lieu de la plage reelle des postes, en pratique n'importe quel hote traversant ce proxy peut publier de l'inventaire. Nous corrigeons toujours en restreignant httpd-trust a la plage physique du reseau des postes, jamais a l'IP de la passerelle de sortie. La deuxieme lecon concerne l'horaire: sans lazy = 1, des parcs de centaines de machines allumees par la meme GPO declenchent l'inventaire a la meme minute que la connexion du matin et s'accumulent sur le concentrateur; le lien de l'agence sature a 8h chaque jour. La fenetre aleatoire de lazy resout cela sans toucher a l'infrastructure.
Mode proxy vs agent direct: quand choisir chacun
| Critere | Agent direct | Mode proxy |
|---|---|---|
| Regles de pare-feu | Une par source (ne passe pas a l'echelle) | Une par reseau |
| Reseau sans route vers GLPI | Ne fonctionne pas | Resout |
| Point unique de defaillance | Aucun supplementaire | Le concentrateur (mitiger avec 2 proxies) |
| Trafic sur le WAN | N connexions | 1 connexion consolidee |
| Complexite operationnelle | Faible | Moyenne (1 hote a maintenir par reseau) |
| Ideal pour | Reseau plat / VPN stable | DMZ, OT, agence sans VPN |
Integration avec GLPI et l'ecosysteme NexTool
Collecter n'est que la moitie du travail; la valeur est dans ce que GLPI fait une fois l'inventaire arrive. Dans les parcs que nous maintenons, nous relions l'inventaire par proxy au reste du cycle de vie de l'actif:
- Les regles metier de GLPI classent l'actif par entite/emplacement a partir de la donnee apportee par le proxy: la bonne agence, la bonne categorie, sans saisie manuelle.
- Le module d'audit NexTool enregistre quand un actif entre, change de proprietaire ou disparait de l'inventaire, essentiel sur les reseaux OT ou un equipement ne peut pas simplement "disparaitre".
- Les notifications se declenchent quand un proxy cesse de reporter: un concentrateur muet signifie un reseau entier aveugle, et cela devient une alerte, pas une surprise de fin de mois.
C'est ce qui separe "installer le GLPI Agent" de "maintenir un inventaire fiable": le proxy est la porte d'entree, mais la donnee ne devient gestion d'actifs que lorsque le GLPI a cote est configure pour recevoir, classer et auditer.
Si votre reseau a des agences, une DMZ ou un atelier qui restent aujourd'hui hors de l'inventaire, l'equipe de maintenance GLPI de NexTool concoit la topologie de proxies, durcit httpd-trust et relie l'inventaire aux regles et a l'audit de votre GLPI. Parlez-nous de la maintenance GLPI.
Révisé par l'équipe NexTool Solutions.
