IPv6 в корпоративной сети: dual-stack с нуля, и почему сложно оказался мониторинг
RIPE NCC зафиксировал исчерпание IPv4 в Европе. Разворачивали дата-центр клиента сразу в dual-stack - настройка прошла гладко, а вот научить Zabbix проверять оба стека оказалось интереснее.
RIPE NCC фиксирует исчерпание пула адресов IPv4 в Европе - dual-stack становится нормой для новых сервисов и дата-центров
На прошлой неделе RIPE NCC официально сообщил: свободных адресов IPv4 в европейском пуле нет. Совсем. Получить новый блок можно только из листа ожидания, когда кто-то вернёт неиспользуемое. На практике это значит: новый дата-центр без IPv6 - это дата-центр, который уже сегодня ограничивает себя в возможностях расширения.
Примерно с этим настроением мы заходили на проект нового ДЦ для клиента. Поставили условие ещё на этапе проектирования: dual-stack с первого дня, каждый сервер и каждый контейнер получает и IPv4, и IPv6-адрес. Отдельного «перехода на IPv6 потом» не будет - только параллельная работа обоих стеков сразу.
Как разворачивали сеть
Топология получилась классическая для небольшого ДЦ: граничные маршрутизаторы с BGP-сессиями к двум провайдерам, внутри - OSPF между коммутаторами, серверный сегмент с VLAN-изоляцией. IPv6 шёл параллельно по той же физике.
Провайдеры выделили /48 для каждого из двух аплинков. Из этих блоков нарезали /64 на каждый VLAN - IPv6 позволяет не жадничать с адресами, и это приятно после многолетнего считания IPv4-подсетей. SLAAC для автоконфигурации серверов отключили - предпочли статические адреса через DHCPv6, чтобы всё было предсказуемо и в инвентаре.
Серверы. На CentOS 7 dual-stack заработал без особых приключений: в /etc/sysconfig/network-scripts/ в тот же ifcfg-eth0 добавили строки IPV6ADDR, IPV6_DEFAULTGW и включили IPV6INIT=yes, после чего у каждого хоста стало по два адреса на каждом интерфейсе. На Ubuntu несколько иначе - там /etc/network/interfaces с секцией inet6 static. Мелочь, но при автоматизации через Ansible пришлось писать ветку под каждый дистрибутив.
Контейнеры. Docker 1.9 с IPv6 работает, но с оговорками. Параметры --ipv6 и --fixed-cidr-v6 при запуске демона включают IPv6 для контейнеров, но nat66 по умолчанию не настраивается - пришлось добавлять правила ip6tables вручную. Не катастрофа, но и не «просто включи флаг».
Где оказалась настоящая сложность
Сеть поднялась примерно за три дня с учётом тестирования. Мониторинг занял вдвое больше.
Проблема в том, что Zabbix по умолчанию думает в терминах «один хост - один IP». Если у хоста два адреса разных семейств - это не автоматически два канала проверки. Нужно явно настроить оба.
Первое, что сломалось - проверки доступности. Стандартный ICMP-пинг в Zabbix идёт по адресу, прописанному в карточке хоста. Если прописан только IPv4, IPv6 не проверяется вообще. Мы узнали об этом когда у одного из серверов отвалился IPv6-маршрут, и мониторинг об этом молчал ещё полдня - всё выглядело зелёным.
Решение: добавили каждому хосту интерфейс с IPv6-адресом отдельно. Для этого в API Zabbix есть параметр type у интерфейса - можно добавить сколько угодно IP одному хосту. Написали скрипт, который берёт инвентарь и создаёт второй интерфейс для каждого хоста автоматически. После этого Zabbix стал честно пинговать оба адреса и триггерить раздельно.
Второе - сервисные проверки. Проверить что nginx слушает на порту 443 - это net.tcp.service[https,,443] в Zabbix-агенте. Но этот чек идёт к localhost, а вот внешние HTTP-проверки через Zabbix-прокси - уже к конкретному адресу. По умолчанию прокси выбирает IPv4. Для сервисов, которые должны быть доступны по IPv6, добавили отдельные web-сценарии с явным указанием IPv6-адреса. Некоторые команды Zabbix-агента умеют сами различать стеки через net.tcp.service с указанием адреса - этим и пользовались.
Третье, самое неочевидное - алертинг. Когда упал IPv4 у сервера, а IPv6 работал - по умолчанию Zabbix поднимал проблему по обоим интерфейсам. Это правильно с точки зрения мониторинга: оба стека должны работать. Но дежурный получал два алерта на один инцидент и начинал путаться. Настроили зависимости триггеров: если упал «родительский» IPv4-пинг и одновременно IPv6-пинг - это один инцидент с двумя симптомами. Если упал только IPv6 - отдельный алерт с пометкой про стек.
Что получилось
Два стека работают. Новые сервисы клиент анонсирует сразу на оба адреса - AAAA-запись рядом с A-записью стала стандартной практикой для этого ДЦ. Внешние пользователи с IPv6 идут по нему, остальные - по IPv4.
Zabbix теперь честно контролирует оба канала, хотя конфигурация получилась объёмнее чем мы планировали. На каждый хост - два интерфейса, на часть сервисов - дополнительные web-сценарии. Опыт с Docker и LLD помог: мы уже умели автоматизировать создание объектов через Zabbix API, так что хосты в мониторинг добавляются скриптом, а не руками.
Выводов два. Настройка dual-stack на уровне сети и ОС - решаемо, документации достаточно, грабли стандартные. Приведение инструментов мониторинга к реальности с двумя стеками - отдельная задача, которую лучше закладывать в план с самого начала, а не «потом допилим». Потом всегда находится что-то важнее.
Для managed-клиентов с новыми площадками мы теперь по умолчанию спрашиваем про IPv6 ещё на этапе предпроектного обсуждения - дешевле заложить сразу, чем прокладывать поверх готовой инфраструктуры.