为什么 ASA 自身的 TACACS+ 请求不经过分支 VPN 隧道

分支隧道已经建立，用户可以对着远端 TACACS+ 服务器完成认证，但防火墙自身的登录却仍然超时。原因并不是隧道有缺陷：LAN-to-LAN 隧道只承载与选择器匹配的流量，而 ASA 关于自身生成的管理流量是一条独立的流，拥有自己的源地址。多数团队是在变更窗口里才发现这一点，因为唯一的管理员账号恰好就是失败的那个。请把 ASA 发起的 AAA 会话当作一条需要设计出来的流，而不是已经打通的连通性的副产品。

ASA 自己就是客户端，自身流量的路径需要单独设计

防火墙联系 TACACS+ 服务器时，它和任何客户端一样，只不过没有人刻意给它配置过路由。它的报文从设备上的某个接口地址发出，是在本地生成而不是转发，因此必须像用户流量一样被路由、被转换、被策略保护。保护用户子网的站点到站点隧道并不会自动保护这个管理源，因为流量的选择依据是地址，而不是意图。

把你期望服务器看到的地址写下来。如果你没法用一行说清楚，说明你还没有设计。

aaa-server 行里的接口不是装饰

在 ASA 上，aaa-server 的 host 条目会在括号里接收一个接口绑定，Cisco 的AAA host 命令参考把它描述为认证服务器所在的接口。正是这个绑定把请求与某个接口、以及该接口所应用的策略关联起来。按照面向互联网的那个接口去选，或者沿用上一次迁移留下的值，得到的源地址根本不是远端服务器和隧道为之设计的地址。

只有当被指定的接口持有你打算用作源的地址时，inside 才是正确答案。在分支设备上通常如此；在有多个私有网段的设备上则未必。

改绑定等于重建条目

同一份命令参考还记录了一条在割接时容易踩到的编辑限制：修改已有主机的接口，必须先删除再重建该 host 条目。看起来改过的配置可能并没有生效，下一次登录仍然从旧地址发出。请把它计划成删除后再添加，并把原始条目的副本摆在面前，而不是原地微调。

如果定义了多台服务器，先改一台并验证，再去动其余的，这样一次失误不会同时锁死所有管理通道。

把选择器、地址转换和返回路径放在一起核对

请求要到达，三件事必须一致。隧道的流量选择器，或者你使用的隧道接口保护，必须包含 ASA 自身的源地址和服务器地址；按用户子网构建的选择器列表通常不包含。路径上的任何 NAT 规则都必须一致地转换这个源，因为服务器授权的是包含它所看到地址的网络设备身份。返回路径也必须存在，在基于策略的隧道上，这意味着对端要有反向匹配的选择器。

在服务器侧，分别确认设备身份、共享密钥和管理策略。TACACS+ 把认证、授权和计费当作彼此独立的操作，因此一次完整交互之后才到来的拒绝是策略层面的答复，而不是传输故障。把它当作网络问题去读，会让你找错地方。

排障期间把密钥挡在抓包、工单和会话记录之外，并记住服务器记录的源地址正是你的设计必须解释的那个地址。

在不把自己锁在外面的前提下完成变更

修改远程管理认证时，使用控制台或一条独立的管理通道，并保留一个已批准的本地兜底方案，直到新路径真正承载过一次登录。然后小范围验证：一台服务器、一台设备、一次成功认证，且两端都观察到同一个源地址。

把这条流单独记录在一页上：发起接口与地址、远端服务器、受保护路径，以及授权策略的负责人。这样以后改动接口或隧道时，就能判断它影响的是两条流中的哪一条，而不必靠猜。