IPAM в Windows Server 2012 R2: пять офисов - один интерфейс для IP, DHCP и DNS

До этого проекта управление IP-пространством у клиента выглядело примерно так: один файл Excel на сетевом диске (последнее обновление - два года назад), одна голова главного сетевика, которая помнит «примерно что где», и три консоли DHCP на разных серверах, между которыми нужно переключаться вручную. Пять офисов, несколько подсетей в каждом, один общий хаос.

Мы про IPAM в WS2012 R2 уже упоминали мельком - в обзоре первых недель на этой платформе отметили, что он «перестал быть игрушкой». Пришло время разобраться детально на реальной задаче.

Что такое IPAM в WS2012 R2 и почему не phpIPAM

IPAM - это роль Windows Server, которая агрегирует данные со всех DHCP и DNS серверов в инфраструктуре и даёт единый интерфейс для работы с ними. Устанавливается на отдельный сервер, интегрируется с Active Directory, подключается к DHCP/DNS-серверам через групповые политики - никаких агентов, никаких дополнительных компонентов на управляемых серверах.

Сторонние инструменты типа phpIPAM или Infoblox существуют давно. phpIPAM для SMB - это отдельный Linux-сервер, поддержка, и главное - ручная синхронизация: данные там актуальны настолько, насколько кто-то их обновляет. Infoblox - это уже совсем другой масштаб и бюджет. Встроенный IPAM привлекает тем, что данные из DHCP/DNS туда прилетают сами, без ручного ввода.

Важное ограничение сразу: IPAM работает только с Windows DHCP и DNS. Если в инфраструктуре есть ISC DHCP или BIND - IPAM про них не знает. У нашего клиента вся сеть на Windows, поэтому это не проблема.

Как разворачивали

Топология у клиента: пять офисов, в каждом свой DHCP-сервер (часть - выделенные, часть - совмещены с DC), DNS - Active Directory integrated, контроллеры домена в каждом офисе. Суммарно штук восемь-девять серверов DHCP/DNS, которые нужно завести под наблюдение.

IPAM-сервер поставили в главном офисе на отдельную VM - рекомендация Microsoft не совмещать IPAM с DC или DHCP-сервером, и это разумно. Роль ставится через Server Manager, первоначальная настройка - через мастер.

Дальше самое интересное - обнаружение серверов. IPAM находит все DHCP и DNS серверы в домене автоматически. Потом нужно настроить доступ: IPAM создаёт GPO, которые разрешают ему опрашивать найденные серверы. GPO создаётся автоматически через Invoke-IpamGpoProvisioning в PowerShell, потом нужно применить их к нужным OU. Схема немного непривычная, но логика понятна.

На то чтобы данные появились в консоли IPAM, ушло часа два - с учётом того, что GPO применились не мгновенно и один сервер в дальнем офисе потребовал ручного gpupdate.

Что увидели после подключения

Первая реакция - что-то между «вот оно» и «ох, сколько же тут мусора».

IP-адреса. Все выданные адреса со всех DHCP-серверов в одном списке. Фильтрация по офису, по подсети, по имени хоста, по MAC. Ищешь адрес или имя машины - один поиск вместо трёх консолей. Это уже окупает развёртывание.

История аренд DHCP. Это отдельная ценность. IPAM хранит историю: кто и когда получил адрес, с какого MAC. Прилетает вопрос «а кто вчера в 14:30 был на адресе 192.168.5.47» - раньше это был детектив с логами на конкретном DHCP-сервере. Теперь - поиск по времени в IPAM. Логи за несколько месяцев, глубина зависит от настроек хранения.

Дублирующиеся DNS-записи. Это оказалось самым болезненным открытием. В DNS нашлось несколько десятков записей, которые указывают на адреса, давно не принадлежащие этим именам. Машины переименовали, пересоздали, адреса переехали - а старые A-записи никто не чистил. IPAM это видит, потому что сопоставляет данные DHCP и DNS: если запись DNS указывает на адрес, который сейчас выдан другому хосту или вообще не выдан - это видно.

Часть таких записей безобидна. Часть - потенциальные конфликты, которые могут аукнуться при следующем переезде сервиса.

Где пришлось повозиться

Scope utilization. IPAM показывает загрузку каждого DHCP-скоупа - сколько адресов выдано, сколько свободно. В трёх офисах скоупы оказались забиты под 90% и выше. Один - вообще переполнен, клиенты периодически не могли получить адрес и сисадмин на месте этого даже не замечал (машины держали аренду, новые подключения падали). IPAM это видит и выводит в статус.

Права доступа. IPAM имеет свою ролевую модель: Administrator, IP Address Record Administrator, DHCP Administrator и так далее. Для распределённой команды это полезно, но настраивать нужно аккуратно - по умолчанию доступа ни у кого нет кроме IPAM Administrator.

DNS через IPAM. Просматривать DNS-зоны и записи удобно. Редактировать - уже менее удобно, для сложных изменений всё равно идёшь в DNS Manager. IPAM здесь скорее read-mostly инструмент для DNS, чем полноценная замена консоли.

Время синхронизации. IPAM опрашивает серверы по расписанию, не в реальном времени. Свежевыданный адрес может появиться в IPAM с задержкой в несколько минут. Для большинства задач это нормально, но надо знать.

Итог

Через неделю после развёртывания клиент уже не вспоминает про Excel. Задача «найти машину по имени» или «посмотреть что было на этом адресе вчера» решается за секунды. Найденные дублирующиеся DNS-записи почистили - это отдельная работа, но хорошо что нашли.

Для инфраструктуры на Windows, которую мы ведём в рамках сопровождения, IPAM - это один из тех инструментов, который просто имеет смысл развернуть, особенно если площадок больше двух. Не навороченная система, не enterprise-платформа - но Excel закрывает надёжно.