web-dev-qa-db-ja.com

LXCコンテナーをホストeth0にブリッジして、パブリックIPを持つことができるようにする

更新：

私はそこで解決策を見つけました： 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を実行しました）。

2日間検索して試した後でも、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（ホストを含​​む）にpingすることはできません。


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）構成パネルで02：00：00：86：5b：11を指すようにIP 179.43.46.233を構成しました。
（この投稿のIPは実際のものではありません。）

この長い質問を読んでくれてありがとう！ :-)

ビアンニー

networkingiptablesbridgelxc
8
Vianney Stroebel

変更を永続的にするためのより良い方法は、/ procに直接書き込む代わりにsysctlを使用することです。これは、実行時にカーネルパラメータを構成して、次回の起動時に正しく設定するための標準的な方法だからです。

# 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を使用して明示的に無効にする必要があります

これらの目的は何ですか？これらのカーネル構成オプションは、パケットをarptables/iptablesに渡す（1）または渡さない（0）ためにここにあります bridge-nf 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ファイアウォールルールが適用されるのは非常に予想外であるため、何が起こっているのかを把握するにはかなりの時間がかかる場合があります。

とセキュリティを強化：

特に仮想化が存在する場合、ブリッジングのリスクはまだ高いと私はまだ思います。 1つのホストに2つのVMがあり、それぞれに専用のブリッジがあり、どちらも他方のトラフィックについて何も知らないようにするシナリオを考えてみます。

ブリッジングの一部としてconntrackが実行されているため、トラフィックがクロスオーバーする可能性があり、これは重大なセキュリティホールです。

更新：2015年5月

3.18より古いカーネルを実行している場合は、デフォルトで有効になっているブリッジフィルタリングの古い動作の影響を受ける可能性があります。 3.18より新しい場合でも、ブリッジモジュールをロードしていて、ブリッジフィルタリングを無効にしていない場合は、この問題に悩まされる可能性があります。見る：

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

何年にもわたって、デフォルトのブリッジフィルタリングを「無効」にしてカーネルのメンテナが変更を拒否するように要求した結果、ブリッジモジュールがロードされない（デフォルトでは）フィルタリングが別のモジュールに移動されました。が読み込まれ、デフォルトで「無効」になります。わーい！

I think this is in the kernel as of 3.17 (It definitely is in kernel 3.18.7-200.fc21, and appears to be in git prior to the tag "v3.17-rc4")

6
aculich

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」設定を削除して、コンテナを再起動してみてください。

0
Murali Suriar