Всем привет! Нужна ваша помощь, так как самостоятельное тыкание и гугление ни к чему не привели. Краткое изложение проблемы наглядно продемонстрировано на схеме, а здесь добавлю описание к ней:
1) На картинке схематично изображена виртуальная машина Ubuntu 17.04 в гипервизоре VMWare Workstation Player который крутится на Windows 10.
2) VMWare предоставляет свой NAT сервис доступный по IPv4 192.168.21.2 который раздает Интернет доступный на хосте Windows 10 всем виртуальным машинам в том числе и Ubuntu 17.04
3) С виртуальной машины Ubuntu 17.04 Интернет доступен
4) Также, на этой виртуальной машине (Ubuntu 17.04) запущен Linux-контейнер «test-alpine» под менеджером LXD/LXC.
Проблема заключается в том, что с контейнера «test-alpine» не доступен VMWare'овский NAT, ну и соответственно интернет внутри контейнера не доступен.
Пинги между контейнером «test-alpine» и Ubuntu 17.04 где хостится этот контейнер ходят без проблем, туда и обратно, но вот транзитные пинги с контейнера до NAT не ходят, хотя IPv4 forwarding включен, равняется единичке. Так же таблица маршрутизации на Ubuntu позволяет как бы беспрепятственно идти трафику:
$ ip route
default via 192.168.21.2 dev ens33 proto static metric 100
10.0.3.0/24 dev lxdbr0 proto kernel scope link src 10.0.3.1
169.254.0.0/16 dev ens33 scope link metric 1000
192.168.21.0/24 dev ens33 proto kernel scope link src 192.168.21.141
192.168.21.0/24 dev ens33 proto kernel scope link src 192.168.21.141 metric 100
а также iptables этому не мешает:
$ sudo iptables -L
[sudo] password for dv:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:domain /* generated for LXD network lxdbr0 */
ACCEPT udp -- anywhere anywhere udp dpt:domain /* generated for LXD network lxdbr0 */
ACCEPT udp -- anywhere anywhere udp dpt:bootps /* generated for LXD network lxdbr0 */
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere /* generated for LXD network lxdbr0 */
ACCEPT all -- anywhere anywhere /* generated for LXD network lxdbr0 */
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp spt:domain /* generated for LXD network lxdbr0 */
ACCEPT udp -- anywhere anywhere udp spt:domain /* generated for LXD network lxdbr0 */
ACCEPT udp -- anywhere anywhere udp spt:bootps /* generated for LXD network lxdbr0 */
Сетевые интерфейсы на Ubuntu:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:b1:a2:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.21.141/24 brd 192.168.21.255 scope global dynamic ens33
valid_lft 1644sec preferred_lft 1644sec
inet6 fe80::8b3f:e07b:586b:c8ff/64 scope link
valid_lft forever preferred_lft forever
4: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether fe:c4:a4:54:a4:ed brd ff:ff:ff:ff:ff:ff
inet 10.0.3.1/24 scope global lxdbr0
valid_lft forever preferred_lft forever
inet6 fe80::e8dd:13ff:fea4:b624/64 scope link
valid_lft forever preferred_lft forever
6: veth6YJUNU@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxdbr0 state UP group default qlen 1000
link/ether fe:c4:a4:54:a4:ed brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::fcc4:a4ff:fe54:a4ed/64 scope link
valid_lft forever preferred_lft forever
Бридж lxdbr0:
$ brctl show
bridge name bridge id STP enabled interfaces
lxdbr0 8000.fec4a454a4ed no veth6YJUNU
Сеть LXC. Здесь NAT который предоставляет LXC выключен сознательно, так как не понятно что он делает, хочется разобраться в базовой маршрутизации, почему транзитный трафик не ходит с контейнера до NAT VMWare.
$ lxc network show lxdbr0
config:
ipv4.address: 10.0.3.1/24
ipv4.nat: "false"
ipv6.address: none
name: lxdbr0
type: bridge
used_by:
- /1.0/containers/test-alpine
managed: true
Так же есть другой вопрос по теме, это не могу понять вообще смысл сетевого моста который требует LXD и не до конца понятен его механизм работы. Бридж это как я понял из интернетов маленький свитч работающий на канальном уровне сетевой модели OSI. Если смотреть в информацию бриджа через утилиту brctl, то там я обнаруживаю подключение только veth адаптера хоста, но не eth0 контейнера, однако каким то магическим способом контейнер соединяется с хостом. Если смотреть через настройки LXC то там информация отражается, что контейнер присоединен к мосту, но почему это не видно через утилиту brctl? Для чего вообще LXD требует сетевой мост, разве не достаточно виртуальной карты (veth) на хосте (Ubuntu) которые он все равно создает для каждого контейнера? Разве не достаточно такой схемы и почему?
veth2 (хост) 10.0.3.2/24 <---> eth0 (контейнер1) 10.0.3.101/24
veth3 (хост) 10.0.3.3/24 <---> eth0 (контейнер2) 10.0.3.102/24
Сейчас схематично это вот как то так:
br0 (хост) 10.0.3.1/24 (сюда "воткнуты" veth2, veth3)
veth2 (хост) 0.0.0.0 <---> eth0 (контейнер1) 10.0.3.101/24
veth3 (хост) 0.0.0.0 <---> eth0 (контейнер2) 10.0.3.102/24
Вообщем, буду благодарен за любую информацию которая приведет к просветлению :)
