Наконец-то решил. Вот как. Извините за этот очень длинный пост, но я потратил на это много времени и думаю, что некоторые люди могут быть заинтересованы в подробном решении.

Установка

+---------------------------------------------------------------------------------------------+
|HOST                                                                                         |
|                                                                                             |
| +-------------------------------------------------+                                         |
| | UBUNTU-VM                                       |                                         |
| |                                                 |                                         |
| | +-------------------+                           |                                         |
| | |UBUNTU-LXC         |                           |                   +------------------+  |
| | |       10.0.0.3/24 |  10.0.0.1/24              |                   |OTHER VM          |  |
| | |               eth0-----lxcbr0----------eth0-----------br0----------eth0              |  |
| | |                   |           192.168.100.2/24|  192.168.100.1/24 |192.168.100.3/24  |  |
| | +-------------------+                           |                   +------------------+  |
| +-------------------------------------------------+                                         |
+---------------------------------------------------------------------------------------------+

1. Удаление NAT на UBUNTU-VM

Причина, по которой мои пакеты выходят из UBUNTU-VM с 192.168.100.2 , связана с правилом по умолчанию iptables , которое создается при запуске моего container:

root@UBUNTU-VM# iptables -nL -t nat     
Chain PREROUTING (policy ACCEPT)                    
target     prot opt source               destination

Chain INPUT (policy ACCEPT)                         
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)                        
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)                   
target     prot opt source               destination
MASQUERADE  all  --  10.0.3.0/24         !10.0.3.0/24 

Это правило в основном говорит: «Если пакет из подсети 10.0.3.0/24 , а пункт назначения находится в другой подсети, измените IP-адрес источника». Поэтому, если я удалю это правило, я смогу пинговать извне, используя IP-адрес моего контейнера. Давайте удалим это правило:

root@UBUNTU-VM# iptables -D POSTROUTING 1 -t nat

Теперь, если я пингую 192.168.100.1 из моего контейнера LXC ( 10.0.3.233 ), произойдет следующее: Однако br0 , похоже, не может ответить.

2. Добавление маршрута по умолчанию на HOST

root@HOST# ip route add 10.0.0.0/8 via 192.168.100.2

Теперь шлюз по умолчанию для подсети 10.0.0.0/8 - eth0 на UBUNTU-VM. Попробуем пинг:

root@HOST# tcpdump -i br0 -n
14:14:33.885982 IP 10.0.3.233 > 192.168.100.1: ICMP echo request, id 660, seq 14, length 64
14:14:34.884054 ARP, Request who-has 10.0.3.233 tell 192.168.100.1, length 28

По-прежнему не работает. К сожалению, у меня нет объяснения этому. И что еще хуже, почему br0 делает ARP-запрос для IP-адреса, даже не входящего в его подсеть? По крайней мере, я ожидал, что запрос ICMP будет незаметно проигнорирован, но отвечать запросом ARP просто странно.

3. Настройка libvirt

3.1. Текущая конфигурация

br0 - это мост, который я настроил на хосте вручную с помощью netctl . В моем шаблоне UBUNTU-VM у меня есть следующее:

<interface type='bridge'>                                                    
   <mac address='52:54:00:cb:aa:74'/>                                         
   <source bridge='br0'/>                                                     
   <model type='e1000'/>                                                      
   <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</interface>     

Когда создается UBUNTU-VM, kvm (или libvirt ?) Создает пару veth и присоединяет их к мосту.

root@HOST# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.fe0000000001       no              vnet1
                                                        vnet2

По какой-то причине это не работает (изменения / комментарии приветствуются)

Решением было настроить маршрутизируемую сеть вместо простой мостовой сети .

3.2. Определение сети

Создайте XML-шаблон для своей сети:

<network>                                                       
  <name>vms</name>                                              
  <uuid>f3e18be1-41fe-4f34-87b4-f279f4a02254</uuid>             
  <forward mode='route'/>                                       
  <bridge name='br0' stp='on' delay='0'/>                       
  <mac address='52:54:00:86:f3:04'/>                            
  <ip address='192.168.100.1' netmask='255.255.255.0'>          
  </ip>                                                         
  <route address='10.0.0.0' prefix='8' gateway='192.168.100.2'/>
</network>                                                      

Обратите внимание на раздел маршрута по умолчанию. Затем загрузите его и запустите

virsh # define vms.xml
virsh # net-start vms

3.3. Отредактируйте виртуальную машину

Интерфейс должен выглядеть следующим образом:

<interface type='network'>                                                   
  <mac address='52:54:00:cb:aa:74'/>                                         
  <source network='vms'/>                                                    
  <model type='e1000'/>                                                      
  <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</interface>                                                                 

Final test

После перезапуска виртуальной машины и контейнера я наконец могу выполнить эхо-запрос br0 , используя IP-адрес контейнера LXC:

root@HOST# tcpdump -i br0 -n
14:24:00.349856 IP 10.0.3.233 > 192.168.100.1: ICMP echo request, id 468, seq 16, length 64
14:24:00.349900 IP 192.168.100.1 > 10.0.3.233: ICMP echo reply, id 468, seq 16, length 64

Остающиеся вопросы

• Почему этот ARP запрашивает в 2. ?
• Почему моя установка не работает, если я не позволю libvirt обрабатывать мост и саму маршрутизацию? Моя ручная настройка (создание моста с помощью netctl и добавление маршрута по умолчанию с помощью ip route add ) очень похожа на то, что делает libvirt: мост с двумя подключенными к нему интерфейсами vnet , и маршрут по умолчанию ... Может, libvirt творит здесь какую-то черную магию?
• Смогу ли я масштабировать количество контейнеров с помощью этой настройки (это моя конечная цель).

Источники, которые помогли

• сетевой документ libvirt
• Я отредактирую и добавлю другие ссылки, когда у меня будет достаточно репутации (требуется 10 ...)