站点到站点 VPN 上的 ASA DHCP 中继：分步讲解

中继分三个环节运行，只有中间那个环节穿越 VPN。客户端在分支网段广播，ASA 把该广播变成发往 DHCP 服务器的单播请求，服务器则回复中继地址而不是客户端。按这个顺序走一遍，大多数「中继坏了」的情况都会归结为缺少策略或读错了 setroute 那一行。

第一个环节：在面向客户端的接口上启用中继

在分支 ASA 上，中继是面向客户端那个接口的属性。服务器可以在全局声明并指定可达接口，也可以声明在该客户端接口之下，让路由表选择出口。这两种写法不能互换，抄错一种就是排查第一次走偏的地方。

改动之前先看运行配置：哪个接口启用了中继、存在的是哪种服务器写法、setroute 是否挂在客户端接口上。如果 ASA 同时为另一个网段运行 DHCP 服务器，请停下来读一遍限制清单；服务器与中继不能在同一台设备上同时启用。

中继会把自身面向客户端的地址写进网关地址字段。服务器回的正是这个地址，所以它必须能从远端站点经隧道抵达，而不只是本地可达。

第二个环节：让 ASA 自己产生的流量走隧道

这一步常被跳过。基于策略的站点到站点 VPN 通常是为子网之间的流量建的，而中继请求是 ASA 自己产生的。如果隧道的访问列表和 crypto map 只匹配分支主机到服务器子网的流，中继报文可能根本进不了隧道。访问列表要双向检查，不能只看分支到服务器那一条。

确认感兴趣的流量覆盖 ASA 的中继源地址与服务器地址，回程方向也已放行。在基于 VTI 的设计里路由判断更简单，但 VTI 上的中继支持是某个特定版本才加入的；ASA 的 DHCP 指南 指出是 9.14(1)，所以在把 VTI 示例照搬到较老设备之前先核对镜像。

从 ASA ping 服务器本身证明不了什么。它可能走另一条路径成功，用另一个源地址，或者在一条中继报文并不匹配的策略下成功。

第三个环节：读懂响应和 setroute 选项

RFC 2131 规定，当该字段非零时，服务器把响应送到 giaddr 中的地址。因此 回程路径必须把流量路由到中继地址，并且隧道策略要允许服务器到中继这个方向。如果请求过去了而 offer 始终不来，就该在这里找原因。

接下来把两个听起来很像的东西分开。setroute 关键字改变或添加 ASA 交给客户端的默认路由选项。它不在 ASA 上装路由，也不创建 VPN 策略。拿到地址却什么都访问不到的客户端，问题往往出在 setroute 或作用域上，而不是隧道。用一个没有静态网关的客户端测试，观察 offer 里出现的是哪个默认路由器。

把 offer 从头读到尾：分配的地址、掩码、默认路由器、DNS 和租期。然后让租约续期。一次能通、续期就失败的场景，通常藏着第一次交互掩盖的作用域、租期或回程路径问题。

在宣布修好之前我核对什么

从客户端出发抓广播，再确认 ASA 用自己的地址作为 giaddr 做了中继。在远端确认服务器看到了该请求并选择了与分支匹配的作用域。回到分支确认客户端接受了 offer 且能到达网关。

哪个环节没有声音，就去查对应的策略或路由，而不是再加一条中继语句。等有人升级问题时，中继配置通常已经是对的；变的是隧道策略或回程路由。

把三个环节写进变更记录：面向客户端的接口、覆盖中继流量的 VPN 策略，以及服务器回到 giaddr 的路由。正是这份记录让下一次分支建设成为可重复的工作，而不是一次调试。它也告诉下一位工程师先采集哪条命令的输出。