セットアップ:
VM1 ---ブリッジ-VM2
VM1と2は同じサブネット上にあります。ブリッジには、brctlブリッジに追加された2つのインターフェースがあります。 uptables -A FORWARD -s(VM1 ip)-j DENYを使用してVM2 ipをブロックすると、機能しません。パケットがネットワークレイヤーに送信されないことを理解していますが、 this は、「IPパケットがブリッジコード内にある間、すべてのiptablesチェーンがトラバースされる」と述べています。 MACフィルタリングでさえ、iptablesでは機能しません。 ebtablesは正常に動作します。なにが問題ですか?
Linuxのブリッジフィルターフレームワークには、レイヤー2ブリッジコードがiptables
(およびarptables
またはip6tables
)へのアップコールを実行し、レイヤー2(ブリッジフレーム)からレイヤー3(iptables
、パケットを含む)までのフィルタリングの移動を可能にするメカニズムがあります。 )、次にレイヤー2に戻ります。これは、BROUTING
チェーンの使用をはるかに超えています。これにより、レイヤー2にとどまるか、レイヤー3に継続する(フレームに対してdnat
/broute
をローカルに実行することによる)論理的な選択のみが提供されます。
このレイヤー違反により、たとえば、conntrack
機能を活用して、ステートフルファイアウォールをレイヤー2で利用できるようになります。
これが起こることを人々が期待していないときにトラブルを引き起こし、デバッグが困難な問題が発生したり、(ほとんどの場合)必要のないパフォーマンスを妨げたりしました。したがって、カーネル3.18以降、 br_netfilterコードはブリッジコードから分割され、モジュール化されました であり、自動的に読み込まれなくなりました。
この機能をiptablesで使用するには、1つ modprobe br_netfilter
を使用し、sysconfパラメータnet.bridge.bridge-nf-call-iptables
を1
に設定したままにします(echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
と同等)。これにより、OPのリンクのすべてのすばらしい複雑さを許可するようになります: Linuxベースのブリッジでのebtables/iptablesの相互作用 。このモジュールは、iptablesが physdev
)一致を使用するときにも自動的にロードされ、ebtables
とiptables
の両方を使用するときに注意しないと、ファイアウォールの動作全体を微妙に変更する可能性があります。
nftables
に関する注意:この機能は、現在nftables
ではまだご利用いただけません。 somenetdevconf -に示唆されているように、現在のステータスは少し乱雑であると見なされ(レイヤー化違反の追加の複雑さのため)、これをnftables
に実装しようとする前に、いくつかの再編成が求められます レポート 。更新:実際に作業が始まりました: ブリッジの接続追跡サポート 。