
まず、専用サーバーに割り当てられた特別な IPv6 アドレスは 1 つだけです。::1/128 です。しかしeth0 にアドレスを割り当てることができます (例: ::2/128、::3/128 など)。
今、私はそのサーバー上で LXC コンテナーを実行したいのですが、それらをファーストクラス シチズンとして、独自の IPv6 アドレスを持たせたいと思っています。
IPv4 の LXC は正常に動作します。コンテナーを起動して、そこから世界中に ping を送信できます。 というブリッジ デバイスがありますlxcbr0
。
正直に言って、どう進めればよいかわかりません。私が持っている特定の LXC 設定では (「prefix」は割り当てられたプレフィックスを表します):
lxc.network.ipv6 = prefix::3/128
lxc.network.ipv6.gateway = prefix::2 # iffy, not sure this is correct
ホスト上で、転送を使用するように sysctl を構成しました。
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.eth0.forwarding = 1
今ではもう分からなくなってしまいました。考えるブリッジに IP を割り当てる必要があります。prefix::2/128 を割り当てました。これは上記の LXC 設定で使用します。「interfaces」で:
iface lxcbr0 inet6 static
address prefix::2
netmask 128
# use arp proxy? Read that somewhere.
post-up /sbin/ip -6 neigh add proxy prefix::3 dev eth0 #container 1
post-up /sbin/ip -6 neigh add proxy prefix::4 dev eth0 #container 2
言うまでもなく、これは機能しません。コンテナを起動してログインすることはできますが、何も ping できません。ホストからコンテナに ping することもできません。ルーティングに問題があることはわかっていますが...?
現在の状態の出力の一部: ホスト 'ip -6 a':
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2607:5300:60:714::1/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::ea40:f2ff:feed:106f/64 scope link
valid_lft forever preferred_lft forever
8: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2607:5300:60:714::2/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::b07b:e3ff:fe33:22e7/64 scope link
valid_lft forever preferred_lft forever
18: vethPVJQ6M: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::fcb7:57ff:fe3c:bcd1/64 scope link
valid_lft forever preferred_lft forever
コンテナ 'ip -6 a':
20: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2607:5300:60:714::3/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::216:3eff:fe59:679f/64 scope link
valid_lft forever preferred_lft forever
ホスト 'ip -6 r':
2607:5300:60:714::1 dev eth0 proto kernel metric 256
2607:5300:60:714::2 dev lxcbr0 proto kernel metric 256
2607:5300:60:7ff:ff:ff:ff:ff dev eth0 metric 1024
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev lxcbr0 proto kernel metric 256
fe80::/64 dev vethPVJQ6M proto kernel metric 256
fe80::/64 dev vethWT7OPQ proto kernel metric 256
default via 2607:5300:60:7ff:ff:ff:ff:ff dev eth0 metric 1024
コンテナ 'ip -6 r':
2607:5300:60:714::2 dev eth0 metric 1024
2607:5300:60:714::3 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
default via 2607:5300:60:714::2 dev eth0 metric 1024
ホストはUbuntu 15.04、LXC バージョン 1.1.2 を実行します。
いくつかアドバイスをいただければ幸いです。
答え1
ここでは、さまざまなことを混同しているように思われます。まず、サーバーのイーサネット ポートのネット マスクが実際に /128 であるかどうかは疑わしいです。別の何か (おそらく /64) であり、他の多数の顧客と共有セグメントを使用しているのではないかと思います。
「ip -6 a」コマンドの出力から判断すると、次のようになります。
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2607:5300:60:714::1/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::ea40:f2ff:feed:106f/64 scope link
valid_lft forever preferred_lft forever
8: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2607:5300:60:714::2/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::b07b:e3ff:fe33:22e7/64 scope link
valid_lft forever preferred_lft forever
18: vethPVJQ6M: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fe80::fcb7:57ff:fe3c:bcd1/64 scope link
valid_lft forever preferred_lft forever
インターフェイスの /128 はエラーだと思います。プレフィックスは 2607:5300:60:714::/64 のようです (おそらく)。
それが正しいと仮定すると、次のようにインターフェイス ファイルを設定する必要があります (必要に応じて IPv4 を追加します)。
auto lxcbr0
iface lxcbr0 inet6 static
bridge_ports eth0
bridge_fd 0
address 2607:5300:60:714::1
net mask 64
gateway 2607:5300:60:7ff:ff:ff:ff:ff
注: デフォルト ゲートウェイに到達するために 2607:5300:60:7ff::/64 に到達する方法が明確ではありません。プロバイダーがネットワークの構成方法をどのように想定しているかを把握したり、プロバイダーが提供しているドキュメントを直接確認したりすることが非常に役立ちます。ここから推測すると、2607:5300:60:714::/64 ネットワークは 2607:5300:60:7ff::/64 と同じリンク上にあると考えられます。2607:5300:60:7ff::/64 はプロバイダーのインフラストラクチャに使用されます。2607:5300:60:714:/64 全体を利用できるのか、それとも同じリンク上の他の顧客と共有されるのかは不明です。
その範囲内で自由にアドレスを割り当てることができると仮定すると、実際に必要なのは、コンテナを同じ lxcbr0 インターフェースに接続し、各コンテナのアドレスをそのブリッジ インターフェースに割り当てることだけです。
繰り返しますが、これはあなたが提供したデータに基づいた推測にすぎません。プロバイダーの実際の構成がわからない限り、確実に判断することは不可能です。