☰

在桥接 IP 分配的接口上启用 Linux NAT 中的数据包流

tag-icon • tag-icon networking bridge nat
在桥接 IP 分配的接口上启用 Linux NAT 中的数据包流

在我的 Linux 机器上，我有以下配置：

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether bc:e6:7c:51:20:6b  txqueuelen 1000  (Ethernet)
br0.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.103  netmask 255.255.255.0  broadcast 192.168.0.255
        ether bc:e6:7c:51:20:6b  txqueuelen 1000  (Ethernet)
br0.2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 20.20.20.1  netmask 255.255.255.0  broadcast 20.20.20.255
    ether bc:e6:7c:4d:8f:b0  txqueuelen 1000  (Ethernet)
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether bc:e6:7c:51:20:6b  txqueuelen 1000  (Ethernet)
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether bc:e6:7c:51:3a:b0  txqueuelen 0  (Ethernet)

/ # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.bce67c51206b       no              eth0
                                                        eth1

有 2 个第 3 层接口br0.1并br0.2在桥接器顶部创建。这是一种非典型的 NAT 配置，其中br0.2通过 .NET 为 LAN 端的客户端提供 DHCP 服务eth1。它具有静态 IP 20.20.20.1，并br0.1通过 WAN 端口连接eth0并通过 DHCP 从 DHCP 获取 IP eth0。

后路由链中还有一个伪装规则

table ip haswell-nat {
        chain haswell-postrouting {
                type nat hook postrouting priority mangle; policy accept;
                ip saddr 20.20.20.0/24 masquerade
        }
}
  • 当我从客户端 (20.20.20.2) ping 到默认网关 192.168.0.10 时，NAT 正在发生。
  • 我看到数据包来自 192.168.0.103。

我想知道这个 ping 数据包是如何被伪装的，因为 和 都eth0在eth1桥接接口下。通常eth0和eth1是单独的接口，并且不在任何桥下。

如果它们位于桥下，那么数据包是否应该简单地转发到其他接口而不触及 iptable 规则，因为它位于 IP 层？

编辑：网桥可识别 VLAN：

/ # bridge vlan show
port              vlan-id
eth0              1 PVID Egress Untagged
                  2
                  15
br0               1
                  2
                  15
eth1              1 PVID Egress Untagged

答案1

OP 没有提供所有细节，但是：

br0.1 通过 eth0 作为 wan 端口连接，并通过 eth0 从 DHCP 获取 IP

br0.2 正在为通过 eth1 连接的 LAN 端的客户端提供 DHCP

我只能假设以太网0和以太网1从外部设备（例如在其端口上配置了 VLAN 的交换机）接收 VLAN 标记流量，该标记流量由以下设备透明桥接br0（未配置为 VLAN 感知或 OP 会描述它）。

此 VLAN 标记的流量会被交换机过滤，因此不会泄漏到“另一端”。

这个流量还到达桥的自我界面：想要参与的界面路由。通过在其之上设置 VLAN 子接口，可以让多个接口参与接收流量的路由：这成为具有两个接口的路由器br0.1和br0.2参与路由（br0也会参与，但它没有配置 IP 地址，所以不会参与。与 ARP 可能发生的交互可以忽略不计）。

即使我的假设有点偏离，这并不重要路由而不是桥接将会发生。

以太网0和以太网1不参与路由：它们只是桥接端口。同样地，br0不参与路由，因为它没有地址，并且我可以假设没有添加任何会使用它的路由。

路由中涉及的其余接口是：

  • br0.1：广域网
  • br0.2：局域网

我可以假设路线 ( ip route) 与此类似：

# ip route
default via 192.168.0.10 dev br0.1 
20.20.20.0/24 dev br0.2 proto kernel scope link src 20.20.20.1 
192.168.0.0/24 dev br0.1 proto kernel scope link src 192.168.0.103

从现在开始，人们可以忽略网桥或网桥端口的参与：如果流量确实到达br0.1或者br0.2那么这就变成了路由的IP 数据包（通过类似以太网的接口），而不是桥接的帧。

网络过滤器连线（和 NAT）与 IP 地址一起使用nftables可以通过界面选择行为。这里的规则集不涉及接口名称，只涉及地址：每当 IP 源位于 20.20.20.0/24 的数据包在 nat/postrouting 中伪装时。

两种不同的情况是：

  • 系统上使用非默认源地址 20.20.20.1 本地发起的流经过 NAT。

  • 来自 20.20.20.0/24 的路由数据包经过 NAT

如果请求是从客户端 20.20.20.2 发送到另一个客户端 20.20.20.3，那么这一次的流量将为桥接的而不是路由的：（除了 ARP 广播）它永远不会到达br0,br0.1或者br0.2并且不会发生任何路由。这nftablesIP 挂钩根本不会被使用，也不会发生 NAT（除非内核模块br_netfilter 已加载这得到NAT 可能适用于桥接流量也。这永远不应该被需要或与nftables.)

相关内容