ASA VPN hairpin：通过一个接口路由两条隧道

远程用户连接到 ASA，请求一个分支机构后面的主机，而 ASA 从该用户进入的同一个接口把请求发出去。做到这一点不需要第二个物理端口。它需要的是四个相互独立的决定，而人们往往把它们合并成一个：允许 hairpin、一条保护正确地址的隧道、一条保住你所承诺源地址的 NAT 策略，以及一条授权该服务的访问策略。

一个数据包，两条隧道

跟着流程走，操作顺序就不再神秘。数据包在远程访问隧道内到达，被解密，变成一个源地址来自客户端地址池的普通 IP 包。随后 ASA 为它做路由，与站点到站点的 crypto ACL 匹配，再次加密，并从外部接口发往分支。

下面的地址只是示例，但结构很重要：源是地址池，而不是 ASA 的内部局域网。

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

由此引出两件事。客户端需要通过自己的远程访问连接获得通往分支前缀的路由，也就是 split-tunnel 或推送的路由列表必须包含它。而分支必须知道如何把流量送回 10.77.0.20，或者送到你的 NAT 设计所替换的地址。

hairpin 许可是全局的

人们常用的命令是 same-security-traffic permit intra-interface。它允许流量从同一个接口进出，而这正是这条路径所需要的。它同时也是一个全局设置：启用它会改变其他恰好两次经过同一接口的流的行为。

所以它应当出现在变更记录里，而不是调试会话里。要问清楚：设备上还有什么现在可能走同接口的路径，其中是否有些应该走。在有访客网络或相互重叠的合作伙伴隧道的繁忙边界上，答案并不自动是“不”。把理由写在设置旁边，因为下一位工程师会找到命令，却找不到当时的对话。

保护范围与 NAT 是分开的

站点到站点隧道保护的是它的 crypto ACL 所选择的内容。如果该 ACL 把 ASA 的内部子网列为源，远程访问地址池就不在保护范围内，数据包要么被丢弃，要么被明文发出，取决于平台对不匹配流量的处理方式。当设计要求保留地址池地址时，把地址池加入受保护的流。

接下来 NAT 决定地址池地址是否保留。Identity NAT 会保留它，分支看到源就是 10.77.0.20。地址转换则改变了约定：分支现在把流量送回转换后的地址，它自己的策略必须接受这一点。规则顺序决定 crypto ACL 在转换之前还是之后匹配，所以要读实际生效的流，而不是假定哪一条赢。

不要为了打通一个中转场景就删除通用的互联网 PAT 规则。有针对性的豁免或一条刻意的 identity 规则，比在出站策略上开一个洞更容易解释，也更容易回退。

加密不是授权

一条能用的隧道只证明两个对端在密钥和选择器上达成一致。它完全不能说明这个用户是否可以访问那个服务。绑定在远程访问连接上的 VPN 过滤器或组策略仍然必须允许分支的目标和端口，外部路径上的接口 ACL 也依然生效。

把答案从两个方向都测一遍。当邻近的服务本应失败、而某条连接却成功时，这比一次成功的 ping 更有信息量，因为它说明策略是有选择性的，而不是完全敞开。如果本应被拒绝的测试却成功了，问题不在隧道，而在策略。把两个结果都留在变更记录里，下一个人才能知道哪种行为是预期的。

hairpin 还是第二个接口

hairpin 中转让设计保持小巧，代价是一个全局设置。单独的接口，或者带自己虚拟接口的基于路由的隧道，可以隔离中转路径并给你按接口的策略，代价是地址规划以及另一份 crypto map 或配置。两者没有哪个更正确，它们失败的方式不同。

基于路由的设计是另一种布局，而不是在同一份配置上打个勾。如果你改用这种设计，上面关于基于策略的 crypto ACL 的讨论就不再适用，路由表开始承担选择工作。

从真实客户端验证

从 ASA 发起的探测使用不同的源地址，不会走地址池到分支的路径。用 packet-tracer 来检查五元组，然后从实际的远程客户端打开真实连接，因为追踪器只是模拟，不能替代客户端自身的路由和策略。

在一次计划内的变更之后，先连接本应可用的服务，再连接本应被拒绝的服务，然后确认分支的回程路由。Cisco 的 VPN hairpin NAT 示例 把 intra-interface 许可、NAT 和 ACL 清楚地分开，这才是值得照搬的心智模型。