Я использую CentOS 7 для всего (кроме Mac, указанного ниже). На хосте установлен VirtualBox 5.1.8. Сеть - 192.168.10.0/24. Нигде нет файрволов.
В этом сценарии все работает, как ожидалось:
Ничего не помечено, хосты и гости могут общаться через любой порт, с любого ip. Сетевой интерфейс на каждом госте является мостом. Здесь жизнь хороша.
Этот сценарий не работает:
Я создал интерфейсы VLAN на хосте и на каждом госте. Мы назовем это eth0.10. Каждый гость продолжает использовать eth0 (потому что использование eth0.10 эффективно удалило его из сети). Сетевой интерфейс на каждом госте является мостом.
Примечание: когда я упоминаю здесь ping, я понимаю, что это всего лишь ICMP, но мои тесты также включали тесты TCP. Для краткости используется ping.
Теперь я могу пинговать гостя (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.
Так что все, кроме хозяина, могут видеть гостей. Гости могут видеть друг друга и всех, но не хозяина. Безумно правда?
Я читал кое-что о Открыть Vswitch но я не знаю, нужно ли мне это. Кажется, я упускаю из виду что-то фундаментальное, но сейчас я проверил работу со многих сторон.
Любые предложения будут ценны!
Мне удалось воспроизвести ваш точный сценарий.
Вот мой тестовый 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:
При подключении виртуальных машин к 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