NATと複雑なブリッジ構成

NATと複雑なブリッジ構成

次のような複雑なブリッジ構成があります。

ここに画像の説明を入力してください。

デフォルトのパスがありますvia 172.31.0.1 dev eth0_bridge

lan_bridgeeth0_bridge今、別のデバイスが接続し、eth1DHCPサーバーからアドレスを取得し、デフォルトのルートを介してインターネットにアクセスできるように、間の仮面舞踏会を設定しようとしていますeth0

そのために、次のようにiptablesルールを追加しました。

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0_bridge -j MASQUERADE

これを行い、他の一般的なNATルールを追加しましたが、問題を引き起こすのはまさにこのルールでした。 .tcpdumpping 172.31.0.1に接続しようとすると、パケットが元のソースアドレスと一緒に到着したことがわかります。このルールは一度も壊れたことがないようです。だから、次のルールを追加しました。eth1172.31.0.1

iptables -t nat -I POSTROUTING 1 -s 192.168.100.0/24 -j LOG --log-prefix NAT:

これは dmesg に表示される唯一の一致です。

[10555.271048] NAT:IN= OUT=eth1_bridge PHYSIN=eth1 PHYSOUT=ve_eth1_lan SRC=192.168.100.210 DST=172.31.0.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=55162 DF PROTO=ICMP TYPE=8 CODE=0 ID=13662 SEQ=1

したがって、これらのパケットがPOSTROUTINGテーブルに到着する唯一の時間は、eth1_bridgeエントリvethペア(見出し)を離れるときですlan_bridge。この時点でパケットをMASQUERADEに送信します。

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth1_bridge -j MASQUERADE

その結果、100%パケット損失が発生しました。

この場合、192.168.100.0/24ネットワーク間のNATをどのように設定しますか?172.31.0.0/24

編集する詳細は:

私が見つけたシステムは、4.9カーネルを実行するAlpine 3.9でした。また、2つのブリッジを使用して4.15を実行しているUbuntu 18.04で再現されました。

ベストアンサー1

br_netfilterこの動作は、モジュールをロードして関連ブリッジでiptablesを有効にした場合にのみ観察されます(参照/sys/class/net/*/bridge/nf_call_iptables/proc/sys/net/bridge/bridge-nf-call-iptables- これは論理ORを適用するため、システム内のすべてのブリッジまたは特定のブリッジに対して有効にできます。有効にすると無効にすることはできません)。特定のブリッジ)。

この設定では、NAT POSTROUTINGチェーンは、パケットが最初のブリッジに到達したときにパケットに適用されます。この時点では、質問のログメッセージに示すようにOUTデバイスがあるため、出力インターフェイスとしてのルールは機能しません。広すぎるマスカレードルールを設定してパケットが開いている間にマスカレードを許可すると、マスカレードが発生しますが、送信元アドレスが正しくありません。eth1_bridgeeth0_bridgeeth1_bridge

理論的な解決策は、ブリッジシステム全体でiptablesを無効にし、実際に必要な場合にのみ有効にすることです。残念ながら、Dockerはここに指を置いて(a)モジュールをロードし、br-netfilter(b)/proc/sys/net/bridge/bridge-nf-call-iptablesを1に設定するよう強制しました。このシステムではdockerを使用しているので、修正するのは少し難しいです。私はこれについてlibnetworkにバグレポートを提出しました。

おすすめ記事