分流隧道并不让公网主机豁免 ASA 的 NAT 规则

分流隧道通常被描述为一种办法：让企业流量留在隧道内，让其余互联网流量绕开防火墙。这个描述的两半都以同样的方式错了。分流隧道是客户端做出的路由决策，而路由决策完全不能说明数据包到达 headend 之后会发生什么。

只要有一个位于公网地址的合作伙伴服务坚持要看到你总部的地址，这套说法就不攻自破。

迷思：分流隧道让防火墙不再处于路径上

人们相信，私有网段之外的任何目的地都会走本地互联网连接，因此防火墙永远看不到它，也永远不需要为它配规则。这只在目的地不在隧道列表里时成立。运维一旦把公网主机加进 split-include ACL，客户端就会把该流量送进隧道，ASA 就必须像处理其他任何解密后的流一样，对它做路由、过滤和地址转换。客户端上唯一改变的只有目的地列表。

客户端并没有变成路由器。它只是执行了你给它的策略。

split-include 路由实际做了什么

在 Cisco ASA 远程接入配置中，组策略携带 split-tunnel-policy tunnelspecified 以及指定标准 ACL 的 split-tunnel-network-list。该 ACL 中每一行 permit 都是客户端应当送进隧道的目的地，其余流量继续使用本地默认路由。

添加一台主机只需一行，而这正是客户端唯一能看到的改动：access-list RA-SPLIT standard permit host 203.0.113.20。

之后请重连客户端。策略是在连接时交换的，因此已建立的会话会保留旧列表，让这次改动看起来毫无效果。

数据包从同一个接口进出

现在跟踪解密后的流向。数据包经 VPN 隧道从外部接口进入，目的地是公网地址，路由表又把它从同一个外部接口送回互联网。进出同一接口的流量默认会被丢弃，除非允许 ASA 这样做，而 same-security-traffic permit intra-interface 正是做这件事。没有它，连接会以看似路由问题、实则不是的方式失败。

该设置是全局的。它为所有需要 hairpin 的流量放行，而不只是这台合作伙伴主机，因此它属于需要评审的变更，而不是快速测试。

为什么限定目的地的 PAT 不是可选项

解密后数据包的源地址仍是客户端 VPN 地址，通常来自 10.77.0.0/24 这样的地址池。该地址在公网上没有路由，所以合作伙伴要么永不回应，要么回应到空处。

地址转换修正源地址，并保持目的地址不变。由于对象已在别处定义，一条限定到该目的地的手动规则形如：

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static 这部分很关键。去掉它，规则就会变成宽泛的转换，可能匹配到远超预期的流量，而顺序更靠前的宽泛 identity 规则可能完全压过它。在认定你的规则就是匹配的那条之前，请检查 show nat detail 和各节顺序。

接口 PAT 还意味着合作伙伴看到的是 ASA 接口地址，该地址可能在上游再次被转换。如果合同指定了地址，请端到端确认，而不是只看一跳。

用正确的测试目的地来验证

请使用合作伙伴主机本身，而不是通用的 what-is-my-ip 页面。那个页面几乎肯定在分流列表之外，因此它报告的是你的本地互联网地址，对这条路径毫无说明。向合作伙伴服务新建连接，询问他们观察到的源地址，或者运行 packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed，逐行阅读 NAT 和路由各阶段。从客户端做 traceroute 是较弱的检查，因为它展示的是已经发生的路径，而不是选择该路径的策略。

然后检查哪些东西不应该变。普通网站仍须从本地连接出去，隧道列表内的私有资源仍须可达。修好合作伙伴却弄坏这两者之一的改动，是另一个缺陷。

这个设计的可用版本很短：split ACL 里一台主机、hairpin 许可、一条限定目的地的 PAT 规则。故事里的其余部分都是迷思。