Виртуальный роутер в Neutron - это ключевой компонент, обеспечивающий связь изолированных облачных сетей с внешним миром. Без него виртуальные машины внутри проекта остаются полностью отрезанными от интернета и других сетей. Этот материал содержит проверенные на практике команды и сценарии для создания, настройки и диагностики роутеров, управления плавающими IP-адресами и правилами NAT. Вы получите готовую последовательность действий для организации сетевой связности в частном облаке OpenStack.
Мы разберем полный цикл: от подготовки подсетей до сложных сценариев межпроектной маршрутизации. Все примеры проверены на актуальных версиях OpenStack и сопровождаются командами для CLI и пояснениями для Horizon. Если вам нужны смежные темы по виртуализации сети, обратите внимание на руководство по маршрутизации в VMware NSX и Hyper-V SDN.
Зачем нужны виртуальные роутеры в Neutron
Сети проекта (tenant networks) в OpenStack по умолчанию полностью изолированы. Виртуальные машины внутри одной сети видят друг друга, но не имеют доступа к интернету и не могут общаться с ВМ в других сетях или проектах. Виртуальный роутер снимает это ограничение. Он выполняет три критически важные функции: маршрутизацию пакетов между подсетями, трансляцию сетевых адресов (Source NAT) для исходящего трафика и Destination NAT для входящих соединений через плавающие IP.
Архитектура связности выглядит так: виртуальные машины подключаются к изолированной сети проекта, эта сеть через интерфейс подключается к роутеру, а роутер своим внешним шлюзом выходит во внешнюю сеть (external network). Внешняя сеть - это мост в физическую инфраструктуру или интернет. Плавающий IP (floating IP) - это адрес из пула внешней сети, который роутер транслирует на фиксированный внутренний адрес конкретной ВМ. Такая схема обеспечивает контролируемый доступ извне к нужным сервисам, сохраняя изоляцию остальных машин.
Подготовка окружения: сети и подсети
Перед созданием роутера необходимо подготовить две сущности: изолированную сеть проекта и внешнюю сеть с пулом плавающих адресов. Ошибки на этом этапе - самая частая причина неработающей маршрутизации. Проверьте, что внешняя сеть уже существует и имеет атрибут --external. Если вы администратор облака и настраиваете его с нуля, начните с внешней сети.
Создание изолированной сети проекта
Изолированная сеть создается внутри проекта и не имеет прямого выхода наружу. Для нее обязательно нужно определить подсеть с CIDR, шлюзом по умолчанию и включенным DHCP. Команды выполняются от пользователя проекта.
# Создаем приватную сеть
openstack network create --internal private-net
# Создаем подсеть с диапазоном адресов
openstack subnet create --network private-net \
--subnet-range 192.168.100.0/24 \
--gateway 192.168.100.1 \
--dns-nameserver 8.8.8.8 \
--dhcp private-subnet
# Проверяем результат
openstack network list
openstack subnet listПосле выполнения этих команд виртуальные машины, подключенные к сети private-net, будут получать IP из диапазона 192.168.100.0/24 через DHCP. Шлюз 192.168.100.1 станет активным после подключения сети к роутеру - именно этот адрес Neutron назначит на интерфейс роутера в данной подсети.
Настройка внешней сети и пула плавающих адресов
Внешнюю сеть создает администратор облака. Она использует физический тип сети - flat или vlan - и содержит диапазон адресов, маршрутизируемых в физической инфраструктуре. Именно из этого диапазона будут выделяться плавающие IP.
# Администратор создает внешнюю сеть (тип flat)
openstack network create --external \
--provider-network-type flat \
--provider-physical-network physnet1 \
public-net
# Добавляем подсеть с пулом плавающих адресов
openstack subnet create --network public-net \
--subnet-range 203.0.113.0/24 \
--gateway 203.0.113.1 \
--allocation-pool start=203.0.113.100,end=203.0.113.200 \
--no-dhcp \
public-subnetКлючевой момент: для внешней подсети DHCP отключен флагом --no-dhcp. Адреса из пула 203.0.113.100-200 будут назначаться только через API Neutron как floating IP. Шлюз 203.0.113.1 должен существовать в физической сети и обеспечивать выход в интернет.
Создание и базовая настройка виртуального роутера
Роутер создается одной командой, после чего его нужно подключить к внешней сети и к приватной подсети. Порядок действий важен: сначала назначается внешний шлюз, затем добавляются интерфейсы внутренних сетей.
Создание роутера и подключение внешнего шлюза
Создаем роутер и сразу назначаем ему внешний шлюз. В момент назначения шлюза Neutron автоматически включает Source NAT для всех подключенных приватных подсетей - виртуальные машины смогут выходить в интернет через внешний IP роутера.
# Создаем роутер
openstack router create project-router
# Назначаем внешний шлюз
openstack router set --external-gateway public-net project-router
# Проверяем статус и внешний IP роутера
openstack router show project-router -c external_gateway_infoВ выводе команды show вы увидите IP-адрес, который роутер получил на внешнем интерфейсе из пула внешней сети. Если пул не был задан явно, Neutron возьмет любой свободный адрес из подсети. Запомните этот адрес - через него пойдет весь исходящий SNAT-трафик.
Подключение интерфейса к приватной сети
Теперь связываем роутер с внутренней подсетью. После этой операции виртуальные машины в сети private-net получат маршрут по умолчанию через роутер.
# Добавляем интерфейс роутера в приватную подсеть
openstack router add subnet project-router private-subnet
# Проверяем порты роутера
openstack port list --router project-routerNeutron автоматически создаст порт в приватной сети с IP-адресом, который вы указали как шлюз при создании подсети (192.168.100.1). На виртуальной машине, подключенной к этой сети, проверьте таблицу маршрутизации:
ip route
default via 192.168.100.1 dev eth0Маршрут по умолчанию указывает на интерфейс роутера. Если ВМ получила IP по DHCP, но маршрута нет - проверьте, что опция --gateway была задана при создании подсети.
Управление плавающими IP-адресами (Floating IP)
Плавающий IP - это публичный адрес из внешней сети, который ставится в соответствие внутреннему фиксированному IP виртуальной машины. Роутер выполняет трансляцию Destination NAT: все пакеты, приходящие на floating IP, перенаправляются на приватный адрес ВМ. Это основной механизм публикации сервисов в облаке.
Создание и привязка floating IP к инстансу
Создаем плавающий адрес из внешней сети и привязываем его к порту виртуальной машины. Порт должен принадлежать сети, подключенной к роутеру с внешним шлюзом.
# Создаем floating IP
openstack floating ip create public-net
# Находим порт виртуальной машины
openstack port list --server my-vm
# Привязываем floating IP к порту
openstack floating ip set --port <port-id> <floating-ip>
# Проверяем привязку
openstack floating ip listПосле привязки проверьте доступность ВМ с внешнего хоста командой ping <floating-ip>. Если пинг не проходит, последовательно проверьте: назначен ли роутеру внешний шлюз, разрешает ли security group входящий ICMP-трафик, включен ли на ВМ файрвол (iptables, ufw).
Настройка Destination NAT через floating IP
DNAT работает на уровне роутера Neutron. Когда внешний клиент отправляет пакет на floating IP 203.0.113.150, роутер проверяет свою таблицу трансляций и подменяет адрес назначения на фиксированный IP ВМ, например 192.168.100.10. Обратный трафик проходит через SNAT или через тот же floating IP - в зависимости от настроек.
Важный нюанс: security groups применяются к порту виртуальной машины до DNAT. Это значит, что правило должно разрешать трафик на фиксированный IP ВМ, а не на floating IP. Если вы открыли порт 80 для floating-адреса в security group, но не указали правильный внутренний IP - трафик будет заблокирован.
Работа с NAT: SNAT и межпроектная маршрутизация
Трансляция сетевых адресов - базовая функция роутера Neutron. Понимание того, как работает SNAT и как организовать связь между проектами, позволяет строить сложные сетевые топологии без потери управляемости.
Как работает SNAT на роутере Neutron
Source NAT включается автоматически при назначении роутеру внешнего шлюза. Все пакеты от виртуальных машин, идущие во внешнюю сеть, проходят через правило SNAT: исходный адрес (192.168.100.10) подменяется на внешний IP роутера (203.0.113.5). Для внешнего мира весь исходящий трафик проекта выглядит как трафик с одного адреса.
Проверить работу SNAT можно из namespace роутера. Найдите его идентификатор и загляните в правила iptables:
# Список всех network namespace
ip netns list
# Ищем namespace роутера (содержит ID роутера в имени)
ip netns | grep qrouter
# Смотрим правила NAT внутри namespace
ip netns exec qrouter-<id> iptables -t nat -L -n -vВ цепочке POSTROUTING вы увидите правило MASQUERADE для исходящего трафика из приватных подсетей. Отключить SNAT можно только удалением внешнего шлюза - Neutron не предоставляет опции выборочного отключения SNAT для отдельных подсетей через CLI. Если вам нужен такой уровень контроля, используйте DVR или ручную настройку правил через API.
Сценарий: связь между изолированными проектами
Два разных проекта по умолчанию полностью изолированы. Чтобы виртуальные машины из проекта A могли общаться с ВМ из проекта B без выхода в интернет, используйте shared network - сеть, доступную нескольким проектам.
# Администратор создает общую сеть
openstack network create --share shared-net
openstack subnet create --network shared-net \
--subnet-range 10.0.0.0/24 shared-subnet
# В каждом проекте подключаем интерфейс роутера к общей подсети
openstack router add subnet router-project-a shared-subnet
openstack router add subnet router-project-b shared-subnetПосле этого ВМ в обоих проектах смогут общаться через общую сеть. Маршрутизация между ними работает на уровне роутеров без SNAT - трафик остается в пределах облака. Ограничение: security groups по-прежнему применяются, поэтому не забудьте разрешить нужные порты для диапазона адресов общей сети.
Для более сложных сценариев маршрутизации в ЦОД обратитесь к руководству по Cisco Nexus и VRF, где разобрана логическая изоляция на уровне оборудования.
Типовые архитектуры и лучшие практики
Выбор архитектуры роутеров зависит от масштаба облака, требований к отказоустойчивости и нагрузки на сетевые узлы. Рассмотрим три проверенных шаблона.
Один роутер на проект: простота и контроль
Самый распространенный сценарий для небольших и средних облаков. Все приватные сети проекта подключаются к одному роутеру, который выполняет функции шлюза и NAT. Плюсы очевидны: минимум объектов для управления, предсказуемое поведение, простая диагностика. Минус - единая точка отказа. Если сетевой узел, на котором работает роутер, выходит из строя, весь проект теряет связность.
Для повышения отказоустойчивости настройте VRRP между двумя роутерами, размещенными на разных сетевых узлах. Neutron поддерживает L3 High Availability через отдельный агент. Включите HA при создании роутера:
openstack router create --ha project-router-haРоутер в режиме HA автоматически создает резервную копию на другом узле и синхронизирует состояние через VRRP. Переключение при отказе занимает несколько секунд.
Распределенный виртуальный роутер (DVR)
DVR (Distributed Virtual Router) решает проблему узкого горлышка на сетевом узле. В классической схеме весь трафик между ВМ и внешней сетью проходит через один физический сервер - сетевой узел. При высокой нагрузке это приводит к деградации производительности. DVR выносит маршрутизацию на compute-узлы: каждый гипервизор выполняет SNAT и DNAT локально для своих виртуальных машин.
Настройка DVR требует установки агента L3 в режиме DVR на compute-узлах и отдельного централизованного SNAT-узла для исходящего трафика. Включается DVR глобально в конфигурации Neutron:
# /etc/neutron/neutron.conf
[DEFAULT]
router_distributed = TrueИспользуйте DVR в высоконагруженных средах с интенсивным east-west трафиком. Для небольших инсталляций дополнительная сложность настройки не оправдана.
Диагностика и решение типичных проблем
Проблемы с маршрутизацией в Neutron диагностируются послойно: от порта ВМ до внешнего шлюза роутера. Приведенные ниже инструменты покрывают 90% типовых ситуаций.
Проверка связности через namespace роутера
Namespace роутера - это изолированное сетевое окружение Linux, в котором работают интерфейсы и правила iptables конкретного роутера. Прямая работа с namespace дает доступ к низкоуровневой диагностике.
# Находим ID роутера
openstack router list
# Находим соответствующий namespace (на сетевом узле)
ip netns list | grep <router-id>
# Проверяем интерфейсы внутри namespace
ip netns exec qrouter-<id> ip addr
# Проверяем таблицу маршрутизации
ip netns exec qrouter-<id> ip route
# Пингуем внешний мир из namespace роутера
ip netns exec qrouter-<id> ping 8.8.8.8
# Захватываем трафик на внешнем интерфейсе
ip netns exec qrouter-<id> tcpdump -i qg-<port-id> -nЕсли ping из namespace роутера до 8.8.8.8 проходит, но ВМ не имеет доступа в интернет - проблема на уровне SNAT или security groups. Если ping не проходит из namespace - проверьте физическую связность внешней сети и правильность шлюза 203.0.113.1.
Частые ошибки при настройке floating IP
Собранные на практике проблемы и способы их решения:
- Не назначен внешний шлюз роутеру. Floating IP создается, но не может быть привязан к порту. Решение:
openstack router set --external-gateway public-net project-router. - Floating IP создан, но не привязан к порту. Адрес висит в статусе DOWN. Решение:
openstack floating ip set --port <port-id> <floating-ip>. - Security group запрещает входящий трафик. Пакет доходит до роутера, DNAT отрабатывает, но на порту ВМ пакет отбрасывается. Решение: добавьте правило в security group, разрешающее нужный протокол и порт с source 0.0.0.0/0.
- Конфликт IP-адресов. Две ВМ получили одинаковый floating IP из-за ошибки в скрипте автоматизации. Решение:
openstack floating ip listдля поиска дубликатов и ручное освобождение. - Неверный шлюз в приватной подсети. При создании подсети указан шлюз, не совпадающий с адресом интерфейса роутера. Решение: проверьте
openstack subnet show private-subnet -c gateway_ipи сравните с IP порта роутера в этой подсети.
Для углубленной диагностики сетевых проблем на уровне протоколов маршрутизации используйте инструменты диагностики OSPF и BGP - методика анализа логов и захвата трафика применима и к виртуальным роутерам Neutron.
Если вы разворачиваете тестовое окружение для практики, облачные серверы Timeweb Cloud позволяют быстро поднять выделенный хост с OpenStack и отработать все сценарии без риска для production-среды. Для автоматизации рутинных операций с конфигурациями можно подключить API нейросетей через AiTunnel - это ускоряет генерацию скриптов и шаблонов сетевых конфигураций.