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を実行したもの）が必要です。

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は実際のものではありません。）

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

ビアンニー

networking  iptables  bridge  lxc 
— ビアンニー・ストローベル
ソース

回答:

6

変更を永続的にするためのより良い方法は、/ 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を使用します。

彼らは何のためにここにいるのですか？これらのカーネル構成オプションは、bridge-nf FAQで説明されているように、arptables / iptablesにパケットを渡す（1）か、渡さない（0）かのいずれかです。

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

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

これは3.17以降のカーネルにあると思います（カーネル3.18.7-200.fc21にあり、タグ「v3.17-rc4」の前のgitにあるようです）

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

— Murali Suriar
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.