ОБНОВИТЬ:
Я нашел там решение: 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-адреса в этом посте не настоящие.)
Спасибо, что прочитали этот длинный вопрос! :-)
Вианни
Лучший способ сделать ваше изменение постоянным - использовать 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
Что касается ответа на вопрос в вашем обновлении ...
мост-netfilter (или мост-нф) - это очень простой мост для пакетов IPv4 / IPv6 / ARP (даже в заголовках 802.1Q VLAN или PPPoE), который обеспечивает функциональность прозрачного межсетевого экрана с отслеживанием состояния, но более продвинутые функции, такие как прозрачный IP NAT, предоставляются путем передачи этих пакетов в arptables / iptables для дальнейшей обработки - однако, даже если более продвинутые функции arptables / iptables не нужны, передача пакетов этим программам все еще включена по умолчанию в модуле ядра и должна быть отключена явно с помощью sysctl.
Для чего они здесь? Эти параметры конфигурации ядра предназначены для передачи (1) или не передачи (0) пакетов в arptables / iptables, как описано в мост-нф FAQ:
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")
У меня аналогичная установка работает на гипервизоре 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 и перезапустить контейнер.