Инвентаризация через прокси с GLPI Agent для сегментированных сетей

Как NexTool внедряет режим прокси GLPI Agent для инвентаризации филиалов, DMZ и сетей OT/ICS без прямого маршрута к серверу GLPI: архитектура, реальная настройка httpd-trust, подводные камни SNAT и расписания, интеграция с правилами и аудитом GLPI.

В этой статьеРазделов: 6

В сегментированных сетях проблема редко в 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Не работаетРешает
Единая точка отказаДополнительной нетКонцентратор (смягчается двумя прокси)
Трафик через WANN соединений1 консолидированное соединение
Эксплуатационная сложностьНизкаяСредняя (1 хост на сопровождении в каждой сети)
Лучше всего дляПлоская сеть / стабильная VPNDMZ, OT, филиал без VPN

Интеграция с GLPI и экосистемой NexTool

Сбор — это половина работы; ценность в том, что GLPI делает после поступления инвентаризации. В парках, которые мы сопровождаем, мы связываем инвентаризацию через прокси с остальным жизненным циклом актива:

  • Бизнес-правила GLPI классифицируют актив по организации/местоположению на основе данных, переданных прокси, — нужный филиал, нужная категория, без ручного ввода.
  • Модуль аудита NexTool фиксирует, когда актив появляется, меняет владельца или исчезает из инвентаризации, — это критично в сетях OT, где оборудование не может просто «пропасть».
  • Уведомления срабатывают, когда прокси перестаёт отчитываться: молчащий концентратор означает целую «слепую» сеть, и это становится оповещением, а не сюрпризом в конце месяца.

Именно это отличает «установку GLPI Agent» от «сопровождения надёжной инвентаризации»: прокси — это входная дверь, но данные становятся управлением активами только тогда, когда GLPI на другой стороне настроен принимать, классифицировать и проверять их.

Если у вас есть филиалы, DMZ или производственные цеха, которые сегодня остаются вне инвентаризации, команда сопровождения GLPI NexTool спроектирует топологию прокси, ужесточит httpd-trust и свяжет инвентаризацию с правилами и аудитом вашего GLPI. Обсудите с нами сопровождение GLPI.


Проверено командой NexTool Solutions.

Часто задаваемые вопросы

Это агент с включённым локальным HTTP-сервером, который принимает инвентаризацию от соседних агентов и пересылает её в GLPI. Он оправдан, когда барьер связан с маршрутом или межсетевым экраном — филиал без VPN, DMZ, сеть OT, — а не когда речь идёт только о масштабе в сети, которая и так видит GLPI. Главное преимущество — свести десятки правил межсетевого экрана к одному на сеть.

Нет. До GLPI должен достучаться только агент-концентратор, как правило по HTTPS на порт 443. Остальные агенты отправляют данные на локальный прокси на порт 62354. Карта межсетевого экрана сокращается с N источников до одной строки на сеть.

Ограничьте его физическим диапазоном сети рабочих станций, например 192.168.10.0/24. Типичная ошибка — указать IP корпоративного исходящего прокси: при SNAT все станции приходят с одним и тем же IP, и любой хост, проходящий через этот прокси, сможет отправлять инвентаризацию. Доверяйте диапазону станций, а не IP шлюза.

Без случайного окна (lazy = 1) сотни компьютеров, включаемых одной и той же GPO, запускают инвентаризацию в одну и ту же минуту утреннего входа и выстраиваются в очередь на концентраторе, перегружая канал филиала. lazy распределяет отправки; delaytime задаёт частоту (86400 секунд = раз в сутки).

Концентратор — единая точка отказа для сети. В критичных сетях мы используем два прокси и мониторим оба: когда концентратор перестаёт отчитываться, это сразу становится оповещением, потому что молчащий прокси означает целую сеть без инвентаризации. Мониторинг прокси выводится на ту же панель сопровождения GLPI.

Нужна помощь?