桥接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 ping到任何IP（包括主机的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

而且我的主机无法ping通该容器：


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（在/ etc / default / lxc中为USE_LXC_BRIDGE =“ false”）。


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

我已经在托管提供商（OVH）配置面板中将IP 179.43.46.233配置为指向02：00：00：86：5b：11。
（这篇文章中的IP不是真实的。）

感谢您阅读这个冗长的问题！:-)

万尼

networking  iptables  bridge  lxc 
— 范尼·斯特劳贝尔
source

Answers:

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数据包（即使在802.1Q VLAN或PPPoE标头中）的非常简单的桥，它提供了有状态透明防火墙的功能，但是更高级的功能（例如透明IP NAT）是通过将这些数据包传递到arptables / iptables进行进一步处理而提供-但是，即使不需要arptables / iptables的更高级功能，在默认情况下，仍将内核模块中的数据包传递给那些程序，并且必须显式关闭使用sysctl。

他们在这里做什么？这些内核配置选项此处是按照bridge-nf常见问题中的说明将数据包传递（1）或不传递（0）数据包至arptables / iptables ：

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防火墙规则应用于网桥上的帧太出乎意料了，因此可能要花一些时间才能确定正在发生的事情。

并提高安全性：

我仍然认为桥接的风险更高，尤其是在存在虚拟化的情况下。考虑这样一种情况，您在一台主机上有两个VM，每个VM都有一个专用桥，目的是使两个都不知道对方的流量。

使用conntrack作为桥接的一部分时，流量现在可以越过，这是一个严重的安全漏洞。

更新：2015年5月

如果您运行的内核版本早于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”之前）

— 阿库利奇
source
0

我在Debian Wheezy虚拟机管理程序上运行了类似的设置。我不必在容器的rootfs中修改/ etc / network / interfaces；在LXC的配置中配置lxc.network。*就足够了。

无论您是否正在运行容器，都应该能够进行桥接工作。我在主机上的/ etc / network / interfaces的br0下配置了以下设置：

% 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会话。

完成后，尝试删除/ etc / network / interfaces中的'eth0'配置并重新启动容器。

— 穆拉里·苏里亚
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.