Настройка второго IP-адреса для хостов Proxmox VE
Представьте: вы арендовали дополнительный IP у хостинга, письмо пришло, адрес в личном кабинете есть, а что с ним делать дальше — непонятно. Открываете /etc/network/interfaces, видите vmbr0, eno1, какой-то bridge-ports, закрываете и идёте гуглить. Знакомо?
Хорошая новость: Proxmox не требует отдельного физического интерфейса под каждый IP. Всё решается на уровне конфигурации — alias, статический маршрут или macvtap, в зависимости от задачи. Один 10G-порт спокойно тянет несколько публичных адресов, десятки ВМ и управляющий трафик без какого-либо hardware-апгрейда — важно лишь, чтобы само железо соответствовало системным требованиям Proxmox к аппаратной части.
Разберём это по порядку — от простейшего alias до routed-схемы с изоляцией трафика.
Два способа добавить IP на хост
Proxmox строится на Debian (если вы ещё выбираете платформу виртуализации, стоит изучить сравнение популярных гипервизоров), поэтому вся сетевая магия живёт в /etc/network/interfaces. Когда вы добавляете второй IP, у вас два пути: alias и статический маршрут через post-up.
IP alias — старый добрый eno1:0. Ядро видит его как отдельный псевдоинтерфейс, трафик идёт через тот же физический порт. Настройка минимальная:
auto eno1:0
iface eno1:0 inet static
address 1.2.3.4
netmask 255.255.255.255
Routed через post-up — чище и гибче. IP назначается прямо на vmbr0, маршрут добавляется при поднятии интерфейса:
auto vmbr0
iface vmbr0 inet static
address 5.6.7.8
netmask 255.255.255.0
gateway 5.6.7.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
post-up ip addr add 1.2.3.4/32 dev vmbr0
pre-down ip addr del 1.2.3.4/32 dev vmbr0
Почему pre-down обязателен — при перезапуске без него адрес зависает в системе, и ifreload начинает ругаться на дублирующий адрес.
Проверить конфиг без перезагрузки — ifreload -a. Команда перечитывает /etc/network/interfaces и применяет изменения на лету. Для production-сервера это критично: ребут ради смены IP — прошлый век.
После применения убедитесь, что маршруты в порядке: ip route show покажет таблицу маршрутизации, а ip addr show vmbr0 — все адреса на мосту, включая только что добавленные. Если что-то не так, journalctl -u networking -n 50 объяснит причину — обычно это либо синтаксическая ошибка в interfaces, либо конфликт адресов из-за забытого pre-down.
Когда один IP хосту, а остальные — виртуалкам
Типичный сценарий на хостингах вроде Hetzner или FirstVDS: вы покупаете блок дополнительных IP и хотите раздать их по ВМ. Проблема в том, что провайдеры часто фильтруют трафик по MAC-адресу — каждый IP должен выходить с «правильного» мака, иначе пакеты просто не пройдут.
Решение — routed-конфигурация с виртуальным мостом без физических портов. Создаётся vmbr1, который не привязан ни к какому физическому интерфейсу:
auto vmbr1
iface vmbr1 inet static
address 10.10.10.1
netmask 255.255.255.0
bridge-ports none
bridge-stp off
bridge-fd 0
post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
Каждой ВМ, которой нужен публичный IP, добавляется маршрут /32 через хост:
post-up ip route add 1.2.3.4/32 dev vmbr0
pre-down ip route del 1.2.3.4/32 dev vmbr0
Внутри Ubuntu-контейнера или ВМ шлюз прописывается как адрес хоста, а не реальный gateway провайдера. Это и есть суть routed-схемы — хост выступает маршрутизатором.
Для LXC-контейнеров есть нюанс: ip_forward на хосте должен быть включён постоянно, иначе после ребута трафик встанет. Добавьте net.ipv4.ip_forward = 1 в /etc/sysctl.conf и не надейтесь только на post-up.
Ещё один момент с LXC: если контейнер непривилегированный (unprivileged), то сетевые интерфейсы внутри него управляются иначе. Proxmox создаёт пару veth-интерфейсов — один на хосте, один внутри контейнера. Маршруты /32 для таких контейнеров прописываются на хостовом конце veth, а не на vmbr. Это важно, когда вы настраиваете routed-схему: стандартная инструкция для KVM здесь не работает напрямую.
Сравнение методов
Выбор метода зависит от сценария. Вот сравнение трёх подходов — только плюсы, минусы и контекст применения:
| Метод | Преимущества | Недостатки | Когда использовать |
|---|---|---|---|
| IP alias (eno1:0) | Простота, нет лишних зависимостей | ARP-конфликты при /29, устаревший подход | Малые конфигурации, один-два доп. IP |
| Routed /32 (post-up ip route) | Полная изоляция ВМ от хоста, чистая маршрутизация | Требует post-up/pre-down скриптов, ip_forward | Кластеры, публичные IP для ВМ |
| MACVTAP | Высокая производительность, нет overhead моста | Хост не видит ВМ-трафик, нет моста для управления | 10G+ сети, когда производительность критична |
Подводные камни, которые топят новичков
Сетевая конфигурация Proxmox — то место, где одна опечатка может оставить вас с сервером без доступа и с открытым Zoom в поддержку хостинга.
Потеря веб-интерфейса на порту 8006. Если вы меняете адрес vmbr0 и не обновляете /etc/hosts, pveproxy продолжает слушать на старом IP. После ifreload веб-морда пропадает. Лечится так:
# Обновить /etc/hosts
sed -i 's/старый_IP/новый_IP/' /etc/hosts
# Перезапустить прокси
systemctl restart pveproxy
Если уже потеряли доступ — только IPMI или KVM-консоль от хостинга.
ARP-проблемы при /29-подсетях. Когда провайдер выдаёт подсеть /29 с отдельным шлюзом (не из этой подсети — бывает и такое), хост должен выступать роутером для остальных адресов блока. Без post-up с правильными маршрутами пинги с ВМ не проходят — провайдер просто не знает, куда слать ответы. Решение: явный маршрут до шлюза через ip route add в post-up.
MAC-фильтры провайдера. Некоторые хостинги (особенно европейские) жёстко привязывают IP к MAC-адресу виртуального сетевого интерфейса ВМ. Если ВМ создана с автоматическим MAC — трафик не пройдёт. Нужно либо зарегистрировать MAC в панели хостинга, либо выдать ВМ конкретный MAC вручную в настройках Proxmox.
Конфликт с dhcpcd. Если где-то на хосте завёлся DHCP-клиент (бывает после экспериментов), он может перезаписать статический адрес. Проверьте systemctl status dhcpcd и отключите, если найдёте.
Безопасность: не открывайте всё подряд
Второй IP на хосте — это удобство и одновременно расширение поверхности атаки. Несколько практических вещей, которые стоит сделать сразу.
pve-firewall включается через веб-интерфейс и по умолчанию разрешает всё. Для управляющего интерфейса — ограничьте доступ к 8006 по IP через iptables прямо в post-up:
post-up iptables -A INPUT -p tcp --dport 8006 ! -s ваш_управляющий_IP -j DROP
VLAN-изоляция через vmbr с тегами — следующий уровень. Создаёте отдельный мост с bridge-vlan-aware yes, назначаете теги интерфейсам ВМ, и трафик разных сервисов не пересекается даже на одном хосте. Это актуально, когда на одном сервере живут и продакшн, и тестовые окружения.
Мониторинг сетевых интерфейсов через Zabbix: шаблон Linux network interfaces из коробки умеет отслеживать трафик, ошибки и статус каждого vmbr. Добавьте триггер на изменение IP-адреса интерфейса — это поможет поймать момент, когда что-то пошло не так, автоматически.
Кластер: когда нод несколько
В кластере Proxmox каждая нода имеет свою сетевую конфигурацию, и она не синхронизируется автоматически. Если вы добавили второй IP на одной ноде — на остальных это нужно делать руками или через Ansible.
Миграция ВМ между нодами с разными IP-схемами работает, если у ВМ сетевой интерфейс привязан к мосту с тем же именем (vmbr0, vmbr1). Кстати, если вы переносите в кластер физические серверы, полезно разобраться с методами конвертации физических серверов в виртуальные (P2V). Proxmox не мигрирует сетевые настройки хоста — только конфигурацию самой ВМ. Поэтому vmbr1 должен существовать на целевой ноде с аналогичными маршрутами, иначе ВМ после миграции останется без сети.
Corosync — служба кластерного управления — использует отдельный интерфейс для cluster-трафика. Если вы добавляете второй IP и случайно меняете маршрутизацию, Corosync может потерять кворум. Перед любыми изменениями сети в кластере проверьте pvecm status и убедитесь, что все ноды онлайн.
Автоматизация через Ansible: простой шаблон template для /etc/network/interfaces плюс хендлер ifreload -a — и одна команда настраивает сеть на всех нодах одновременно. Для IT-отделов от пяти серверов это экономит часы на однотипных операциях.
Два IP на одном хосте — это не экзотика, а повседневная практика в любом хостинге с посуточной оплатой за адрес. Proxmox даёт все инструменты: alias для простых задач, routed /32 для изоляции ВМ, VLAN для сегментации. Главное — держать конфиг чистым, pre-down не забывать, и перед каждым ifreload иметь запасной способ зайти на сервер. Остальное — детали, которые решаются за один journalctl -u networking.
