站点间 VPN 正常，但 ASA 日志不来：先查源地址

内部主机能到达远端收集器，syslog 也出现了。可 ASA 自己关于同一会话的消息却从不出现。收集器和隧道都没有问题，这正是让人困惑的地方。防火墙的日志是从一个隧道从未打算保护的源发出的。

什么会到，什么不会到

先把仪表盘上看起来一样的两条流分开。转发的流量穿过 ASA：LAN 主机发往收集器，ASA 按隧道策略匹配、加密，收集器看到的是主机的地址。生成的流量则始于 ASA 本身：设备自己构造 syslog 报文，选择出接口和源地址，然后才去问有没有匹配的隧道策略。第一条流证明隧道是通的，却完全不能说明第二条。

设备上被缓冲的事件同样不能证明已经送到远端，因为日志可能只存在本地、从未发出。在责怪隧道之前，先看收集器的接收计数，空计数和持续增长的计数是两种完全不同的结论。

生成的报文不是转发的流量

当 ASA 自己构造报文时，它并不是在替某台 LAN 主机做代理。源地址来自出接口或显式的源设置，报文要经过和其他所有本地发出的流量相同的路由查找和策略检查。这意味着 VPN 选择器必须包含 ASA 实际使用的地址，而它往往是外部接口，而不是内部子网。

如果策略保护的是 10.20.0.0/24，而 ASA 用外部地址作源，日志报文要么以明文发往它到不了的收集器，要么直接被丢弃。两种情况从收集器一侧看完全相同。同样的道理也适用于管理流量，所以 management-access 是一个独立的设计决定。

ASA 把哪个源放到线路上

用实测而不是假设去找源。在发测试消息时于出接口抓包，能看到真实的源和目的，比读三节配置省时间。把这个地址和隧道的本地选择器对一对。

某些版本允许把日志源绑定到接口，你的版本对应的命令参考才是判断该选项是否存在、会改变什么依据。别的 Cisco 平台上的 source-interface 命令在 ASA 上并不自动有效。

如果确实要改源，就刻意地改并记录下来，因为收集器的 ACL 和任何基于 syslog 的关联都依赖它。

让选择器和日志流对齐

源确定之后，按顺序检查三件事：决定哪些流量值得关注的加密 ACL 或基于策略的选择器、决定报文去向的路由，以及可能在加密前改写源地址的任何 NAT 规则。匹配路由但不匹配选择器的报文不会进隧道，而被 NAT 改写过的报文可能两者都不匹配。

收集器一侧也有自己的要求：允许 ASA 源地址的 ACL、回程路由，以及在你配置的端口上监听的日志服务。传输方式在这里同样重要，因为在部分被阻断的路径上，TCP 和 TLS 日志与 UDP 的行为不同。每次只改一个要素，否则下一次抓包就说不清是哪个改动起了作用。

在收集器上确认，再把源记录下来

确认消息能到，然后写下 ASA 使用的源地址、承载它的选择器，以及测试时用的严重级别。

这份记录能让下一次收集器 ACL 变更或选择器调整变成两分钟的核对，而不是重新摸索。它还写明了这两条流里究竟哪一条被验证过，而这恰恰是大多数运行手册漏掉的部分。如果消息还是不来，临时降低严重级别阈值，并对单个目的地址做测试。

Cisco 的 ASA 日志常见问题 记录了一个源在外部、需要相应受保护流量定义的案例，其内部源示例则同时包含内部日志主机和内部 management-access。要把文档中的组合与软件上下文一起看，而不是假定复制来的一行适用于所有配置。

承载 LAN 流量的隧道，不是承载防火墙自己声音的那条隧道。