СЕТЬ CONTROL CENTER — ИНТЕРФЕЙСЫ, ЗОНЫ, WAN/LAN, VLAN И BONDING Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по сетевой конфигурации Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция описывает учет нескольких сетевых интерфейсов, назначение сетевых зон/ролей, конфигурацию LAN/WAN, VLAN и bonding там, где они поддерживаются. Routing, firewall, NAT и port forwarding рассматриваются отдельно в документе 08. КРИТИЧЕСКОЕ ПРАВИЛО Наличие у сервера двух интерфейсов WAN + LAN НЕ превращает Control Center в маршрутизатор. IP forwarding, routing между зонами, NAT и port forwarding включаются только отдельным явным изменением. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Доступ | Локальная консоль/OOB или другой резервный путь доступа Интерфейсы | Обнаружены ОС и Control Center IP-план | Подготовлены адреса, prefix/mask, gateways DNS | Подготовлены записи при изменении адресов VLAN | VLAN IDs и switch port mode согласованы Bonding | Поддерживается ОС/драйвером и согласован со switch Backup | Актуален перед критическим сетевым изменением Права | Network administration АРХИТЕКТУРА Пример multi-NIC узла: Internet/Upstream | [WAN] | +----------------+ | Control Center | | Node | +----------------+ | | [LAN] [MGMT] | | Internal LAN Admin network Это только классификация интерфейсов. Межзонная маршрутизация по умолчанию не предполагается. ПЕРЕД НАЧАЛОМ 1. Откройте console/OOB доступ. 2. Запишите текущие IP, routes, DNS и interface names. 3. Не меняйте одновременно все management interfaces. 4. Если меняется адрес, подготовьте staged configuration и auto-rollback. 5. Для VLAN убедитесь, что switch настроен до применения VLAN на сервере или применяйте согласованный план, исключающий потерю доступа. Для Linux соберите факты: ```bash ip -br link ip -br addr ip route ip rule cat /etc/resolv.conf ``` Ожидаемый результат: Администратор знает текущие интерфейсы, адреса и маршруты до изменения. Шаг 1. Просмотр интерфейсов в Control Center Откройте раздел сети узла [Уточнить название элемента интерфейса]. Для каждого интерфейса проверьте: - системное имя; - MAC, если отображается; - link state/speed, если доступно; - IPv4/IPv6 addresses; - текущую zone/role; - default gateway association; - VLAN/bond membership; - Actual State/freshness. Не определяйте WAN/LAN исключительно по порядку имен eth0/eth1: используйте физическую/логическую схему. Шаг 2. Назначение сетевой зоны/роли 1. Выберите интерфейс. 2. Назначьте роль LAN, WAN, Management или другую поддерживаемую зону [Уточнить точный каталог зон]. 3. Просмотрите diff. 4. Убедитесь, что это изменение метаданных/политики не включает автоматически routing/NAT. 5. Создайте Change. 6. Проверьте Actual State. Ожидаемый результат: Интерфейс классифицирован однозначно, а сетевые политики могут учитывать его зону. Шаг 3. Настройка статического IP Если точное название UI неизвестно, используйте раздел сети узла [Уточнить название элемента интерфейса]. 1. Выберите интерфейс. 2. Укажите IP-адрес и prefix/mask. 3. Укажите gateway только если он должен относиться к этой routing configuration. 4. Не создавайте второй конкурирующий default route без явного policy routing design. 5. Включите staged apply. 6. Укажите/проверьте механизм connectivity confirmation [ТРЕБУЕТ УТОЧНЕНИЯ: timeout и проверка]. 7. Просмотрите diff. 8. Примените Change. 9. Подтвердите доступность по новому адресу. Что изменится: Адрес интерфейса и, возможно, связанные routes. Риск: Потеря management connectivity. Проверка с другой машины: ```bash ping -c 4 ``` Используйте ping только если ICMP разрешен. Более важна проверка фактического административного протокола/Web UI. Rollback: Если connectivity confirmation не проходит, staged configuration должна автоматически вернуть предыдущую сетевую конфигурацию. [ТРЕБУЕТ УТОЧНЕНИЯ: фактический timeout/условия rollback]. Шаг 4. VLAN Используйте VLAN только при поддержке конкретной ОС/драйвера и при согласованной конфигурации switch. План: - parent interface: ; - VLAN ID: ; - address: /; - zone: ; - switch port: trunk/tagged согласно сетевому дизайну. 1. Создайте VLAN subinterface через [Уточнить название элемента интерфейса]. 2. Укажите parent и VLAN ID. 3. Настройте IP. 4. Назначьте зону. 5. Выполните validation. 6. Примените staged Change. 7. Проверьте tagged connectivity. Для диагностики Linux после применения: ```bash ip -d link show ip -br addr ip route ``` Ожидаемый результат: VLAN-интерфейс присутствует в Actual State и достигает только ожидаемой L3-сети. Риск: Неверный tag/native VLAN на switch может полностью потерять связь. Rollback: Удалить новый VLAN через обратный Change; если доступ потерян — automatic staged rollback или console/OOB. Шаг 5. Bonding Bonding используется для устойчивости/агрегации только если поддерживается Control Center, ОС, NIC drivers и switch design. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемые bonding modes и LACP]. Перед созданием: - оба порта должны быть подключены к корректно настроенному switch/domain; - MAC/LACP policy должна соответствовать выбранному mode; - IP должен быть назначен bond interface, а не конфликтующим slave interfaces, согласно выбранной схеме. Порядок: 1. Создайте bond [Уточнить название элемента интерфейса]. 2. Выберите member interfaces. 3. Выберите поддерживаемый mode. 4. Настройте IP/zone на bond. 5. Выполните validation. 6. Примените staged Change. 7. Проверьте link state и connectivity. 8. Проведите контролируемый тест отключения одного физического линка. Ожидаемый результат: При отказе одного допустимого member связь сохраняется в пределах заявленного bonding mode. Для Linux диагностики: ```bash ip -d link show ip -br link ``` [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемая диагностическая команда bond status в каждой ОС]. Шаг 6. Несколько default gateways Не добавляйте несколько default routes без явной архитектуры policy routing/metrics. Control Center должен показывать результат validation и потенциальную асимметрию маршрутов. Если требуется multi-WAN или policy routing — используйте документ 08 и подтвержденную функцию версии. Шаг 7. Проверка после сетевого Change Проверьте из двух точек: 1. с самого узла; 2. с внешней административной станции. Linux: ```bash ip -br addr ip route getent hosts ``` При необходимости: ```bash ip route get ``` Ожидаемый результат: Ответный маршрут к администратору проходит через ожидаемый интерфейс; DNS соответствует фактическому адресу. ПРОВЕРКА ПОСЛЕ НАСТРОЙКИ - [ ] все интерфейсы идентифицированы; - [ ] зоны назначены корректно; - [ ] WAN/LAN не включили routing/NAT автоматически; - [ ] management path сохранен; - [ ] VLAN tags соответствуют switch; - [ ] bond members Healthy; - [ ] default route однозначен или policy routing осознанно настроен; - [ ] DNS соответствует адресам; - [ ] Actual State совпадает с Desired State; - [ ] нет Critical network alerts; - [ ] staged rollback был доступен для рискованного изменения. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение После apply потерян Web UI | неверный IP/gateway/VLAN | console: ip addr/route | дождаться auto-rollback или восстановить через OOB VLAN не работает | switch не trunk/tagged, неверный ID | ip -d link; switch config | согласовать VLAN ID/mode Bond не поднимается | switch/LACP mismatch | link/bond state | исправить mode на обеих сторонах Ответ идет не тем интерфейсом | несколько default routes/metrics | ip route get | исправить routing policy WAN и LAN связаны неожиданно | routing/forwarding включены отдельно | document 08 checks | отключить ненужное forwarding policy штатным Change РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - выделяйте отдельный management path при возможности; - критические IP changes выполняйте только с console/OOB; - используйте staged apply + automatic rollback; - документируйте switch-side VLAN/LACP конфигурацию; - не используйте DHCP на критичных server-facing адресах без reservation и согласованной DNS policy; - проверяйте MTU end-to-end при VLAN/bond/storage networks; - не смешивайте изменение IP, hostname, cluster membership и role migration в одном Change. ИТОГ Control Center управляет multi-NIC сетью как отдельной подсистемой: интерфейсы классифицируются по зонам, VLAN/bonding применяются только при подтвержденной поддержке, а рискованные изменения выполняются staged с проверкой связности и rollback. WAN+LAN не включает маршрутизацию автоматически. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - точные network UI names; - supported zones; - staged timeout/confirmation algorithm; - supported VLAN options; - supported bonding modes/LACP; - IPv6 scope; - MTU/jumbo frame support; - exact network permissions.