Лаборатория: безопасный переход с DHCP на статический IPv4¶
Этот сценарий описывает управляемое изменение адреса сервера НАЙС.ОС CLOUD через systemd-networkd. Он предназначен для изолированной VM и отработки регламента без потери административного доступа. Примеры используют учебные сети RFC 5737 и не должны применяться как реальные адреса.
Цель и границы¶
Нужно заменить DHCP на статическую адресацию, сохранить DNS и маршрут, проверить SSH с другого компьютера, а при ошибке вернуться к исходной конфигурации.
Выполнять на реальной машине допускается только при наличии резервной консоли VM/IPMI, утверждённых IP/gateway/DNS, бэкапа и выделенного окна работ. Изменение общего системного DHCP-профиля из /usr/lib запрещено: отдельный .network добавляется в /etc/systemd/network/ после анализа приоритетов.
Исходные данные примера¶
| Поле | Учебное значение | Что нужно узнать в реальной сети |
|---|---|---|
| Интерфейс | ens3 |
ip -br link, networkctl status |
| IPv4 | 192.0.2.45/24 |
Свободный адрес/маска от администратора |
| Gateway | 192.0.2.1 |
Шлюз подсети |
| DNS | 192.0.2.53 |
Разрешённый DNS-сервер |
| Домен | example.test |
Внутренний домен, если требуется |
| SSH | 22/tcp |
Активный порт и политика firewall |
Контрольная точка А: наблюдение¶
cat /etc/os-release
ip -br link
ip -br addr
ip -4 route
networkctl status ens3
resolvectl status ens3
iptables -S INPUT
iptables -S OUTPUT
ss -lntp | grep ':22'
Задайте в протоколе точный вывод Network File, наличие cloud-init и факт получения DHCP. Если в networkd виден неподтверждённый профиль /run/systemd/network/..., сначала исследуйте его владельца. Не заменяйте его без установления источника генерации.
Контрольная точка Б: резервная копия и способ отката¶
umask 077
backup="/root/network-change-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$backup"
cp -a /etc/systemd/network "$backup/network-etc"
ip -br addr > "$backup/ip-before.txt"
ip -4 route > "$backup/routes-before.txt"
networkctl status ens3 > "$backup/networkctl-before.txt"
Если есть конфиги в /run/systemd/network/, учтите, что они временные и обычно не сохраняются между reboot; просто скопировать их недостаточно, чтобы остановить их генерацию. Обязательно задокументируйте расположение профилей и настройку cloud-init.
Контрольная точка В: подготовка конфигурации¶
Создайте /etc/systemd/network/10-ens3-static.network (если имя не конфликтует с другой политикой сопоставления):
[Match]
Name=ens3
[Network]
DHCP=no
Address=192.0.2.45/24
Gateway=192.0.2.1
DNS=192.0.2.53
Domains=example.test
В реальной сети подставьте согласованные параметры. Если существующий профиль 10-ens3.network содержит VLAN, bridge, маршруты или особые настройки, его нельзя просто затенить новым файлом — перенесите все необходимые параметры в новый корректно составленный профиль или отредактируйте прежний под контролем консоли.
Контрольная точка Г: применение¶
Убедитесь, что оператор находится у VM console. Для типового networkd:
networkctl reload
networkctl reconfigure ens3
networkctl status ens3
ip -4 address show dev ens3
ip -4 route
resolvectl status ens3
Если адрес не изменился, возможно, действует старый DHCP lease или выбран другой профиль. Исследуйте journalctl -b -u systemd-networkd и поле Network File, вместо циклического systemctl restart systemd-networkd через SSH.
Контрольная точка Д: проверки по уровням¶
- У интерфейса правильный IPv4 и префикс.
- Default route соответствует согласованному шлюзу.
ip route get <доверенный_IP>показывает ожидаемый интерфейс/источник.resolvectl query <внутренний_FQDN>возвращает согласованный адрес.- Исходящий TCP/HTTPS разрешён iptables OUTPUT, если это требуется роли узла.
- С другого административного компьютера открывается новый SSH-сеанс.
- После контролируемого reboot конфигурация сохраняется.
Одинаково важны отрицательные проверки: недопустимые порты должны оставаться закрыты, а клиент из недоверенного сегмента не должен получать доступ через новые правила.
Восстановление¶
Если SSH недоступен, используйте консоль и восстановите оригинальный профиль по реальному пути из протокола. Если именно новый файл создавался для опыта, удалите только его и верните ранее сохранённые файлы в /etc/systemd/network/. Затем networkctl reload, networkctl reconfigure ens3, проверьте адреса/маршруты. Не удаляйте весь каталог .network, потому что другие интерфейсы, виртуальные мосты или cloud-init могут зависеть от его содержимого.
Результат лаборатории¶
Успех означает не просто ping и не просто зелёный статус networkd: есть правильный IP, маршрут, DNS, новый SSH-сеанс, предусмотренный исходящий трафик и подтверждённый возврат после перезагрузки. Для продакшна полезно сохранить обезличенный diff .network и результаты контрольных команд.
Связанные материалы: статический IP, приоритет профилей, cloud-init, iptables.