Универсального файла interfaces для любой площадки нет. Один провайдер маршрутизирует блок на основной адрес хоста, другой выдаёт отдельный gateway, третий требует дополнительный MAC для каждого адреса.

Proxmox VE поддерживает bridged, routed и masquerading-схемы. Для публичной подсети часто выбирают routed-вариант: внешняя сеть видит один MAC хоста, а адреса виртуальных машин маршрутизируются через внутренний bridge.

01

Получите схему от оператора

До настройки запросите не только сам префикс. Нужны next hop, маска, основной адрес узла, VLAN и правило привязки маршрута. Отдельно уточните, разрешены ли дополнительные MAC-адреса и работает ли anti-spoofing на порту.

  • публичный адрес и шлюз физического интерфейса;
  • выделенный IPv4-префикс и его фактический next hop;
  • VLAN ID, если сеть выдаётся в отдельном VLAN;
  • разрешённые MAC-адреса и лимиты на их количество;
  • доступный MTU и необходимость proxy ARP.
ДальшеПоймите routed-схему
02

Поймите routed-схему

Физический интерфейс сохраняет основной адрес сервера. Для гостевых адресов создаётся bridge без физического порта, а Linux маршрутизирует пакеты между внешним интерфейсом и этим bridge. Так виртуальные машины не отправляют наружу собственные MAC-адреса.

На узле включают IPv4 forwarding. Proxy ARP нужен не всегда: он зависит от того, как upstream доставляет адреса до хоста. Добавлять его по чужой инструкции без понимания схемы опасно.

Ниже учебный пример, не схема действующей площадки Q-DC. Адреса 192.0.2.0/24 и 198.51.100.0/24 зарезервированы для документации и не используются в интернете. В примере оператор направляет весь гостевой блок на основной IP хоста. Bridge 198.51.100.1/24 служит шлюзом для VM с адресом 198.51.100.10/24.

Оператор
  route 198.51.100.0/24 via 192.0.2.10
       |
Proxmox: основной IP 192.0.2.10
  IPv4 forwarding
       |
vmbr1: 198.51.100.1/24 (без физического порта)
       |
VM: 198.51.100.10/24
  gateway: 198.51.100.1

Proxmox: варианты сетевой конфигурации IANA: адреса TEST-NET

ДальшеНазначьте адреса гостям без конфликта
03

Назначьте адреса гостям без конфликта

Адрес bridge, шлюз виртуальной машины и маска зависят от маршрута провайдера. Иногда гостю назначают адрес с маской /32 и указывают внутренний gateway, иногда используется маска всего блока. Оба варианта встречаются, но смешивать их нельзя.

Оставьте служебные адреса явно отмеченными и ведите IPAM-таблицу: IP, виртуальная машина, MAC, назначение, PTR и дата выдачи. Это особенно важно для /24 и нескольких узлов.

ДальшеУчтите firewall и anti-spoofing
04

Учтите firewall и anti-spoofing

Форвардинг сам по себе не разрешает нужный трафик. Проверьте firewall узла, правила Proxmox, фильтры внутри гостя и reverse path filtering. Слишком строгая проверка обратного пути может мешать асимметричной маршрутизации.

Запретите гостям использовать чужие адреса блока. Для большой подсети нужны фильтры source IP, контроль MAC и журнал изменений, иначе одна ошибочная VM может создать конфликт для всего парка.

ДальшеПродумайте кластер и миграцию
05

Продумайте кластер и миграцию

Если префикс маршрутизируется на один физический сервер, миграция VM на другой узел не перенесёт маршрут автоматически. Нужны изменение next hop, динамическая маршрутизация, общий L2-сегмент или заранее построенная отказоустойчивая схема.

Для BGP уточните, где заканчивается ответственность оператора и начинается конфигурация клиента. Две сессии полезны только тогда, когда проверены оба пути и понятен механизм переключения.

ДальшеПроверьте маршрут до запуска
06

Проверьте маршрут до запуска

Тестируйте входящий и исходящий трафик с нескольких внешних сетей. Проверьте traceroute, MTU, потери, обратный маршрут, перезагрузку узла и повторный запуск сетевых интерфейсов.

Изменение сети по удалённому SSH может лишить доступа. Перед применением подготовьте IPMI/KVM, резервную копию конфигурации и команду автоматического отката.

Эти команды только показывают состояние, не меняя сеть. Запускайте их на своём узле и подставляйте реальные адреса вместо учебных. ip_forward должен быть равен 1; маршрут к гостю должен идти через внутренний bridge, а не через внешний шлюз. Наличие локального маршрута не доказывает, что upstream доставляет префикс: входящий доступ проверьте из внешней сети.

  • адрес гостя доступен извне и выходит с ожидаемого IP;
  • маршрут восстанавливается после перезагрузки;
  • соседняя VM не может использовать чужой адрес;
  • PTR и firewall соответствуют назначению;
  • есть рабочий путь восстановления через IPMI/KVM.
ip -br address
ip -4 route show
sysctl net.ipv4.ip_forward
ip -4 route get 198.51.100.10
ip -4 neigh show dev vmbr1
ДальшеПерейти к вопросам по теме