通过 ASA 站点到站点 VPN 发布内部服务

在站点到站点 VPN 后面发布一项服务，是一件包含五个故障点的事，而它们会按固定顺序出错。隧道起来了，转换对上了，分支回应了，回应沿同一条路径返回。其中任何一项不对，浏览器看到的都一样：连接挂起或被重置。从上到下走这份清单，在第一个不通过的检查处停下。

检查 1：隧道保护了源地址

先从一个已经在传流量的隧道开始，然后确认你打算发布的地址位于受保护网段之内。在 ASA 上，该网段来自加密 ACL 或 VTI 的路由，它必须覆盖源的真实地址，而不是分支用于管理的那个子网。选择器漏掉源，就会给你一条已建立却不承载该流量的隧道。

在动转换之前，先用隧道计数器和路由表确认。如果从中心经隧道到不了源，这份清单后面任何一步都补不回来。

如果受保护网段与源地址不一致，就停在这里。

检查 2：确定分支将看到哪个源

分支看到的要么是客户端原始地址，要么是转换后的地址，这个选择决定了回程路径。保留客户端地址在源侧日志里读起来更干净，但分支必须把面向公网客户端的回应经隧道送回；普通互联网默认路由会把它们送向另一边，连接只在一个方向上断掉。把源转换成分支已经通过隧道路由的地址，就消除了这个要求。

转换还会改变源能记录什么，以及基于源的规则能匹配什么。如果应用需要知道请求背后的人，那属于经过认证的反向代理，而不是 NAT 决定。

检查 3：按真实接口写转换

ASA 按顺序评估转换规则并报告哪一条命中，所以规则里的接口对并非摆设。为从外到内的路径写的规则，不会匹配入口和出口与你假设不同的流量。

你要建的路径有四段，四段必须一致：

把表中的网段当作占位符。关键在于转换后的元组是分支愿意通过隧道接受的地址，而且反向映射存在于 NAT 状态中，使回应在出去时被还原。

检查 4：把访问规则限定在已发布的端口上

发布端口，而不是主机。一条对每项服务都放行源的规则，会把一个已发布应用变成通往源上所有内容的路径，包括你特意留在互联网之外的管理界面。只放行从转换后源到源的已发布端口，让管理服务留在仅经 VPN 的路径上。

同时检查规则顺序。一条宽泛的放行规则压在具体规则之上，会让具体规则形同不存在。

检查 5：跟踪一个请求及其回应

不要从浏览器开始，因为浏览器会掩盖是哪一段失败。在中心跟踪这条流，并在改动任何东西之前先读结果。

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

跟踪会指出命中的转换、放行或拒绝该流的访问规则，以及报文是否被路由进隧道。如果显示流量从你没预料到的接口离开，说明 NAT 规则里的接口对写错了。如果显示拒绝，说明规则顺序错了。如果进了隧道但源始终不回应，问题在分支的回程路径。

然后从外部发一个真实请求，确认回应经同一条隧道回来。把已发布条目、转换、受保护地址对和回程路由记录为发布记录。