源 NAT 会让后续防火墙看不到客户端地址

为员工与实验室客户端编写的规则被放到新的边缘防火墙上，却悄悄匹配一切或什么都不匹配。原因在上游：网关已经改写了客户端地址，因此规则看到的是一个中转地址，而不是两个组。增加设备并不能恢复路径已经丢掉的信息。在编写策略之前，先找出区分仍然存在的最后一点。

为什么边缘规则只看到一个地址

多对一转换把每个内部地址与端口的组合映射到一个带分配端口的共享外部地址。会话在转换器看来仍可凭借这些端口绑定区分，但下游设备若只做简单的源前缀匹配，就只能看到那个共享地址。这足以让两个组在该规则处变得一模一样。数据包照样到达，分组信息却没有。

要检查防火墙接口实际观察到什么，而不是图里承诺了什么。两者的差异比任何人预想的都更常见。

找出最后一个可执行的区分点

从执行点出发往回走，直到出现原始前缀。通常两条命令就能定位边界。

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

NAT 表显示哪些流量、按哪条规则被转换，而 conntrack 列表显示活动流的原始与转换后元组。在上游防火墙只能看到转换后地址的地方，按组生效的源地址规则无论怎么写都无法工作。沿着路径向前或向后走，直到抵达两台客户端前缀仍然可区分的那台设备。逐跳记录源地址，而不要相信内、外标签。

三种放置位置及其代价

策略可以放在执行转换的网关上，那里仍能看到原始源地址。若中转改为路由而非转换，也可以放在上游防火墙上，但这意味着要添加回程路由并去掉源地址改写。或者改为基于身份而非地址执行，通过一个能识别用户或设备的认证控制来实现。每种选择都有归属和失效模式，只有前两种能让规则纯粹关于源地址。

无论选哪种，记录规则时都要连同它所匹配的地址一起写。地址假设悄悄改变的规则比没有规则更糟，因为它会继续匹配流量，保护的却是完全不同的东西。

验收：一个放行客户端和一个拒绝客户端

用两个客户端测试，每组各一个，记录它们各自如何到达执行点。把两组元组都留在规则结果旁边，让证据表明区分得以保留，而不是证明还存在另一台防火墙。NAT 或路由变更后要重做测试，因为被呈现的地址正是会悄悄失效的部分。在必须区分人的地方保留认证，因为源地址是策略输入，而不是身份证明。

把执行点、观察到的源地址和规则写进工单。否则下一位工程师还会再加一台防火墙和同一条规则。