☰

net.bridge.bridge-nf-call-{arp,ip,ip6} テーブルのデフォルト値が 1 であるのはなぜですか。

tag-icon • tag-icon networking linux-kernel
net.bridge.bridge-nf-call-{arp,ip,ip6} テーブルのデフォルト値が 1 であるのはなぜですか。

少なくともArch Linuxでは、これがデフォルト設定です。私はこれが管理されていないスイッチのように動作する必要があり、ほとんどの順方向チェーンのデフォルトポリシーがパケットを破棄するため、ブリッジ動作を直感的にしないと思います。

これらのデフォルトの背後には何らかの理由がありますか？

ベストアンサー1

この機能使用増加を許可ebtables使用時iptablesブリッジ パスにルーターの代わりにステートフル ファイアウォール ブリッジを実装します。それ久しぶりです(2002)最初はスイッチがなく、ブリッジコードの一部です。ブリッジとネットフィルタのサポートが有効、やっぱりそうですね。

それから2003年に追加されたスイッチ。もちろん、互換性の理由からデフォルト設定は有効になっています。

それからカーネルは3.18です。br_netfilterこの機能によって引き起こされる可能性のある問題のため、この機能は独自のカーネルモジュールに分割されました。人々は互換性について心配しており、すでに互換性を停止する計画があります。nftables:

これにより互換性が損なわれます。 [...] ただし、br_netfilter を modprobing すると損傷を簡単に除去できます。

さらに、nftablesの計画は、このソフトウェア層に依存せず、代わりに接続トレースをブリッジ層に統合して、ブリッジネットフィルタユーザーが希望するステートフルフィルタリングとNATを有効にすることです。

この機能が正しく機能するには、カーネルモジュールをロードする必要があります。ただし、主要な既知の顧客は通常、すべてのブリッジステートフルファイアウォール設定で見つかります。iptablesターゲットphysdevどのbr_netfilter互換性の理由で再自動ロード。

したがって、単純なシステムではbr_netfilterロードまたはロードしないでください。システム制御：net.bridge、、、bridge-nf-call-arptables（bridge-nf-call-ip6tables、、、、）内で利用可能なコンテンツはまったく表示されませbridge-nf-call-iptablesんbridge-nf-filter-pppoe-tagged。bridge-nf-filter-vlan-taggedbridge-nf-pass-vlan-input-dev

しかし今、このカーネルモジュールにはDockerという新しい主要な顧客がいます。この問題が発生する一般的な方法は、Dockerを実行するときです。Docker 明示的な読み込みbr_netfilterコンテナ間の内部通信を制御する同時デフォルトでは、転送されたパケットをフィルタリングして破棄します。。その結果、人々は、しばしば予期しない状況でも、その動作が使用されることを発見したり、実際に再び発生しないべき動作が予想されると考えています。

デフォルト設定はシステム全体であるため、Dockerが管理するブリッジに加えて、システム内の他のすべてのブリッジ、つまり初期ホストネームスペースのブリッジだけでなく、どのその他のネットワークネームスペース。

同様に、iptables'physdevbr_netfilter自分のモジュール（）自体がロードされたときにのみ自動的にロードされます。xt_physdev（以前はこれより頻繁に発生しました。）今回のパッチ）。方法を参照してください修理する説明は次のとおりです。

より良い解決策は、「call-iptables」デフォルトを0に変更し、明示的な設定を1に強制することです。ただし、これは以前のバージョンとの互換性を損なう可能性があります。。

これらすべてがこの質問に対する答えを提供します。

これは以前のバージョンとの互換性のためです。

追加の注意事項。

xt_physdevカーネルモジュールが現在ロードされていないシステムでは、br_netfilterユーザーネームスペースを実行している一般ユーザーのみが次の操作を実行できます。

$ unshare -urnm
# iptables -A FORWARD -m physdev --physdev-is-bridged
# exit
$

特別で外観的に役に立たないルールを使用する攻撃から自分自身を保護しないシステム（仮想マシン、コンテナ...）にインストールされている他の技術のLAN接続を中断する可能性があります。

iptables -P FORWARD DROP

Netfilter ドキュメントページでは、これらの効果を説明し、ブリッジパス、ルーティングパス、ebtable、iptable 間の相互作用について説明します。 Linuxベースのブリッジのebtables/iptables相互作用。これパート7どのような保護を追加する必要があるかを説明するので、特に便利です。たとえば、次のようになります。

iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE

上記の最初の規則は、同じLAN上のアドレス間パケットがIP層から転送されず（つまりルーティング）、イーサネット層からフレームに転送（ブリッジング/スイッチング）されるため、あまり意味がありません。ルートではなく、橋や橋と見なされるため、一致します。iptablesレイヤ3：IPv4でのみ機能すると予想されます。ただし、br_netfilterロードされると、このタイプの「死んだルール」が必要です。それ以外の場合は、ブリッジパスのレイヤ2でルーティング専用のタスクが発生します（ここに示すように、NATは同じLAN上の2つのノード間でブリッジされます。最初のルールなしで完了）。 ）。

人々は（長年にわたり）それから抜け出そうとしてきましたが、br_netfilter機能的同等性が必要です。これは、カーネル5.3を介したIPおよびIPv6（ARPのようです）の実装と似ています。nftablesおよびカーネルモジュールnf_conntrack_bridgeこれを通してnftablesbridge家族の中で（またはトリガーのような系列でipはない）使用ip6inetbr_netfilterつながる:

これは "br_netfilter" インフラストラクチャを置き換えます。

ステータスフィルタリング

Bridgeシリーズは、Linuxカーネル5.3以降の接続追跡をサポートしています。

これを有効にするには、ルールセットのconntrackステータス情報と一致させるだけです。

iptableに精通している人のために：これはbr_netfilterに代わるものであり、iptablesの-m physdevと一致します。。

ただし、VLANのカプセル化/カプセル化解除に関連する他の機能、特にPPPoEプロトコルはまだ準備されていません。

また、カーネル5.3以降では、ネットワークネームスペース全体の機能を無効にし、ネットワークネームスペース固有またはブリッジベースでのみ有効にすることができます。ただし、これは作成されたすべての新しい名前空間（初期ネットワーク名前空間を含む）内で次のように最初に実行する必要があります。

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

ip link add ...次に、ブリッジの作成時間（）またはそれ以降（ip link set ...）でそれを必要とする慎重に選択されたブリッジに対して、次の手順を実行します。

ip link set somebridge type bridge nf_call_iptables 1

Dockerとデフォルト設定iptables設定ではこれを処理できないため、Dockerはこれらの設定を使用するホストで同時に実行することはできませんが、Docker-in-Docker（実際には同じ理由でDocker以外のLXCなどの他のコンテナテクノロジでは）はそれぞれの既定値なので良いかもしれません。新しい名前空間はまだ古いバージョンと互換性があります。

おすすめ記事