当远程访问客户端必须充当分支机构网关时

一台连接 VPN 的笔记本电脑可以访问总部。同一张桌子上的打印机和文件服务器却不行，因为没有任何组件把它们的报文转发进那条隧道，也没有组件把回复带回来。把客户端变成分支机构网关，首先是一项路由与责任归属的决策，其次才是配置决策。设备上标注的协议名称，并不能回答该角色是否受支持。

协议标签不会告诉你的事

OpenVPN 文档描述了一种站点到站点设计，其中连接器转发整个子网，Access Server 则通过网关角色和显式路由来实现它。另一种以 SSL VPN 名义销售的产品可能只提供远程用户功能，没有受支持的方式通告客户端背后的网络。版本同样重要，因为某个发行版中存在的功能并不构成对另一个版本的承诺。要阅读你实际运行的实现，并把为其他产品编写的配方视为线索，而不是设计方案。

首先要确定的问题是，VPN 的所有者是否根本支持转发角色。如果不支持，无论客户端侧做多少路由，都不会让它变得受支持。

这份约定有两边：分支机构与总部

在分支机构一侧，由一台主机负责转发、过滤和恢复。它需要一条从每台分支机构设备出发的明确路径，而外层 VPN 连接即使在隧道中断时，也必须能通过底层网络保持可达。在总部一侧，必须有人定义分支机构子网、接受网关的身份，并放行特定资源。任何一半都无法单独成立。

返回路径是常被跳过的那部分。客户端的隧道地址并不会通告它背后的子网，因此总部路由器需要一条指向该前缀的 VPN 网关的路由。

在路由式设计中，集中器转发分支机构前缀的报文，上游 LAN 路由知道如何把回复送回。在转换式设计中，总部看到的源地址会被改写，这可能省去一条返回路由，却隐藏了是哪台分支机构机器发出了流量。这一取舍应写入设计文档，因为一旦引入地址转换，应用日志和访问规则就会失去逐设备身份。

路由式还是转换式：有意识地选择返回路径

当逐设备身份和逐主机策略很重要，并且你能在每台相关路由器上维护返回路由时，选择路由式。

当你无法增加路由，但可以接受总部只看到一个源地址时，选择转换式。混合设计确实存在，而且更难推理，所以要写明哪些前缀走路由、哪些走转换。然后用两端的抓包来验证这一选择，而不是相信隧道状态。

一项有用的检查是不对称的：从分支机构设备请求某个资源，然后确认回复从总部朝分支机构前缀发出。在总部主机上执行 traceroute -n 10.60.4.20，可以看出该路径是否经过 VPN 网关。

像运营基础设施那样运营它，而不是一次登录

要决定网关在无人登录时如何启动、认证、更新和恢复。凭据续期、多因素提示、睡眠行为，以及分支机构失去访问时由谁响应，都会成为运维问题。多个共享同一条网络路径的人绝不能继承网关用户的个人权限，因此资源授权、日志范围和故障策略都需要有明确的责任人。为避免逐设备注册而共享账户，不是一种设计。

把它与 受支持的站点网关 按同样的要求做比较，然后再作决定。重复使用旧台式机并不会消除维护或恢复工作，二手价格也说明不了运营成本。

在经批准的计划下，验证拟用的分支机构应用、它们的返回流量，以及一个被拒绝的目的地。成功的样子是一项有归属的网络服务，具备具名的分支机构身份和明确的策略，而不是一个显示 Connected 的客户端窗口。