En redes segmentadas el problema rara vez es el GLPI Agent en si, sino la ruta. Sucursales sin VPN, DMZ, redes OT/ICS y laboratorios suelen tener solo salida HTTP y nunca un camino directo al servidor de inventario. Cuando damos soporte a parques GLPI para clientes, ahi es donde el modo proxy del GLPI Agent deja de ser una curiosidad de la documentacion y se vuelve arquitectura de produccion: un agente por red concentra el inventario de los vecinos y lo reenvia a GLPI por un unico canal controlado.
Donde el modo proxy realmente ayuda (y donde no)
El modo proxy no existe para "ahorrar agentes". Existe para colapsar N reglas de firewall en una sola. Sin proxy, cada estacion de una sucursal tendria que alcanzar el servidor GLPI, lo que implica abrir todo el parque al centro de datos o depender de una VPN que rara vez cubre la red de impresoras, los controladores de fabrica o el segmento de invitados. Con proxy, solo el concentrador habla con GLPI. Donde lo adoptamos:
- Sucursales sin VPN directa al centro de datos, con solo navegacion web permitida.
- Redes aisladas: DMZ, OT/ICS (planta industrial), laboratorio, segmento de invitados.
- Firewalls restrictivos donde solo el trafico de salida HTTP/HTTPS pasa por un proxy corporativo.
- Sitios remotos con enlace inestable, donde concentrar y reenviar local reduce la retransmision por la WAN.
Donde no vale la pena: una red plana que ya ve GLPI, o un parque pequeno tras una VPN estable. Ahi el proxy solo agrega un punto de fallo. La regla que usamos en consultoria es simple: proxy cuando la barrera es de ruta/firewall, no cuando es de escala.
Arquitectura: un concentrador por dominio de red
[Estaciones Sucursal A] --HTTP--> [GLPI Agent Proxy A :62354] --+
[Estaciones Sucursal B] --HTTP--> [GLPI Agent Proxy B :62354] --+--HTTPS 443--> [Servidor GLPI]
[Red OT/ICS] --HTTP--> [GLPI Agent Proxy C :62354] --+ (glpi.suempresa.com)Cada red tiene un agente con el servidor HTTP local activado (la funcion proxy). Los agentes de las estaciones no conocen GLPI: publican su inventario en el proxy de su propia red. El proxy lo reenvia al servidor GLPI por una unica conexion TLS. En la practica, el mapa de firewall del cliente deja de tener decenas de origenes y pasa a tener una linea por red.
Configuracion real que pusimos en produccion
En GLPI Agent 1.x la configuracion vive en archivos .cfg y el servicio expone las tareas HTTP en el puerto 62354. El concentrador necesita dos cosas: la tarea de servidor local activada y una lista de confianza (httpd-trust) restringida al rango de la red, nunca abierta.
1. Agente concentrador (proxy de la red)
# /etc/glpi-agent/conf.d/proxy.cfg (agente concentrador)
# Adonde se reenvian los inventarios recolectados:
server = https://glpi.suempresa.com/front/inventory.php
# Activa el servidor HTTP embebido y la tarea de reenvio:
tasks = inventory, remoteinventory
# Confianza: SOLO el rango de la red local puede publicar en el proxy
httpd-trust = 192.168.10.0/24
# Puerto del listener local (default de GLPI Agent):
httpd-port = 62354
# No inventariar el propio concentrador por duplicado:
no-task = collect2. Agentes de las estaciones (apuntan al proxy, no a GLPI)
# /etc/glpi-agent/conf.d/local.cfg (estaciones de la sucursal)
# El "server" aqui es el proxy de la red, no GLPI:
server = http://proxy-sucursal-a.local:62354
# Frecuencia de reenvio (segundos). 86400 = 1 vez al dia:
delaytime = 86400
# Evita que todos disparen en el mismo instante (ventana aleatoria):
lazy = 13. Validacion rapida en el concentrador
# Respondio el listener?
curl -sS http://localhost:62354/ | head -n 5
# Forzar una ejecucion y observar el reenvio a GLPI:
glpi-agent --debug --force
# En el servidor: llego el inventario por el proxy?
tail -f /var/log/glpi-agent/glpi-agent.log | grep -i "success"Lo que NexTool aprendio en la practica
Un detalle que solo aparece en el soporte diario: cuando httpd-trust queda demasiado amplio (o apunta a un proxy corporativo que hace SNAT), todas las estaciones llegan al concentrador con la misma IP de origen, la del proxy de la empresa. Si confiaste en la IP del proxy corporativo en lugar del rango real de las estaciones, en la practica cualquier host que atraviese ese proxy puede publicar inventario. Siempre lo corregimos restringiendo httpd-trust al rango fisico de la red de estaciones, nunca a la IP del gateway de salida. La segunda leccion es sobre el horario: sin lazy = 1, parques con cientos de maquinas encendidas por el mismo GPO disparan el inventario en el mismo minuto del login matutino y se encolan en el concentrador; el enlace de la sucursal se ahoga a las 8h cada dia. La ventana aleatoria de lazy lo resuelve sin tocar infraestructura.
Modo proxy vs agente directo: cuando elegir cada uno
| Criterio | Agente directo | Modo proxy |
|---|---|---|
| Reglas de firewall | Una por origen (no escala) | Una por red |
| Red sin ruta a GLPI | No funciona | Lo resuelve |
| Punto unico de fallo | Ninguno extra | El concentrador (mitigar con 2 proxies) |
| Trafico en la WAN | N conexiones | 1 conexion consolidada |
| Complejidad operativa | Baja | Media (1 host a mantener por red) |
| Mejor para | Red plana / VPN estable | DMZ, OT, sucursal sin VPN |
Integracion con GLPI y el ecosistema NexTool
Recolectar es la mitad del trabajo; el valor esta en lo que GLPI hace despues de que llega el inventario. En los parques que mantenemos, conectamos el inventario por proxy con el resto del ciclo de vida del activo:
- Las reglas de negocio de GLPI clasifican el activo por entidad/ubicacion a partir del dato que trajo el proxy: la sucursal correcta, la categoria correcta, sin escritura manual.
- El modulo de auditoria de NexTool registra cuando un activo entra, cambia de dueno o desaparece del inventario, esencial en redes OT donde un equipo no puede simplemente "desaparecer".
- Las notificaciones se disparan cuando un proxy deja de reportar: un concentrador mudo significa una red entera ciega, y eso se vuelve una alerta, no una sorpresa a fin de mes.
Esto es lo que separa "instalar el GLPI Agent" de "mantener un inventario confiable": el proxy es la puerta de entrada, pero el dato solo se vuelve gestion de activos cuando el GLPI de al lado esta configurado para recibir, clasificar y auditar.
Si tu red tiene sucursales, DMZ o planta industrial que hoy quedan fuera del inventario, el equipo de soporte GLPI de NexTool disena la topologia de proxies, endurece el httpd-trust y conecta el inventario a las reglas y auditoria de tu GLPI. Habla con nosotros sobre soporte de GLPI.
Revisado por el equipo de NexTool Solutions.
