站点到站点 VPN：究竟哪个方向真正需要规则？

两端都报告隧道已建立，远端分支机构能从网关应答，而一侧用户的应用仍然超时。常见建议是在两个方向都添加防火墙规则。有时这是对的，有时它重复了一条已经存在的规则，有时正是第二条规则破坏了状态。属于哪种情况取决于防火墙在哪里看到数据包。

有状态回程流量会改变规则数量

有状态防火墙会记录请求，并在没有第二条规则的情况下放行回复，因此只需要一条规则的设计是正常的。无状态访问列表没有这种记忆，回复必须被显式允许。两者在各自的平台上都正确，这就是建议相互矛盾的原因。

阅读你面前平台的转发文档，并检查你正在编辑的策略在它看到数据包的位置是否有状态。对已建立流量的显式拒绝，或在状态表之前就评估回复的规则顺序，会把可用的设计变成令人困惑的设计。规则数量是实现细节，而要求是：被允许的会话两个方向都能完成。

防火墙在哪里看到解密后的数据包

在基于策略的隧道中，防火墙可能在解密前评估加密数据包，并在解密后于不同接口评估解密后的数据包。为错误接口编写的规则存在、正确，却永远不会被匹配。这就是为什么从可用部署复制来的规则集会在相同硬件上失败。

基于路由的 IPsec 和大多数现代实现会提供隧道接口，因此解密后的数据包会到达那里，普通接口规则随之生效。在从为另一种模型编写的指南复制规则集之前，先确认部署使用的是哪种模型。隧道接口也是你需要知道数据包究竟有没有被解密时该看的地方。

非对称路由打破了这个假设

有状态防火墙假设它能看到会话的两半。如果回复经由另一台网关返回，该设备没有请求的状态，就会按自己的策略丢弃它。症状是单向故障，发送侧的任何规则都无法修复。 追踪回复路径 再改动任何东西。

在两侧添加宽泛的允许规则之前，先检查回复路由。在每个接口上容忍一切，既掩盖了路由错误，又同时扩大了访问范围，这是最糟糕的组合。

用真实源地址检查两个方向

用远端实际看到的地址测试，因为地址转换可能让源规则匹配不到任何东西。同时在两台网关上抓包。

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

在远端网关上以意外源地址出现的请求，解释了一条从不匹配的规则；而到达错误接口的回复，解释了状态不匹配。然后分别测试批准范围内和范围外的一个目标，让边界得到证明而不是假设。

记录转换后的源地址、解密数据包使用的接口以及匹配到的规则。这三个事实无需重复整个排查就能回答下一张工单。