Вы получили дополнительные IP, назначили один виртуальной машине (VM), но из интернета она недоступна. Так бывает, когда настройки не соответствуют способу, которым провайдер доставляет адреса на сервер. Для приложений на одном сервере обычно достаточно назначить адреса локально. Для виртуальных машин выбирают подключение через bridge или маршрутизацию — в зависимости от схемы провайдера.
Дополнительный IP — это выделенный адрес. Routed subnet — подсеть, трафик к которой провайдер направляет через указанный сервер или маршрутизатор. Даже один дополнительный адрес /32 может передаваться маршрутизацией. Поэтому сначала выясните способ подключения, затем выбирайте конфигурацию.
Чем отличаются L2 и routed subnet
При подключении на уровне L2 виртуальная машина находится в Ethernet-сегменте провайдера — непосредственно или через VLAN, отдельный логический сегмент сети. Внешний интерфейс хоста и интерфейс VM объединяют сетевым мостом, или bridge. Он работает как виртуальный коммутатор. Шлюз для VM предоставляет провайдер.
Провайдер при этом видит MAC-адрес — адрес сетевого интерфейса VM в Ethernet. Если действует ограничение на разрешённые MAC, потребуется зарегистрировать адрес или использовать выданный виртуальный MAC. Самостоятельно подключить произвольное число VM к внешнему bridge можно только тогда, когда это допускает сеть провайдера.
При routed subnet, то есть маршрутизации на уровне L3, провайдер создаёт маршрут к подсети через определённый next hop — адрес следующего узла. Таким узлом может быть ваш сервер. Он принимает пакеты и передаёт их виртуальным машинам во внутреннюю сеть. На внешнем соединении используется MAC маршрутизатора, а MAC гостевых машин остаются во внутреннем сегменте.
L2: провайдер → внешний bridge → VM
Routed: провайдер → сервер-маршрутизатор → внутренний bridge → VMВ обеих схемах может присутствовать bridge. Разница в том, соединён ли он с внешним сегментом напрямую или находится за маршрутизатором. Совпадение первых цифр IP и название моста vmbr0 сами по себе этого не определяют.
Какую схему выбрать под свою задачу
| Задача | Подходящий вариант | Условия и ограничения |
|---|---|---|
| Несколько адресов для приложений в одной ОС | Назначить дополнительные IP самому серверу по инструкции провайдера. | Routed-блок тоже можно использовать локально. Пересылка пакетов между интерфейсами для этого не требуется, но приложениям нужны правильные привязки к IP. |
| Отдельные публичные IP у VM, провайдер разрешает прямое подключение | L2 bridge. | Нужны корректные шлюзы, VLAN при его использовании и разрешённые MAC. Ограничения провайдера могут сделать этот вариант непригодным. |
| Подсеть для нескольких VM, собственный шлюз и общие правила фильтрации | Routed subnet через хост или отдельный маршрутизатор. | Нужны маршрут у провайдера, маршруты внутри сервера, пересылка IP-пакетов (IP forwarding) и правила межсетевого экрана (firewall). Отказ маршрутизатора затронет весь блок за ним. |
| VM нужны преимущественно исходящие подключения, отдельных публичных адресов не требуется | Частная сеть с преобразованием сетевых адресов (NAT), при необходимости — прокси или перенаправление портов. | Можно обойтись меньшим числом IPv4. Входящие подключения придётся отдельно направлять к нужному приложению. |
Если провайдер уже маршрутизирует блок на основной IP сервера, используйте его как routed-блок. Изменение bridge на хосте не меняет маршрут в сети дата-центра. Переход на другую схему нужно согласовать с провайдером.
Какие параметры получить до настройки
Одного списка адресов недостаточно. В заявке на подключение уточните:
- Способ доставки: подсеть находится в доступном вам L2-сегменте или маршрутизируется через конкретный next hop? Для routed попросите явно указать, через какой IP направлен блок.
- Адреса и шлюзы: какой префикс выделен, сколько адресов разрешено использовать, какие маски назначать интерфейсам, где должен находиться шлюз VM.
- Ограничения подключения: допустимые MAC, необходимость виртуальных MAC или VLAN, разрешена ли отправка пакетов с адресами всего блока через ваш сервер.
- Условия эксплуатации: настройка PTR для обратного DNS, возможность переноса блока на другой сервер, стоимость адресов и подключения.
Полезный запрос в поддержку: «Нужен публичный IPv4 для каждой VM на Linux-гипервизоре. Подтвердите схему доставки блока, next hop или L2-шлюз, допустимые MAC, префиксы интерфейсов и число доступных клиенту адресов».
Не переносите настройки другого дата-центра без проверки. Например, в документации Hetzner для отдельных IP и подсетей описаны разные условия использования виртуальных MAC. Это особенности конкретной сети, а не общее правило для всех хостингов.
Как выглядит routed subnet на одном гипервизоре
Рассмотрим условный пример для IPv4. Все адреса ниже зарезервированы для документации; использовать их на реальном сервере нельзя. Предположим, провайдер подтвердил маршрут 203.0.113.0/29 через основной IP хоста 198.51.100.10.
| Узел или параметр | Значение в примере |
|---|---|
Внешний адрес хоста на eno1 |
198.51.100.10/24 |
| Внешний шлюз хоста | 198.51.100.1 |
| Внутренний bridge хоста | vmbr1, адрес 203.0.113.1/29, без подключения физического внешнего интерфейса |
| Адрес первой VM | 203.0.113.2/29 |
| Шлюз внутри VM | 203.0.113.1 |
Входящий пакет проходит через хост к VM. Ответ VM отправляет своему шлюзу 203.0.113.1, а хост — внешнему шлюзу 198.51.100.1. Это два разных шлюза на разных участках пути.
Адрес 203.0.113.2 назначается VM. Не добавляйте его одновременно как локальный адрес гипервизора: хост может начать принимать предназначенный VM трафик на себя. На хосте нужен маршрут к гостевой сети. В этом примере он появляется при назначении 203.0.113.1/29 внутреннему bridge.
NAT для такой схемы не нужен: VM использует собственный публичный IP. Проверьте, что старое правило MASQUERADE не охватывает этот блок и не подменяет исходящий адрес основным IP хоста. Правила NAT для отдельной частной сети могут продолжать работать.
Почему встречаются /32 и шлюз вне подсети
Размер выделенного блока и префикс адреса на интерфейсе могут различаться. Провайдер может выделить /29, но предложить настраивать отдельные адреса как /32 с маршрутами к ним. В такой схеме шлюз иногда находится вне префикса интерфейса.
Это допустимо, если настроена достижимость шлюза: отдельным маршрутом или параметром вроде on-link: true в Netplan. Возможность такой настройки описана в документации Netplan. Используйте вариант, указанный провайдером. Расширение маски до /24 «чтобы шлюз оказался рядом» может направить трафик не туда.
Routed также не означает, что доступны все адреса блока. В обычном внутреннем сегменте /29 восемь адресов: один обозначает сеть, один используется для широковещательной рассылки, шесть остаются узлам. Если один из шести занимает шлюз, для VM остаются пять. В схеме с /32 расход может быть другим, но допустимость использования крайних адресов нужно подтвердить у провайдера.
Как подготовить изменение без потери доступа
До настройки сохраните рабочие файлы сети и firewall, вывод ip -4 address, ip -4 route и ip rule. Проверьте вход в консоль сервера через панель провайдера: она понадобится, если исчезнет SSH. Начните с одного свободного IP и одной тестовой VM.
Применяйте изменения штатным способом для своей системы. В Proxmox VE с ifupdown2 используйте Apply Configuration в интерфейсе управления. Ручные настройки находятся в /etc/network/interfaces; учитывайте подключаемые файлы и отложенные изменения в /etc/network/interfaces.new.
В Ubuntu с Netplan конфигурация обычно хранится в /etc/netplan/*.yaml. После подготовки файла сначала проверьте его, затем примените в режиме с подтверждением:
sudo netplan generate
sudo netplan try --timeout 120Если первая команда сообщает об ошибке, исправьте её до применения. После второй проверьте новый SSH-сеанс и сеть тестовой VM, затем подтвердите конфигурацию. При потере доступа используйте консоль и восстановите сохранённые настройки. Документация Netplan предупреждает об ограничениях отката, в том числе для виртуальных устройств: после тайм-аута нужно проверить, что рабочая конфигурация действительно восстановилась.
Рабочий адрес управления и маршрут к нему должны сохраниться в итоговой конфигурации. В простой схеме с одним внешним каналом отдельный default route для каждого дополнительного IP не нужен.
Как проверить маршрутизацию и найти место сбоя
Следующие команды предназначены для Linux. В примере хост маршрутизирует подсеть во внутренний bridge vmbr1. Подставьте свои адреса и имена интерфейсов.
Проверьте адреса, маршрут и пересылку пакетов
На гипервизоре выполните:
ip -br -4 address
ip -4 route get 203.0.113.2
sysctl net.ipv4.ip_forwardМаршрут к VM должен указывать на vmbr1. Если вывод содержит local, проверьте, не назначен ли адрес VM самому хосту. Если выбран внешний интерфейс, исправьте маршрут к гостевой сети. Команда ip route get показывает решение ядра, но не отправляет проверочный пакет.
Для хоста, который пересылает IPv4-пакеты, ожидается net.ipv4.ip_forward = 1. Если значение равно 0, сначала подготовьте правила firewall для пересылаемого трафика. Затем на Linux с поддержкой /etc/sysctl.d/ создайте или отредактируйте файл /etc/sysctl.d/90-routed-subnet.conf с записью:
net.ipv4.ip_forward = 1Примените этот файл и повторите проверку значения:
sudo sysctl -p /etc/sysctl.d/90-routed-subnet.conf
sysctl net.ipv4.ip_forwardУчтите, что смена режима ip_forward сбрасывает ряд параметров IPv4 к значениям по умолчанию. Если на хосте уже настроены нестандартные сетевые sysctl, проверьте их после изменения. Для IP, используемых только самим хостом, включать forwarding не нужно.
Внутри VM проверьте ip -4 address и ip -4 route. Для нашего примера нужны адрес 203.0.113.2/29 и маршрут по умолчанию через 203.0.113.1.
Проверьте firewall и реальный сервис
На маршрутизаторе трафик к VM проходит через правила пересылки FORWARD. Разрешение порта только в INPUT, который относится к самому хосту, не открывает этот порт у гостя.
Если используется nftables, посмотреть действующие правила можно командой sudo nft list ruleset. Найдите цепочки с hook forward: разрешён ли нужный поток к адресу и порту VM, проходят ли ответы, нет ли последующего запрещающего правила. Проверьте также firewall гостевой ОС и фильтры в панели провайдера. Изменяйте правила через тот инструмент, который ими управляет.
Проверяйте соединение с другой сети, например с отдельного VPS. Если на VM уже работает HTTPS-сервис на порту 443, а на проверяющем компьютере установлен netcat, проверка TCP-подключения выглядит так:
nc -vz -w 5 203.0.113.2 443Успех означает, что TCP-подключение к этому порту устанавливается. Затем откройте само приложение и проверьте его ответ. Отказ в соединении обычно указывает на отсутствие слушающего сервиса или явный запрет; тайм-аут — на потерю пакетов либо фильтрацию. Один неудачный ping не доказывает неисправность маршрута: ICMP может быть запрещён.
Проследите, где пропадают пакеты
На гипервизоре откройте два терминала. В первом наблюдайте внешний интерфейс, во втором — внутренний bridge, затем повторите внешнее подключение. Внешний IP проверяющего клиента в примере — 192.0.2.50; замените его своим:
sudo tcpdump -ni eno1 'host 192.0.2.50 and tcp port 443'sudo tcpdump -ni vmbr1 'host 203.0.113.2 and tcp port 443'Для остановки захвата используйте Ctrl+C. Сопоставьте направление пакетов:
- Запрос не приходит на внешний интерфейс: проверьте адрес теста, внешние фильтры и маршрут блока у провайдера.
- Запрос приходит снаружи, но не уходит во внутреннюю сеть: проверяйте маршрут к VM, forwarding и firewall хоста.
- Запрос доходит до VM, но ответа нет: проверьте приложение, firewall и обратный маршрут внутри гостевой ОС.
- Ответ VM появляется на внутреннем интерфейсе, но не выходит наружу: проверяйте внешний маршрут хоста, фильтрацию обратного трафика и правила NAT.
При нескольких внешних каналах дополнительно проверьте ip rule и ip -4 route show table all. Строгая проверка обратного пути rp_filter может отбрасывать пакеты при асимметричной маршрутизации. Менять её следует после проверки маршрутов, когда понятна причина отбрасывания.
Отдельно выполните исходящий запрос из VM и посмотрите адрес отправителя в журнале принимающего сервиса. В показанной схеме без NAT там должен быть IP гостя. Основной IP гипервизора вместо него — повод проверить правила подмены адресов.
Проверьте доступ к шлюзу и необходимость proxy ARP
Для L2-подключения после попытки связаться со шлюзом выполните внутри VM ip -4 neigh show. Повторяющиеся состояния INCOMPLETE или FAILED у адреса шлюза означают, что его MAC не удалось определить. Сверьте gateway, VLAN, подключение VM к bridge и разрешённый MAC. Состояние STALE само по себе ошибкой не является.
Proxy ARP позволяет хосту отвечать на ARP-запросы от имени адресов, доступных через него. Это требуется в некоторых схемах подключения. Если провайдер действительно маршрутизирует весь блок через основной IP хоста, включать proxy ARP только из-за наличия подсети обычно не требуется. Уточните, ожидает ли провайдер ARP-ответ для каждого дополнительного IP или только для next hop.
Можно ли перенести подсеть на другой сервер
Routed subnet сама по себе не даёт автоматического переключения на резервный сервер. При переносе VM на другой узел должен сохраниться маршрут к ней: через согласованную внутреннюю сеть либо после изменения маршрутизации у провайдера. Для отказоустойчивости отдельно проектируют резервирование шлюза.
Маршрут к небольшой подсети внутри сети дата-центра также не означает право анонсировать её из другого дата-центра. Это отдельная задача с другими техническими и договорными условиями.
Что сравнить перед заказом
Сравнивайте стоимость по числу реально используемых адресов, добавляя расходы на настройку и обслуживание маршрутизатора. L2 может быть проще при нескольких VM и разрешённых MAC. Routed удобен, когда вы управляете блоком за собственным шлюзом, но требует контроля маршрутов и фильтрации. Ни один вариант сам по себе не увеличивает скорость канала и не делает публичные сервисы закрытыми.
На странице аренды IPv4 в HSTQ отдельно указаны общее число адресов в блоке и ограничения услуг. Например, для /27 заявлены 32 адреса в блоке и 29 клиентских адресов в типовой L2-схеме; для routed число уточняется до заказа. Внешний анонс в таблице услуги предусмотрен для /24 и более крупных блоков; эти условия нельзя автоматически переносить на /27–/25. Перед оплатой согласуйте схему подключения, доступные адреса и параметры для вашей ОС или гипервизора.
