次のような複雑なブリッジ構成があります。
デフォルトのパスがありますvia 172.31.0.1 dev eth0_bridge
。
lan_bridge
eth0_bridge
今、別のデバイスが接続し、eth1
DHCPサーバーからアドレスを取得し、デフォルトのルートを介してインターネットにアクセスできるように、間の仮面舞踏会を設定しようとしていますeth0
。
そのために、次のようにiptablesルールを追加しました。
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0_bridge -j MASQUERADE
これを行い、他の一般的なNATルールを追加しましたが、問題を引き起こすのはまさにこのルールでした。 .tcpdumpping 172.31.0.1
に接続しようとすると、パケットが元のソースアドレスと一緒に到着したことがわかります。このルールは一度も壊れたことがないようです。だから、次のルールを追加しました。eth1
172.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_bridge
eth0_bridge
eth1_bridge
理論的な解決策は、ブリッジシステム全体でiptablesを無効にし、実際に必要な場合にのみ有効にすることです。残念ながら、Dockerはここに指を置いて(a)モジュールをロードし、br-netfilter
(b)/proc/sys/net/bridge/bridge-nf-call-iptablesを1に設定するよう強制しました。このシステムではdockerを使用しているので、修正するのは少し難しいです。私はこれについてlibnetworkにバグレポートを提出しました。