私は2つのインターフェイス間のIP転送設定に精通しており、常に動作します。これで、ローカルブリッジから出力インターフェイスへのIP転送を設定する別のシナリオがあります。
lan0
eno1 < --- > bridge0 -<
lan1
次のコマンドを使用しました。
sysctl net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING --out-interface eno1 -j MASQUERADE
iptables -A FORWARD --in-interface bridge0 -j ACCEPT
wlan0から8.8.8.8へのpingを試してみてください。
tcpdumpを使用すると、eno1に到着したパケットを表示し、ping応答を受信できます。しかし、eno1からbridge0に戻りません。
ブリッジを使用すると何か抜けましたか？
いくつかの要求された出力：
root@mclaren:/home/ramon# ip -br link
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eno1 UP f0:d4:e2:eb:c9:9c <BROADCAST,MULTICAST,UP,LOWER_UP>
<BROADCAST,MULTICAST,UP,LOWER_UP>
bridge0 UP a6:13:ed:28:be:7a <BROADCAST,MULTICAST,UP,LOWER_UP>
lan0 UNKNOWN 7a:46:b3:ea:a2:92 <BROADCAST,UP,LOWER_UP>
lan1 UNKNOWN fa:2b:35:57:5c:44 <BROADCAST,UP,LOWER_UP>
root@mclaren:/home/ramon# ip -4 -br address
lo UNKNOWN 127.0.0.1/8
eno1 UP 172.23.1.107/24
bridge0 UP 192.168.0.254/32
root@mclaren:/home/ramon# ip route
default via 172.23.1.254 dev eno1 proto dhcp src 172.23.1.107 metric 100
172.23.1.0/24 dev eno1 proto kernel scope link src 172.23.1.107
172.23.1.254 dev eno1 proto dhcp scope link src 172.23.1.107 metric 100
192.168.0.0/24 dev bridge0 scope link src 192.168.0.254
root@mclaren:/home/ramon# ip -4 neigh
172.23.1.111 dev eno1 lladdr 1c:98:ec:1a:d5:c0 STALE
192.168.0.50 dev bridge0 FAILED
192.168.0.97 dev bridge0lladdr 0a:a0:db:c0:ab:91 STALE
172.23.1.105 dev eno1 FAILED
192.168.0.25 dev bridge0 lladdr 0a:a0:db:c0:41:f4 STALE
172.23.1.130 dev eno1 FAILED
172.23.1.254 dev eno1 lladdr e0:23:ff:d0:b8:22 REACHABLE
172.23.1.163 dev eno1 lladdr e0:70:ea:01:18:6e STALE
192.168.0.33 dev bridge0 lladdr 0a:a0:db:c0:a0:0d STALE
root@mclaren:/home/ramon# bridge link
124: lan0: <BROADCAST,UP,LOWER_UP> mtu 1500 master bridge0 state forwarding priority 32 cost 100
164: lan1: <BROADCAST,UP,LOWER_UP> mtu 1500 master bridge0 state forwarding priority 32 cost 100
root@mclaren:/home/ramon# iptables-save -c
# Generated by iptables-save v1.8.7 on Sat Aug 27 18:53:58 2022
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [22529:1892750]
:OUTPUT ACCEPT [0:0]
[0:0] -A FORWARD -i bridge0 -j ACCEPT
COMMIT
# Completed on Sat Aug 27 18:53:58 2022
# Generated by iptables-save v1.8.7 on Sat Aug 27 18:53:58 2022
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
[13:990] -A POSTROUTING -o eno1 -j MASQUERADE
[0:0] -A POSTROUTING -o eno1 -j MASQUERADE
COMMIT
# Completed on Sat Aug 27 18:53:58 2022
ベストアンサー1
ファイアウォールルールセットが戻りトラフィックをブロックします。
*filter :INPUT ACCEPT [0:0] :FORWARD DROP [22529:1892750] :OUTPUT ACCEPT [0:0] [0:0] -A FORWARD -i bridge0 -j ACCEPT COMMIT[...]
これにより、ブリッジインターフェイスから受信したトラフィックが別の場所に移動できます。ただし、どこからでも受信したトラフィックがブリッジインターフェイスに到達できるようにする方法はありません。したがって、ping応答が到着すると、デフォルトポリシーである廃棄が適用されます。
簡単にこれを行うことができます：
iptables -A FORWARD -o bridge0 -j ACCEPT
またはあなたは使用することができますステートフルファイアウォール回答を許可（のみ）：
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
特に、追加の設定が必要なFTPなどのプロトコルの代替データストリーム関連トラフィックには関連するICMPエラーが含まれているため、UDPエラーを再度受信したり、パスMTU検索が正しく機能したりできます。
この回答には、ブリッジの使用に関する内容はありません。
Dockerを使用すると、代わりにする必要があるかどうかを検討する必要があります。入れるこれらのルールは、FORWARDチェーン（参照）ではなくDOCKER-USERチェーン（Dockerがここに何かを追加できるため）にあります。詳しくはそこから必要かどうかを知ってください）。
iptables -N DOCKER-USER || true # so it works whether Docker was started before or not
iptables -I DOCKER-USER 1 -o bridge0 -j ACCEPT
iptables -I DOCKER-USER 2 ...
または
iptables -N DOCKER-USER || true
iptables -I DOCKER-USER 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
...
今Dockerが存在するのでできる通常のインターフェイスの代わりにブリッジを使用することに関連しています。その後、FORWARDまたはDOCKER-USERに追加する必要があります。そうしないと、lan0とlan1の間のブリッジトラフィックが中断される可能性があります。
iptables -A -m physdev --physdev-is-bridged -j ACCEPT
このDockerの問題に関する関連質問：ここ、ここまたはそこ。これはかなり進化したテーマです。つまり、Dockerがネットワーク設定/ファイアウォール設定を変更したシステムでは、ネットワーク実験を実行しないでください。