用 DHCP 选项 121 为 LAN 主机下发 VPN 回程路由

远程 VPN 客户端接入，LAN 服务器作出应答，而这个应答从普通的上网路由器出去，就在那里死掉。单台服务器可以用一条静态路由修好，但整段服务器子网最好在它们本来就获取网络配置的地方处理。DHCPv4 的选项 121 分发的正是这种目的路由，而人们一旦忘了默认路由，出错的地方通常就是它。症状是单向流量：请求能进来，应答却消失了。

先把三个地址说清楚

取一个具体的 LAN：192.168.50.0/24，默认路由器照常在 192.168.50.1，另有一台独立的 VPN 网关在 192.168.50.2。已通过认证的远程客户端占用 10.90.0.0/24。

每台参与的主机需要的路由是 10.90.0.0/24 via 192.168.50.2。目的地是客户端池，下一跳是网关的 LAN 地址，而不是它的隧道地址。

把它编码成无类静态路由

选项 121 携带前缀与下一跳的配对，RFC 3442 既定义了编码方式，也定义了随之而来的客户端行为。对于只服务这个示例 LAN 的现有 dnsmasq 实例，配置的形态是：

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

这只是一个片段，不是新的 DHCP 服务。在服务多个网段的服务器上，请用你已经在用的标签或网络策略限定这个选项。把改动前的配置留在手边，因为回滚意味着再来一次租约续期，而不是重启。

别把默认路由弄丢

陷阱就在这里。收到选项 121 的客户端必须忽略常规的 Router 选项，所以只通告 VPN 池的路由，可能 让那台主机完全没有默认路由。机器看起来仍然配置完好，却悄悄失去互联网。用户会把这种情况描述为网络挂了，尽管每个接口都是通的。

像上面的片段那样，把想要的默认路由放进同一份列表。也要保留常规的 Router 选项，供不实现无类路由的客户端使用；究竟发给谁，由服务器自身的选项处理决定。

确认客户端会接受什么

手动配置地址的主机永远不会接收这一项，因为它根本不申请租约。客户端的支持程度也各不相同，所以要在你实际运行的操作系统上测试，而不是假定每台设备都遵循选项 121。向那些服务器的所有者确认哪些是静态地址。那些主机需要自己的路由条目，否则就干脆不参与。

受管的 DHCP 服务是另一重限制。有些云网络不允许管理员发布任意选项，而同一网段里存在竞争的 DHCP 服务器，比完全没有选项更糟。

先验证租约，再验证查表

请 DHCP 的负责人应用改动，然后在客户端上续租。已有租约在续期之前会一直保留旧配置，所以不要指望立刻见效。

在 Linux 客户端上读取实际路由，并确认两条记录：

ip -4 route
ip -4 route get 10.90.0.23

按上下文查表应当显示经由 192.168.50.2 的池路由，以及经由 192.168.50.1 的默认路由。如果默认路由缺失，你就复现了上面的陷阱。

再测真正的收发

路由下发并不是全部路径。独立的网关仍然需要转发、远程对端归属，以及允许该服务器的访问策略，而 DHCP 不认证任何人。

最后，留一份拆除方案。学来的静态路由不会在 VPN 断开时自动撤销，所以过期的下一跳可能在隧道消失很久之后，仍把该前缀变成黑洞。