Соединение контейнеров LXC для размещения eth0, чтобы они могли иметь публичный IP

8

ОБНОВИТЬ:

Я нашел решение там: http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#No_traffic_gets_trough_.28except_ARP_and_STP.29

 # cd /proc/sys/net/bridge
 # ls
 bridge-nf-call-arptables  bridge-nf-call-iptables
 bridge-nf-call-ip6tables  bridge-nf-filter-vlan-tagged
 # for f in bridge-nf-*; do echo 0 > $f; done

Но я хотел бы получить экспертное мнение по этому вопросу: безопасно ли отключить все bridge-nf- *? Для чего они здесь?

КОНЕЦ ОБНОВЛЕНИЯ

Мне нужно соединить контейнеры LXC с физическим интерфейсом (eth0) моего хоста, читая многочисленные учебные пособия, документы и сообщения в блогах на эту тему.

Мне нужно, чтобы контейнеры имели собственный публичный IP-адрес (который я ранее делал KVM / libvirt).

После двух дней поиска и попытки я все еще не могу заставить его работать с контейнерами LXC.

На хосте установлен только что установленный Ubuntu Server Quantal (12.10) с только libvirt (который я здесь не использую) и установленным lxc.

Я создал контейнеры с:

lxc-create -t ubuntu -n mycontainer

Поэтому они также запускают Ubuntu 12.10.

Содержимое / var / lib / lxc / mycontainer / config:


lxc.utsname = mycontainer
lxc.mount = /var/lib/lxc/test/fstab
lxc.rootfs = /var/lib/lxc/test/rootfs


lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.veth.pair = vethmycontainer
lxc.network.ipv4 = 179.43.46.233
lxc.network.hwaddr= 02:00:00:86:5b:11

lxc.devttydir = lxc
lxc.tty = 4
lxc.pts = 1024
lxc.arch = amd64
lxc.cap.drop = sys_module mac_admin mac_override
lxc.pivotdir = lxc_putold

# uncomment the next line to run the container unconfined:
#lxc.aa_profile = unconfined

lxc.cgroup.devices.deny = a
# Allow any mknod (but not using the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
#lxc.cgroup.devices.allow = c 4:0 rwm
#lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm
#fuse
lxc.cgroup.devices.allow = c 10:229 rwm
#tun
lxc.cgroup.devices.allow = c 10:200 rwm
#full
lxc.cgroup.devices.allow = c 1:7 rwm
#hpet
lxc.cgroup.devices.allow = c 10:228 rwm
#kvm
lxc.cgroup.devices.allow = c 10:232 rwm

Затем я изменил свой хост / etc / network / interfaces на:


auto lo
iface lo inet loopback

auto br0
iface br0 inet static
        bridge_ports eth0
        bridge_fd 0
        address 92.281.86.226
        netmask 255.255.255.0
        network 92.281.86.0
        broadcast 92.281.86.255
        gateway 92.281.86.254
        dns-nameservers 213.186.33.99
        dns-search ovh.net

Когда я пытаюсь настроить конфигурацию командной строки ("brctl addif", "ifconfig eth0" и т. Д.), Мой удаленный хост становится недоступным, и мне приходится его сильно перезагружать.

Я изменил содержимое / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces на:


auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 179.43.46.233
        netmask 255.255.255.255
        broadcast 178.33.40.233
        gateway 92.281.86.254

Запуск mycontainer занимает несколько минут (lxc-start -n mycontainer).

Я пытался заменить 

        gateway 92.281.86.254
по :

        post-up route add 92.281.86.254 dev eth0
        post-up route add default gw 92.281.86.254
        post-down route del 92.281.86.254 dev eth0
        post-down route del default gw 92.281.86.254

Мой контейнер запускается мгновенно.

Но какую бы конфигурацию я ни установил в / var / lib / lxc / mycontainer / rootfs / etc / network / interfaces, я не могу пропинговать mycontainer по любому IP (включая хост):


ubuntu@mycontainer:~$ ping 92.281.86.226 
PING 92.281.86.226 (92.281.86.226) 56(84) bytes of data.
^C
--- 92.281.86.226 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5031ms

И мой хост не может пропинговать контейнер:


root@host:~# ping 179.43.46.233
PING 179.43.46.233 (179.43.46.233) 56(84) bytes of data.
^C
--- 179.43.46.233 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

Ifconfig моего контейнера:


ubuntu@mycontainer:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 02:00:00:86:5b:11  
          inet addr:179.43.46.233  Bcast:255.255.255.255  Mask:0.0.0.0
          inet6 addr: fe80::ff:fe79:5a31/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:64 errors:0 dropped:6 overruns:0 frame:0
          TX packets:54 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4070 (4.0 KB)  TX bytes:4168 (4.1 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:32 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2496 (2.4 KB)  TX bytes:2496 (2.4 KB)

Ifconfig моего хоста:


root@host:~# ifconfig
br0       Link encap:Ethernet  HWaddr 4c:72:b9:43:65:2b  
          inet addr:92.281.86.226  Bcast:91.121.67.255  Mask:255.255.255.0
          inet6 addr: fe80::4e72:b9ff:fe43:652b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1453 errors:0 dropped:18 overruns:0 frame:0
          TX packets:1630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:145125 (145.1 KB)  TX bytes:299943 (299.9 KB)

eth0      Link encap:Ethernet  HWaddr 4c:72:b9:43:65:2b  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3178 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1637 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:298263 (298.2 KB)  TX bytes:309167 (309.1 KB)
          Interrupt:20 Memory:fe500000-fe520000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:300 (300.0 B)  TX bytes:300 (300.0 B)

vethtest  Link encap:Ethernet  HWaddr fe:0d:7f:3e:70:88  
          inet6 addr: fe80::fc0d:7fff:fe3e:7088/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:54 errors:0 dropped:0 overruns:0 frame:0
          TX packets:67 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4168 (4.1 KB)  TX bytes:4250 (4.2 KB)

virbr0    Link encap:Ethernet  HWaddr de:49:c5:66:cf:84  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Я отключил lxcbr0 (USE_LXC_BRIDGE = "false" в / etc / default / lxc).


root@host:~# brctl show
bridge name     bridge id               STP enabled     interfaces                                                                                                 
br0             8000.4c72b943652b       no              eth0                                                                                                       
                                                        vethtest

Я настроил IP 179.43.46.233, чтобы он указывал на 02: 00: 00: 86: 5b: 11 на панели конфигурации моего хостинг-провайдера (OVH).
(IP-адреса в этом посте не являются реальными.)

Спасибо за чтение этого длинного вопроса! :-)

Vianney

networking  iptables  bridge  lxc 
— Вианни Штробель
источник

Ответы:

6

Лучший способ сделать ваше изменение постоянным - использовать sysctl вместо прямой записи в / proc, поскольку это стандартный способ настройки параметров ядра во время выполнения, чтобы они были правильно установлены при следующей загрузке:

# cat >> /etc/sysctl.d/99-bridge-nf-dont-pass.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
EOF
# service procps start

Что касается ответа на вопрос в вашем обновлении ...

bridge-netfilter (или bridge-nf) - это очень простой мост для пакетов IPv4 / IPv6 / ARP (даже в заголовках VLAN или PPPoE 802.1Q), который обеспечивает функциональность для прозрачного межсетевого экрана с сохранением состояния, но более продвинутая функциональность, такая как прозрачный IP NAT, обеспечивается передачей этих пакетов в arptables / iptables для дальнейшей обработки, однако, даже если более сложные функции arptables / iptables не нужны, передача пакетов в эти программы по-прежнему включена по умолчанию в модуле ядра и должна быть явно отключена используя sysctl.

Для чего они здесь? Эти параметры конфигурации ядра здесь для передачи (1) или не передачи (0) пакетов в arptables / iptables, как описано в FAQ по bridge-nf :

As of kernel version 2.6.1, there are three sysctl entries for bridge-nf behavioral control (they can be found under /proc/sys/net/bridge/):
bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables.

Безопасно ли отключать все bridge-nf- *? Да, это не только безопасно, но и для дистрибутивов рекомендуется отключить его по умолчанию, чтобы помочь людям избежать путаницы в отношении проблемы, с которой вы столкнулись:

На практике это может привести к серьезной путанице, когда кто-то создает мост и обнаруживает, что часть трафика не пересылается через мост. Поскольку правила брандмауэра IP применяются к фреймам моста так неожиданно, что может потребоваться некоторое время, чтобы выяснить, что происходит.

и для повышения безопасности :

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

Когда conntrack работает как часть моста, трафик теперь может пересекаться, что является серьезной дырой в безопасности.

ОБНОВЛЕНИЕ: май 2015

Если у вас ядро ​​старше 3.18, то вы можете использовать старое поведение мостовой фильтрации, включенное по умолчанию; если вы новее 3.18, то вы все равно можете быть укушены этим, если вы загрузили модуль моста и не отключили фильтрацию моста. Видеть:

https://bugzilla.redhat.com/show_bug.cgi?id=634736#c44

После всех этих лет запросов на «отключенную» фильтрацию по умолчанию для моста и отказ от поддержки, сопровождающей ядро, теперь фильтрация перемещена в отдельный модуль, который не загружается (по умолчанию), когда модуль моста загружен, эффективно делает по умолчанию "отключен". Ура!

Я думаю, что это в ядре по состоянию на 3.17 (это определенно в ядре 3.18.7-200.fc21, и, кажется, находится в git до тега "v3.17-rc4")

— aculich
источник
0

У меня аналогичная установка на гипервизоре Debian Wheezy. Мне не нужно было изменять / etc / network / interfaces внутри rootfs контейнера; достаточно настроить lxc.network. * в конфигурации LXC.

Вы должны быть в состоянии обеспечить работу моста независимо от того, используете ли вы контейнер или нет. У меня есть следующие настройки, настроенные в br0 в / etc / network / interfaces на хосте:

% grep bridge /etc/network/interfaces
  bridge_ports eth0
  bridge_fd 0
  bridge_stp off
  bridge_waitport 0
  bridge_maxwait 0

После настройки этого и перемещения конфигурации моего IP-адреса с eth0 на br0 sudo service networking restartпрозрачно перенастроил интерфейсы на моей хост-машине, не прерывая сеанс SSH.

Как только это будет сделано, попробуйте удалить конфигурацию 'eth0' из / etc / network / interfaces и перезапустить ваш контейнер.

— Мурали Суриар
источник
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.