В сегментированных сетях проблема редко в GLPI Agent — она в маршруте. У филиалов без VPN, DMZ, сетей OT/ICS и лабораторий обычно есть только исходящий HTTP наружу и никогда — прямой путь к серверу инвентаризации. При сопровождении парков GLPI для клиентов именно здесь режим прокси GLPI Agent перестаёт быть любопытной строчкой документации и становится продуктивной архитектурой: один агент на сеть собирает инвентаризацию соседей и передаёт её в GLPI по одному контролируемому каналу.
Где прокси действительно помогает (и где нет)
Режим прокси существует не для того, чтобы «сэкономить агенты». Он нужен, чтобы свести N правил межсетевого экрана к одному. Без прокси каждая рабочая станция филиала должна была бы достучаться до сервера GLPI — то есть пришлось бы открыть весь парк в сторону ЦОД или зависеть от VPN, которая редко охватывает сеть принтеров, контроллеры производства или гостевой сегмент. С прокси с GLPI общается только агент-концентратор. Ситуации, в которых мы его применяем:
- Филиалы без прямой VPN до ЦОД, где разрешён только веб-доступ.
- Изолированные сети: DMZ, OT/ICS (производственный цех), лаборатория, гостевой сегмент.
- Строгий межсетевой экран, где только исходящий HTTP/HTTPS-трафик проходит через корпоративный прокси.
- Удалённые площадки с нестабильным каналом, где локальная концентрация и повторная отправка снижают повторные передачи через WAN.
Где это не имеет смысла: плоская сеть, которая уже видит GLPI, или небольшой парк за стабильной VPN. Там прокси лишь добавляет точку отказа. Правило, которым мы пользуемся в консалтинге, простое: прокси — когда барьер связан с маршрутом/межсетевым экраном, а не с масштабом.
Архитектура: один концентратор на сетевой домен
[Estacoes Filial A] --HTTP--> [GLPI Agent Proxy A :62354] --+
[Estacoes Filial B] --HTTP--> [GLPI Agent Proxy B :62354] --+--HTTPS 443--> [Servidor GLPI]
[Rede OT/ICS] --HTTP--> [GLPI Agent Proxy C :62354] --+ (glpi.suaempresa.com)
В каждой сети есть агент с включённым локальным HTTP-сервером (функция proxy). Агенты рабочих станций не знают о GLPI: они отправляют инвентаризацию на прокси своей сети. Прокси пересылает её на сервер GLPI по одному TLS-соединению. Эксплуатационный результат: в карте межсетевого экрана клиента вместо десятков источников остаётся одна строка на сеть.
Реальная конфигурация, которую мы запускаем в продуктив
В версиях GLPI Agent 1.x конфигурация хранится в файлах .cfg, а служба предоставляет HTTP-задачи на порту 62354. Концентратору нужны две вещи: включённая задача локального сервера и список доверия (httpd-trust), ограниченный диапазоном сети, — никогда не открытый.
1. Агент-концентратор (прокси сети)
# /etc/glpi-agent/conf.d/proxy.cfg (agente concentrador)
# Para onde os inventarios coletados sao reenviados:
server = https://glpi.suaempresa.com/front/inventory.php
# Liga o servidor HTTP embutido e a tarefa que aceita repasse:
tasks = inventory, remoteinventory
# Confianca: SOMENTE o range da rede local pode postar 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 duplicidade:
no-task = collect
2. Агенты рабочих станций (указывают на прокси, а не на GLPI)
# /etc/glpi-agent/conf.d/local.cfg (estacoes 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/dia:
delaytime = 86400
# Evita todos dispararem no mesmo instante (janela aleatoria):
lazy = 1
3. Быстрая проверка на концентраторе
# O listener respondeu?
curl -sS http://localhost:62354/ | head -n 5
# Forcar uma execucao e observar o reenvio ao GLPI:
glpi-agent --debug --force
# No servidor: o inventario chegou pelo proxy?
tail -f /var/log/glpi-agent/glpi-agent.log | grep -i "success"
Чему NexTool научилась на практике
Деталь, которая проявляется только в сопровождении: когда httpd-trust слишком широк (или указывает на корпоративный прокси, выполняющий SNAT), все рабочие станции приходят на концентратор с одним и тем же исходным IP — IP корпоративного прокси. Если вы доверились IP корпоративного прокси вместо реального диапазона станций, на практике любой хост, проходящий через этот прокси, может отправлять инвентаризацию. Мы всегда исправляем это, ограничивая httpd-trust физическим диапазоном сети станций, и никогда — IP исходящего шлюза. Второй урок касается расписания: без lazy = 1 парки из сотен компьютеров, включаемых одной и той же GPO, запускают инвентаризацию в одну и ту же минуту утреннего входа и выстраиваются в очередь на концентраторе — канал филиала захлёбывается каждый день в 8 утра. Случайное окно lazy решает это, не затрагивая инфраструктуру.
Режим прокси или прямой агент: когда что выбирать
| Критерий | Прямой агент | Режим прокси |
|---|---|---|
| Правила межсетевого экрана | По одному на источник (не масштабируется) | По одному на сеть |
| Сеть без маршрута к GLPI | Не работает | Решает |
| Единая точка отказа | Дополнительной нет | Концентратор (смягчается двумя прокси) |
| Трафик через WAN | N соединений | 1 консолидированное соединение |
| Эксплуатационная сложность | Низкая | Средняя (1 хост на сопровождении в каждой сети) |
| Лучше всего для | Плоская сеть / стабильная VPN | DMZ, OT, филиал без VPN |
Интеграция с GLPI и экосистемой NexTool
Сбор — это половина работы; ценность в том, что GLPI делает после поступления инвентаризации. В парках, которые мы сопровождаем, мы связываем инвентаризацию через прокси с остальным жизненным циклом актива:
- Бизнес-правила GLPI классифицируют актив по организации/местоположению на основе данных, переданных прокси, — нужный филиал, нужная категория, без ручного ввода.
- Модуль аудита NexTool фиксирует, когда актив появляется, меняет владельца или исчезает из инвентаризации, — это критично в сетях OT, где оборудование не может просто «пропасть».
- Уведомления срабатывают, когда прокси перестаёт отчитываться: молчащий концентратор означает целую «слепую» сеть, и это становится оповещением, а не сюрпризом в конце месяца.
Именно это отличает «установку GLPI Agent» от «сопровождения надёжной инвентаризации»: прокси — это входная дверь, но данные становятся управлением активами только тогда, когда GLPI на другой стороне настроен принимать, классифицировать и проверять их.
Если у вас есть филиалы, DMZ или производственные цеха, которые сегодня остаются вне инвентаризации, команда сопровождения GLPI NexTool спроектирует топологию прокси, ужесточит httpd-trust и свяжет инвентаризацию с правилами и аудитом вашего GLPI. Обсудите с нами сопровождение GLPI.
Проверено командой NexTool Solutions.