DNS, NTP И БЕЗОПАСНОЕ ИЗМЕНЕНИЕ IP-АДРЕСА Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по базовым сетевым службам Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Инструкция описывает требования к DNS и синхронизации времени, а также безопасную процедуру смены IP-адреса узла Control Center с предварительной проверкой, staged configuration, проверкой доступности и автоматическим rollback при потере связи. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Доступ | Console/OOB или иной независимый резервный канал DNS | Права на изменение необходимых записей Новый IP | Свободен, входит в утвержденный IP-план Gateway/routes | Подготовлены до изменения NTP | Доступны утвержденные источники времени Backup | Актуален перед cluster-critical изменениями Кластер | Все узлы Healthy до смены адреса одного из них АРХИТЕКТУРА DNS связывает стабильное имя узла с его адресом. NTP обеспечивает согласованное время для аутентификации, сертификатов, журналов, кластерных и распределенных операций. Admin client → DNS → FQDN → Control Center node | +→ NTP-synchronized time Смена IP считается завершенной только после подтверждения сетевой доступности, DNS и Actual State. ПЕРЕД НАЧАЛОМ 1. Зафиксируйте старый IP, prefix, gateway и DNS records. 2. Проверьте доступ через console/OOB. 3. Убедитесь, что новый IP не занят. 4. Определите все зависимости от старого адреса: DNS, firewall ACL, monitoring, reverse proxy, certificates, cluster peers, external integrations. 5. Не меняйте одновременно hostname, IP и cluster membership. 6. Для multi-node меняйте по одному узлу и проверяйте Healthy между изменениями. Шаг 1. Проверка DNS Для Linux: ```bash getent hosts getent ahosts ``` Ожидаемый результат: Имя разрешается в ожидаемый текущий адрес. Если возвращается несколько адресов, они должны соответствовать планируемой схеме. Проверка reverse DNS, если в системе доступен `getent`: ```bash getent hosts ``` Reverse DNS рекомендуется для управляемых серверов, но обязательность зависит от конкретного deployment profile. Шаг 2. Проверка NTP На Linux/systemd: ```bash timedatectl status ``` Дополнительная проверка: ```bash timedatectl show -p NTPSynchronized --value ``` Ожидаемый результат: Системное время синхронизировано; второй вызов возвращает `yes`, если systemd сообщает синхронизацию через этот интерфейс. Если время не синхронизировано: Не переходите к cluster/identity-sensitive операциям до восстановления NTP. Не исправляйте время произвольным ручным скачком на production-узле без оценки влияния. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемая настройка NTP-серверов через Control Center и точное название UI]. Шаг 3. Подготовка DNS к смене IP Если организационная DNS-политика позволяет, заранее уменьшите TTL записи до разумного значения в соответствии с вашей DNS-практикой. Не используйте универсальное значение без учета authoritative DNS и кэшей. Подготовьте: - FQDN: ; - старый адрес: ; - новый адрес: ; - prefix: ; - gateway: ; - DNS server(s): . Не удаляйте старую запись до подтверждения новой связности, если выбранная миграционная схема допускает временное сосуществование адресов. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживает ли версия временный secondary address при staged migration]. Шаг 4. Preflight нового адреса Проверьте, что новый адрес не отвечает как другое устройство. Используйте методы, разрешенные вашей сетью. Обычный ping не доказывает отсутствие конфликта, если ICMP блокируется. После назначения адреса ОС/Control Center должен выполнить duplicate-address/conflict validation, если поддерживается. [ТРЕБУЕТ УТОЧНЕНИЯ: точный механизм duplicate address detection]. Шаг 5. Создание staged network Change 1. Откройте сетевую конфигурацию узла [Уточнить название элемента интерфейса]. 2. Выберите management-интерфейс. 3. Укажите новый IP/prefix. 4. Проверьте gateway и routes. 5. Запустите validation/preview. 6. Убедитесь, что включен staged apply с connectivity rollback. 7. Просмотрите diff. 8. Примените Change. Что изменится: Основной адрес узла и, возможно, связанные маршруты/источник исходящих соединений. Риск: Потеря доступа к Web/API, разрыв связи между cluster peers и внешними интеграциями. Rollback: Если Control Center не получает подтверждение связности в установленный срок, он должен вернуть предыдущую рабочую конфигурацию. [ТРЕБУЕТ УТОЧНЕНИЯ: timeout, контрольные endpoints и условия auto-rollback]. Шаг 6. Подтверждение нового IP С независимой административной станции проверьте: ```bash ping -c 4 ``` Ping применим только если ICMP разрешен. Затем обязательно проверьте фактический административный доступ через штатный Web/API endpoint [ТРЕБУЕТ УТОЧНЕНИЯ: URL/порт]. На самом узле: ```bash ip -br addr ip route ip route get ``` Ожидаемый результат: Новый IP активен, ответный маршрут к администратору идет через ожидаемый интерфейс, UI/API доступны. Шаг 7. Обновление DNS После подтверждения сетевой доступности обновите A/AAAA запись через ваш authoritative DNS-механизм. Не приводится универсальная команда, потому что DNS-провайдер/сервер не определен. Ожидаемый результат: ```bash getent ahosts ``` возвращает новый адрес после истечения/обновления кэшей. Если используются reverse records, обновите их согласованно. Шаг 8. Проверка сертификатов и интеграций Если TLS-сертификат выпущен на FQDN, смена IP обычно не требует смены имени сертификата; если сертификат содержит IP SAN или интеграция привязана к IP, требуется отдельное обновление. Проверьте: - cluster peers; - firewall ACL; - reverse proxy/load balancer; - backup target allowlists; - monitoring/alerting; - Market modules, если они используют адрес узла; - external integrations. Не меняйте сертификат «на всякий случай» без необходимости. Шаг 9. Multi-node/HA Для кластера: 1. изменяйте только один узел; 2. при необходимости переведите его в maintenance/drain согласно документу 06; 3. убедитесь, что quorum сохранен; 4. примените staged IP change; 5. подтвердите inter-node connectivity и Healthy; 6. дождитесь Actual State/replication catch-up; 7. только затем переходите к следующему узлу. Риск: Одновременная смена адресов нескольких узлов может сделать cluster membership недоступным и усложнить recovery. Rollback: Верните старый адрес на текущем узле, восстановите Healthy, затем пересмотрите план. Не продолжайте массовую смену при первой неизвестной ошибке. Шаг 10. Возврат DNS TTL После стабилизации верните TTL к обычной организационной политике, если он временно менялся. ПРОВЕРКА ПОСЛЕ ИЗМЕНЕНИЯ - [ ] новый IP активен; - [ ] старый IP удален или сохранен только если это предусмотрено планом; - [ ] FQDN разрешается корректно; - [ ] reverse DNS корректен, если используется; - [ ] NTP synchronized; - [ ] Web/API доступны; - [ ] ответный route корректен; - [ ] cluster peers Healthy; - [ ] firewall/ACL обновлены; - [ ] мониторинг и backup видят узел; - [ ] Desired State = Actual State; - [ ] Audit содержит Change; - [ ] staged rollback больше не ожидает подтверждения. ТИПОВЫЕ ОШИБКИ Симптом | Возможная причина | Проверка | Решение FQDN ведет на старый IP | DNS cache/TTL/запись не обновлена | getent ahosts | проверить authoritative запись и дождаться TTL Новый IP доступен локально, но не удаленно | route/VLAN/firewall/gateway | ip route get; документ 07–08 | исправить конкретную сетевую причину После смены IP кластер Degraded | peers используют старый адрес или ACL | Health/Actual/cluster evidence | вернуть старый IP либо обновить поддерживаемые peer records штатно NTP не synchronized | источник времени недоступен | timedatectl status | восстановить NTP до дальнейших cluster changes Сертификат не принимается | клиент использует IP, а сертификат только на FQDN или изменился SAN | TLS error details | использовать корректный FQDN/выпустить поддерживаемый сертификат РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - используйте FQDN как стабильную точку доступа вместо жесткой привязки клиентов к IP; - применяйте статический IP или DHCP reservation согласно инфраструктурной политике; - критические сетевые изменения выполняйте только при наличии OOB/console; - используйте staged apply и automatic rollback; - сохраняйте DNS/NTP как независимые критические зависимости; - не меняйте несколько HA-узлов одновременно; - после изменения проверяйте не только ping, но и реальный application path. ИТОГ Безопасная смена IP в Control Center выполняется как контролируемое staged изменение: preflight → новый адрес → проверка связности → DNS/integration update → Actual State/Health. DNS и NTP должны оставаться исправными на всем протяжении процедуры. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - точные UI names; - URL/port Web/API; - staged connectivity timeout; - rollback trigger/confirmation mechanism; - secondary IP support; - duplicate-address detection; - NTP configuration UI/provider model; - cluster peer-address update semantics; - IPv6-specific procedure.