☰

ブリッジネットワーキングを使用して2つのネットワークネームスペース間で通信を確立することはできません。

tag-icon • tag-icon networking network-interface network-namespaces
ブリッジネットワーキングを使用して2つのネットワークネームスペース間で通信を確立することはできません。

私はフォローアップをしています。この動画Linuxのネットワークネームスペースについて直接練習してみましたが、何らかの理由で機能しませんでした。私がしたことは次のとおりです。

「blue」と「red」という2つのネットワークネームスペースを作成した後：

sudo ip link add bridge type bridge
sudo ip link set dev bridge up
sudo ip link add veth-red type veth peer name veth-red-br
sudo ip link add veth-blue type veth peer name veth-blue-br
sudo ip link set veth-red netns red
sudo ip link set veth-red-br master bridge
sudo ip link set veth-blue netns blue
sudo ip link set veth-blue-br master bridge
sudo ip netns exec red ip addr add 192.168.15.1/24 dev veth-red
sudo ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue
sudo ip netns exec red ip link set veth-red up
sudo ip link set veth-red-br up
sudo ip netns exec blue ip link set veth-blue up
sudo ip link set veth-blue-br up

今、赤から青へ、またはその逆にpingを試しても機能しません。奇妙なことに、ARPが機能するため、インターフェイス間に接続があります。arp名前空間で実行すると正しい値が表示されるため、これを知っています。

$ sudo ip netns exec red arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.15.2             ether   ca:4f:b6:65:a0:f8   C                     veth-red

$ sudo ip netns exec blue ifconfig
veth-blue: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.15.2  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::c84f:b6ff:fe65:a0f8  prefixlen 64  scopeid 0x20<link>
        ether ca:4f:b6:65:a0:f8  txqueuelen 1000  (Ethernet)
        RX packets 85  bytes 8946 (8.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27  bytes 1986 (1.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

これで、赤い名前空間にARPテーブルの青い名前空間のMACアドレスがあることがわかりますが、なぜpingが機能しないのですか？

答え1

IPv4がフィルタリングされたためです。iptablesまたはnftables。あなたはこのように考えることができます：話すことはできません。iptablesレイヤ 3 で IPv4 を使用します。

しかし、方法があります：br_netfilter（次から表示バックトラッカー証明書の有効期限が切れたためです。）

bridge-netfilter コードは次の機能を有効にします。

{Ip、Ip6、Arp}テーブルは、802.1Q VLANまたはPPPoEヘッダーにカプセル化されていても、ブリッジされたIPv4 / IPv6 / ARPパケットをフィルタリングできます。これにより、ステートフルな透明ファイアウォール機能が可能になります。

したがって、これら3つのツールのすべてのフィルタリング、ロギング、およびNAT機能はブリッジされたフレームで利用可能です。

また、見ることができますLinuxベースのブリッジのebtables/iptables相互作用もっと学ぶ。

したがって、誰かがこれを行うと：

iptables -I FORWARD -j DROP
modprobe br_netfilter

（またはパケットを許可するルールなしでFORWARDポリシーをDROPに設定）デフォルトでは、ブリッジはレイヤ2で受信したすべてのIPv4トラフィックを破棄します。iptables：IPv4フレームの場合、br_netfilterレイヤ2イーサネットフレームは一時的にIPv4パケットに「アップグレード」されます。iptables、まだブリッジロードにあります。ドロップされたパケットiptables橋から出ないでしょう。廃棄されていないアイテム（上記の例ではなし）は、ブリッジ処理を続行するためにイーサネットフレームとしてブリッジに再送されます。

考えられる原因：Docker。 Dockerは実際に有効になっていますbr_netfilter（コンテナ間の分離のため）。明示的に文書化されていませんが、これは次のとおりです。Docker部分ソース:

  if config.EnableIPTables || config.EnableIP6Tables {
      if _, err := os.Stat("/proc/sys/net/bridge"); err != nil {
          if out, err := exec.Command("modprobe", "-va", "bridge", "br_netfilter").CombinedOutput(); err != nil {
              logrus.Warnf("Running modprobe bridge br_netfilter failed with message: %s, error: %v", out, err)
          }
      }
  }

bridgeカーネルモジュールをロードするときbr_netfilter。

Dockerが設定します。iptables'ポリシーをDROPに転送する：

ルーターのドッカー

Dockerはチェーンのポリシーを[...]FORWARDに設定しますDROP。

Dockerが原因でなくても、明らかにDockerを介してbr_netfilterロードされています。physdev次に、ファイアウォールルールはパケットをドロップします。iptables'(またはnftables') 転送ルール。そうでなければ、実際にはブリッジルールがあります。ebtablesまたはnftablesそして足ファミリは転送されたフレームをブロックします。

カーネル5.3以前は、これがブリッジレベルでステートフルファイアウォールを実行する唯一の方法でした。

存在するこの図青いフィールド（イーサネット）の緑色（IPv4）ボックスは、次のことを示します。iptables（またはnftablesbr_netfilter）は、イネーブル時にイーサネットブリッジパスで実行されます。

一般ネットワークのNetfilterとパケットフロー

システム全体の粒度の代わりにブリッジの粒度を使用してこれを行う方法があります（新しい名前空間にも継承されるように、最初にこれを行うのが最善です）。

  • その効果を読み込みますbr_netfilterが、無効にします。

    modprobe br_netfilter
sysctl -w net.bridge.bridge-nf-call-arptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0
sysctl -w net.bridge.bridge-nf-call-iptables=0

    この時点で赤そして青通信は可能ですが、Docker（おそらく損傷の元の原因）は任意にそれ自体が破損します。

  • 選択したブリッジで再度有効にします。

    ip link set bridge type bridge nf_call_iptables 1

    間の通信赤そして青。

カーネル5.3からシステム全体にわたって各ネットワーク名前空間を取得するように設定、非初期ネットワークネームスペースでこの機能を無効にする（または再度有効にする）必要がある場合は、その機能内のすべてのブリッジに影響します。

ip netns FOO sysctl -w net.bridge.bridge-nf-call-iptables=X

Dockerはこれらのモードをサポートしていません。生成するすべてのブリッジで（およびブリッジ生成設定がある場合は、生成するネットワーク名前空間で）sysctlを有効にする必要がありますが、これは現在知られていません。

もちろん、カーネルモジュールを削除すると、対話も防止され、トラフィックが返される可能性があります。

rmmod br_netfilter

まだカーネル5.3で起動しています、nftablesブリッジシリーズは直接ステートフルファイアウォールをサポートしているため、br_netfilterこの機能を使用する必要はなくなりました。br_netfilterPPPoE関連のファイアウォールnet.bridge.bridge-nf-filter-pppoe-tagged（デフォルトでは有効ではありません）でsysctlを使用することは今日でもまだ役に立つかもしれませんが、私が知っている限り、単純な代替方法はありません。

こことSFに関する次のQ / Aの関連回答も参照してください。

関連情報