NAT и сложные конфигурации моста

Я настроил тестовую среду, чтобы попытаться воспроизвести вашу проблему. Следующий сценарий устанавливает три сетевых пространства имен для представления трех систем :

• Узел, который вы изобразили в своем вопросе, называется n0.
• Система gw, подключенная к eth0с адресом 173.31.0.1
.
• Система n1, подключенная к eth1с адресом 192.168.100.100.

Он создает два моста на хосте для представления сети 192.168.100.0/24 и сети 173.31.0.0/24.

Конфигурация внутри n0такова, как вы описали.

#!/bin/sh

set -x

ip netns add gw
ip netns add n0
ip netns add n1

ip link add gw-eth0-out type veth peer name gw-eth0-in
ip link add n0-eth0-out type veth peer name n0-eth0-in
ip link add n0-eth1-out type veth peer name n0-eth1-in
ip link add n1-eth0-out type veth peer name n1-eth0-in

brctl addbr 192_168_100
brctl addbr 172_31_0

brctl addif 172_31_0 gw-eth0-out
brctl addif 172_31_0 n0-eth0-out
brctl addif 192_168_100 n0-eth1-out
brctl addif 192_168_100 n1-eth0-out

for iface in 172_31_0 192_168_100 gw-eth0-out n0-eth0-out n0-eth1-out n1-eth0-out; do
    ip link set $iface up
done

ip link set netns gw name eth0 gw-eth0-in
ip link set netns n0 name eth0 n0-eth0-in
ip link set netns n0 name eth1 n0-eth1-in
ip link set netns n1 name eth0 n1-eth0-in

ip netns exec gw ip addr add 172.31.0.1/24 dev eth0
ip netns exec gw ip link set eth0 up

ip netns exec n1 ip addr add 192.168.100.100/24 dev eth0
ip netns exec n1 ip link set eth0 up
ip netns exec n1 ip route add default via 192.168.100.1

ip netns exec n0 brctl addbr eth0_bridge
ip netns exec n0 brctl addbr eth1_bridge
ip netns exec n0 brctl addbr lan_bridge
ip netns exec n0 ip link add patch-eth1 type veth peer name patch-lan

ip netns exec n0 brctl addif eth0_bridge eth0
ip netns exec n0 brctl addif eth1_bridge eth1
ip netns exec n0 brctl addif eth1_bridge patch-lan
ip netns exec n0 brctl addif lan_bridge patch-eth1
ip netns exec n0 ip addr add 172.31.0.10/24 dev eth0_bridge
ip netns exec n0 ip addr add 192.168.100.1/24 dev lan_bridge
for iface in eth0 eth1 eth0_bridge eth1_bridge lan_bridge patch-lan patch-eth1; do
    ip netns exec n0 ip link set $iface up
done

Когда сценарий завершает работу, у нас есть модель вашей среды без правила MASQUERADE. Как и ожидалось, попытка отправить эхо-запрос 172.31.0.1из 192.168.100.100не удастся.

Если мы добавим правило маскарада кn0:

ip netns exec n0 iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0_bridge -j MASQUERADE

pingпо-прежнему не работает.

Если я включу IP-переадресацию в n0...

ip netns exec n0 sysctl -w net.ipv4.ip_forward=1

Все начинает работать как положено.

Такое поведение наблюдается только при загруженном модуле br_netfilterи включении iptables на рассматриваемых мостах (см. /sys/class/net/*/bridge/nf_call_iptablesи/proc/sys/net/bridge/bridge-nf-call-iptables-они применяются как логическое ИЛИ, поэтому вы можете включить его для каждый мост в системе, или вы можете включить его для определенных мостов, вы не можете отключить его для определенных мостов ).

В этой конфигурации цепочка NAT POSTROUTING применяется к пакету, когда он достигает первого моста. На данный момент устройство OUT— это eth1_bridge, как показано в сообщении журнала в вопросе, поэтому правила с eth0_bridgeв качестве выходного интерфейса не работают. Установка слишком широкого правила MASQUERADE -таким образом, что пакет маскируется, пока он все еще находится на eth1_bridge, приводит к маскировке, но с неправильным адресом источника.

Теоретическое решение этой проблемы состоит в том, чтобы отключить iptables на мостах -во всей системе и включить его только там, где это действительно необходимо. К сожалению, Docker сует свой палец в пирог здесь и заставляет (a )загружать модуль br-netfilterи (b )настройку /proc/sys/net/bridge/bridge -nf -вызовите -iptables на 1. Поскольку мы используем докер в этой системе, это немного сложно исправить.Я поднял отчет об ошибке в libnetwork для этого и намерен представить патч на следующий день или около того, чтобы исправить это.