Вопрос или проблема
Интерфейс, к которому подключены виртуальные машины, на гипервизоре называется vboxnet0. vboxnet0 имеет два IP-адреса: 357.55.323.1/24 и 28.79.49.1/24 (я специально указал нереалистичные IP-адреса), соответственно, имеются виртуальные машины с IP-адресами 357.55.323.0/24 и 28.79.49.0/24. На гипервизоре включено net.ipv4.ip_forward=1. Гипервизор видит виртуальные машины обеих подсетей.
ip rule гипервизора:
90: from all to 28.79.49.0/24 iif vboxnet0 lookup main
90: from all to 357.55.323.0/24 iif vboxnet0 lookup main
200: from 28.79.49.0/24 iif vboxnet0 lookup tbl0
200: from 357.55.323.0/24 iif vboxnet0 lookup tbl1
Примеры сетевых настроек для двух виртуальных машин:
default via 357.55.323.1 dev eth0 onlink
357.55.323.0/24 dev eth0 proto kernel scope link src 357.55.323.51
default via 28.79.49.1 dev eth0 onlink
28.79.49.0/24 dev eth0 proto kernel scope link src 28.79.49.188
Эти две виртуальные машины не могут обмениваться данными друг с другом. Когда я выполняю traceroute, маршрут не проходит дальше шлюза.
traceroute to 28.79.49.188 (28.79.49.188), 30 hops max, 60 byte packets
1 357.55.323.1 0.077 ms 0.057 ms 0.056 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
Когда я выполняю ping 28.79.49.188 с 357.55.323.51, я получаю только:
fastuser@prod:~$ ping 28.79.49.188
PING 28.79.49.188 (28.79.49.188) 56(84) bytes of data.
From 357.55.323.1: icmp_seq=2 Redirect Host(New nexthop: 28.79.49.188)
From 357.55.323.1: icmp_seq=3 Redirect Host(New nexthop: 28.79.49.188)
From 357.55.323.1: icmp_seq=4 Redirect Host(New nexthop: 28.79.49.188)
From 357.55.323.1: icmp_seq=5 Redirect Host(New nexthop: 28.79.49.188)
From 357.55.323.1: icmp_seq=6 Redirect Host(New nexthop: 28.79.49.188)
From 357.55.323.1: icmp_seq=8 Redirect Host(New nexthop: 28.79.49.188)
From 357.55.323.1: icmp_seq=11 Redirect Host(New nexthop: 28.79.49.188)
Во время ping, tcpdump не показывает входящие icmp пакеты от другого хоста, что означает, что они даже не доходят до виртуальной машины (может ли это означать, что гипервизор не отправляет трафик куда-либо?)
Если я явно добавляю статические маршруты на обе виртуальные машины, тогда, конечно, все работает. Но как сделать так, чтобы маршрутизатор-гипервизор отправлял трафик из одной подсети в другую на одном и том же интерфейсе без добавления статических маршрутов на виртуальных машинах?
Ответ или решение
Тема вопроса касается сетевого взаимодействия между подсетями на одном интерфейсе гипервизора, где виртуальные машины оказались неспособными обмениваться данными друг с другом. Рассмотрим, почему это может происходить, и как можно исправить ситуацию, опираясь на предоставленный контекст и технические особенности.
Теория
В сетевой архитектуре, когда несколько подсетей подключены к одному интерфейсу, необходимо корректно настроить маршрутизацию, чтобы пакеты данных могли быть переданы между этими подсетями. В вашем случае оба диапазона IP-адресов, хотя и неправдоподобны, будут использоваться для иллюстративных целей:
- 357.55.323.0/24
- 28.79.49.0/24
Гипервизор видит виртуальные машины из обеих подсетей, и ip_forwarding включён, что должно позволять пересылке пакетов между этими подсетями. Однако, согласно трассировке и пингу, пакеты не достигают конечных хостов, а остается только ICMP сообщение о перенаправлении хоста. Это указывает на проблему с маршрутизацией.
Пример
Ваша текущая настройка ip rule на гипервизоре выглядит следующим образом:
90: from all to 28.79.49.0/24 iif vboxnet0 lookup main
90: from all to 357.55.323.0/24 iif vboxnet0 lookup main
200: from 28.79.49.0/24 iif vboxnet0 lookup tbl0
200: from 357.55.323.0/24 iif vboxnet0 lookup tbl1 Эти правила явно не покрывают логический поток пакетов между подсетями. В результате, когда пакет приходит из одной подсети и должен быть направлен в другую, гипервизор не понимает, куда его отправлять. Такая ситуация приводит к сообщениям о перенаправлении ICMP, которые видите в пинге.
Пинг генерирует ICMP-пакеты, и если их не удается доставить до конечного адресата из другой подсети, это указывает на то, что на гипервизоре отсутствуют маршруты, позволяющие осуществлять маршрутизацию между этими подсетями без настройки явных статических маршрутов на самих виртуальных машинах.
Применение
Для решения проблемы без добавления статических маршрутов на виртуальных машинах, вам необходимо внести изменения в конфигурацию маршрутизации на гипервизоре:
-
Настройка ip rule и ip route: Убедитесь, что в маршрутизационной таблице на гипервизоре добавлены маршруты для обеих подсетей. Вот как это можно сделать:
-
Добавьте правильные маршруты:
ip route add 357.55.323.0/24 dev vboxnet0 ip route add 28.79.49.0/24 dev vboxnet0 -
Настройте ip rule для корректного направления трафика между подсетями:
ip rule add from 357.55.323.0/24 table main ip rule add from 28.79.49.0/24 table main
-
-
Проверка iptables: Убедитесь, что правила iptables не блокируют трафик между подсетями. Вы можете временно отключить правила для проверки:
iptables -F iptables -X -
Логирование и диагностика: Используйте расширенные функции логирования на гипервизоре для идентификации того, где именно происходит сбой маршрутизации. Это может включать в себя расширенный анализ пакетов с помощью tcpdump или iptables с опцией логирования.
-
Проверка ARP настройки: Убедитесь, что на интерфейсе vboxnet0 происходят корректные ARP разрешения для обеих подсетей, чтобы гипервизор мог выявить следующее звено (next-hop).
-
Ограничения или баги в используемом гипервизоре: Убедитесь, что текущая версия вашего гипервизора не имеет известных багов на уровне сетевой маршрутизации. Дополнительная проверка и обновление гипервизора может быть иметь положительный эффект.
Используя эти шаги, возможно, вы настроите гипервизор таким образом, чтобы он корректно маршрутизировал трафик между подсетями на одном интерфейсе без необходимости изменения конфигурации виртуальных машин. Настройка корректного маршрутизатора на гипервизоре возможна, и часто это требует глубокого понимания как работы сетевого стека Linux, так и особенностей вашей среды виртуализации.