NexTool Solutions

Em redes segmentadas, o problema raramente é o GLPI Agent - é a rota. Filiais sem VPN, DMZ, redes OT/ICS e laboratórios costumam ter apenas saída HTTP para o exterior e nunca um caminho direto até ao servidor de inventário. Na sustentação de parques GLPI para clientes, é aí que o modo proxy do GLPI Agent deixa de ser curiosidade da documentação e passa a ser arquitetura de produção: um agente por rede concentra o inventário dos vizinhos e reencaminha-o para o GLPI através de um único canal controlado.

Onde o proxy realmente resolve (e onde não)

O modo proxy não existe para "poupar agentes". Existe para reduzir N regras de firewall a uma só. Sem proxy, cada posto de uma filial teria de alcançar o servidor GLPI - o que significa abrir o parque inteiro para o centro de dados, ou depender de uma VPN que raramente cobre a rede das impressoras, os controladores da fábrica ou o segmento de convidados. Com proxy, só o concentrador fala com o GLPI. As situações onde o adotamos:

• Filiais sem VPN direta para o centro de dados, com apenas navegação web permitida.
• Redes isoladas: DMZ, OT/ICS (chão de fábrica), laboratório, segmento de convidados.
• Firewalls restritivos onde só o tráfego de saída HTTP/HTTPS passa por um proxy corporativo.
• Locais remotos com ligação instável, onde concentrar e reenviar localmente reduz a retransmissão pela WAN.

Onde não vale a pena: rede plana que já vê o GLPI, ou parque pequeno atrás de uma VPN estável. Aí o proxy só acrescenta um ponto de falha. A regra que usamos na consultoria é simples: proxy quando a barreira é de rota/firewall, não quando é de escala.

Arquitetura: um concentrador por domínio de rede

[Postos Filial A] --HTTP--> [GLPI Agent Proxy A :62354] --+
[Postos Filial B] --HTTP--> [GLPI Agent Proxy B :62354] --+--HTTPS 443--> [Servidor GLPI]
[Rede OT/ICS]     --HTTP--> [GLPI Agent Proxy C :62354] --+     (glpi.suaempresa.com)

Cada rede tem um agente com o servidor HTTP local ligado (a função proxy). Os agentes dos postos não conhecem o GLPI: publicam o seu inventário no proxy da própria rede. O proxy reencaminha-o para o servidor GLPI numa única ligação TLS. Na prática, o mapa de firewall do cliente deixa de ter dezenas de origens e passa a ter uma linha por rede.

Configuração real que colocamos em produção

Nas versões 1.x do GLPI Agent a configuração reside em ficheiros .cfg e o serviço expõe as tarefas HTTP na porta 62354. O concentrador precisa de duas coisas: a tarefa de servidor local ligada e uma lista de confiança (httpd-trust) restrita ao intervalo da rede - nunca aberta.

1. Agente concentrador (proxy da rede)

# /etc/glpi-agent/conf.d/proxy.cfg  (agente concentrador)
# Para onde os inventarios recolhidos sao reencaminhados:
server = https://glpi.suaempresa.com/front/inventory.php

# Liga o servidor HTTP integrado e a tarefa de reencaminhamento:
tasks = inventory, remoteinventory

# Confianca: SO o intervalo da rede local pode publicar no proxy
httpd-trust = 192.168.10.0/24

# Porta do listener local (default do GLPI Agent):
httpd-port = 62354

# Nao inventariar o proprio concentrador em duplicado:
no-task = collect

2. Agentes dos postos (apontam para o proxy, não para o GLPI)

# /etc/glpi-agent/conf.d/local.cfg  (postos da filial)
# O "server" aqui e o proxy da rede, nao o GLPI:
server = http://proxy-filial-a.local:62354

# Frequencia de reenvio (segundos). 86400 = 1x por dia:
delaytime = 86400

# Evita que todos disparem no mesmo instante (janela aleatoria):
lazy = 1

3. Validação rápida no concentrador

# O listener respondeu?
curl -sS http://localhost:62354/ | head -n 5

# Forcar uma execucao e observar o reencaminhamento para o GLPI:
glpi-agent --debug --force

# No servidor: o inventario chegou pelo proxy?
tail -f /var/log/glpi-agent/glpi-agent.log | grep -i "success"

O que a NexTool aprendeu na prática

Um detalhe que só aparece na sustentação: quando o httpd-trust fica demasiado largo (ou aponta para um proxy corporativo que faz SNAT), todos os postos chegam ao concentrador com o mesmo IP de origem - o do proxy da empresa. Se confiou no IP do proxy corporativo em vez do intervalo real dos postos, na prática qualquer host que atravesse esse proxy pode publicar inventário. Corrigimos sempre restringindo o httpd-trust ao intervalo físico da rede dos postos, nunca ao IP da gateway de saída. A segunda lição é sobre o horário: sem lazy = 1, parques com centenas de máquinas ligadas pela mesma GPO disparam o inventário no mesmo minuto do login matinal e formam fila no concentrador; a ligação da filial engasga às 8h todos os dias. A janela aleatória do lazy resolve isto sem mexer na infraestrutura.

Modo proxy vs agente direto: quando escolher cada um

Integração com o GLPI e o ecossistema NexTool

Recolher é metade do trabalho; o valor está no que o GLPI faz depois de o inventário chegar. Nos parques que sustentamos, ligamos o inventário por proxy ao restante ciclo de vida do ativo:

• As regras de negócio do GLPI classificam o ativo por entidade/localização a partir do dado que o proxy trouxe - a filial certa, a categoria certa, sem digitação manual.
• O módulo de auditoria da NexTool regista quando um ativo entra, muda de dono ou desaparece do inventário - essencial em redes OT onde um equipamento não pode simplesmente "desaparecer".
• As notificações disparam quando um proxy deixa de reportar: um concentrador mudo significa uma rede inteira cega, e isso torna-se um alerta, não uma surpresa no final do mês.

É isto que separa "instalar o GLPI Agent" de "sustentar inventário fiável": o proxy é a porta de entrada, mas o dado só se torna gestão de ativos quando o GLPI ao lado está configurado para receber, classificar e auditar.

Se a sua rede tem filiais, DMZ ou chão de fábrica que hoje ficam de fora do inventário, a equipa de sustentação GLPI da NexTool desenha a topologia de proxies, reforça o httpd-trust e liga o inventário às regras e auditoria do seu GLPI. Fale connosco sobre sustentação de GLPI.

Revisto pela equipa NexTool Solutions.