VirtualBox, VLAN, CentOS 7: гости и хост не могут общаться

1

Я использую CentOS 7 на всем (кроме Mac, отмеченного ниже). Хост имеет VirtualBox 5.1.8. Сеть 192.168.10.0/24. Брандмауэров нет нигде.

В этом сценарии все работает как положено:

Ничего не помечено, хосты и гости могут общаться на любом порту, с любого ip. Сетевой интерфейс на каждом госте соединен мостом. Жизнь здесь хороша.

Этот сценарий терпит неудачу:

Я создал интерфейсы VLAN на хосте и каждом госте. Мы назовем это eth0.10. Каждый гость продолжает использовать eth0 (потому что использование eth0.10 фактически удаляет его из сети). Сетевой интерфейс на каждом госте соединен мостом.

Примечание: когда я упоминаю ping здесь, я понимаю, что это просто ICMP, но мои тесты также включали тесты TCP. Использование пинга для краткости.

Теперь я могу пинговать гостя (192.168.10.5) с гостем (192.168.10.10), но не могу пинговать гостя (.10.5) с хоста (.10.50). Хост (.10.50) для гостя (.10.5 или .10.10) тоже не работает.

Когда я пингую гостя (.10.5 или .10.10) с другой физической системой, Mac / OS X, также в VLAN10 (.10.200), я получаю ответ. Когда я пингую хост (.10.5) на Mac (.10.200), я получаю ответ. Обратное также верно.

Я также запустил Wireshark (анализатор пакетов) на Mac (.10.200). Я использовал фильтр vlan host 192.168.10.5 и я вижу vlan id 10 в пакете! То же самое верно для каждого хоста в vlan 10.

Так что все, кроме хозяина, могут видеть гостей. Гости могут видеть друг друга и всех, кроме хозяина. Сумасшедший, верно?

Я прочитал несколько вещей об Open Vswitch, но я не знаю, нужно ли мне это. Кажется, что я упускаю из виду кое-что фундаментальное здесь, но я проверил работу с многих сторон.

Любые предложения будут ценны!

Zeek
источник
Возможно, вы столкнулись с этим access.redhat.com/solutions/53031 Не могли бы вы опубликовать вывод «ip a l» от хоста и гостей
Дмитрий Заяц
На самом деле то, что вы описываете, очень похоже на интерфейсы macvtap на kvm access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Дмитрий Заяц
А какие у вас настройки физической сети? Чтобы иметь возможность запускать VLAN по сети, порты коммутатора должны быть подключены в режиме транка, а не в режиме доступа. Поэтому, пожалуйста, опишите ваш хост и гость "ip a l", "netstat -rn" и опишите физическую настройку сети.
Дмитрий Заяц

Ответы:

1

Я был в состоянии воспроизвести ваш точный сценарий.
Вот мой тестовый env

 +---------------------------------------------------------+                                +-----------------------------------------+
 |                                                         |                                |                                         |
 |                    Mac OS X El Capitan                  |                                |          Mikrotik router board          |
 |      Host is also setup with vlan0 VLAN ID 20           |                                |                                         |
 |      192.168.10.3                                       |                                |                                         |
 |                                                         |                                |                                         |
 |             Both VMs are bridged to en0                 |en0         Trunk               |  VLAN 20 192.168.10.250                 |
 |            +-----------------------------------------------------------------------------+  VLAN 30 192.168.30.250                 |
 |            |                            |               |            VLANs 20 and 30     |                                         |
 |   +------------------+         +-------------------+    |                                |                                         |
 |   |                  |         |                   |    |                                |                                         |
 |   |    Cent OS 7     |         |    Cent OS 7      |    |                                |                                         |
 |   |    Node 1        |         |    Node 2         |    |                                |                                         |
 |   |                  |         |                   |    |                                |                                         |
 |   |  192.168.10.2    |         |    192.168.10.4   |    |                                +-----------------------------------------+
 |   +------------------+         +-------------------+    |
 |      VLAN 20                          VLAN 20           |
 +---------------------------------------------------------+

Точно то же самое происходит.
Когда обе виртуальные машины соединены с en0:

  1. Они могут пинговать друг друга. 192.168.10.2 <-> 192.168.10.4
  2. Они могут пропинговать VLAN 20 Int 192.168.10.250, которая отправляется на Mikrotik, поэтому они могут подключаться к внешнему миру.
  3. Хост Mac, который также настроен с vlan0 VLAN ID 20 192.168.10.3, может пропинговать Mikrotik
  4. Виртуальные машины не могут пропинговать хост, а хост не может пропинговать виртуальные машины.

При подключении виртуальных машин к vlan0 вместо en0 - они теряют связь с внешним миром (не может пинговать микротик)

Таким образом, похоже, что ситуация действительно очень похожа на способ мостового соединения в KVM с macvtap. Виртуальные машины Macvtap не могут взаимодействовать с хостом, поэтому здесь объясняется проблема https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/App_Macvtap.html

Эта ситуация на самом деле не ошибка - это определенное поведение macvtap. Из-за способа, которым физический Ethernet хоста подключен к мосту macvtap, трафик на этот мост от гостей, который перенаправляется на физический интерфейс, не может быть возвращен обратно в стек IP хоста. Кроме того, трафик из стека IP-адресов хоста, который отправляется на физический интерфейс, не может быть возвращен обратно на мост macvtap для пересылки гостям.

Похоже, что тот же механизм действует с мостовыми VLAN. Я не знаю точно, просто спекулирую здесь.

Изменить: я нашел этот блог из стойки, которая объясняет именно эту проблему http://blog.rackspace.com/vms-vlans-and-bridges-oh-my-part-2

Дмитрий Заяц
источник