Access Server 网关用户：为客户端的分支 LAN 配置路由

你可以 ping 通 OpenVPN 客户端的隧道地址，却仍到不了它后面 LAN 上的任何主机。Access Server 从 VPN 池分配地址，而池地址是服务器唯一确认己有的部分。分支前缀需要单独声明，声明之后分支仍需要转发方，总部仍需要回程路径。写在错误位置的路由看似解决方案，却什么也不改变。

两个地址，两种所有权

客户端连接时，Access Server 从已配置的池分配地址，例如 10.90.0.0/24。这只是给一台主机的租约。连接并未说明同一客户端也位于 10.60.0.0/24 之前，服务器也不会猜测：只有管理员声明，LAN 前缀才能经由某台特定客户端到达。

因此在别的机器上添加静态路由无济于事。该路由说把 10.60.0.0/24 发往此地址，但若该地址属于从未被标记为网关的客户端，服务器没有理由把数据包送到那里，客户端协议栈还可能丢弃。声明与路由是同一机制的两半。

网关设置究竟安装了什么

在 Admin Web UI 中，声明是用户属性：在 connector 用户上启用 Configure VPN gateway，并在 Network on the VPN client side 填入分支真实前缀。该用户与其他用户一样认证，因此需要适合无人值守设备的凭证策略，自动登录配置属于机密。

服务器据此认为该前缀可经该客户端的池地址到达，Access Controls 下的路由配置决定向他人通告什么：推送给普通客户端的路由，以及允许总部网络访问客户端地址的规则。只为确实要到分支的网络启用路由，并让允许列表保持简短。

粘贴进生成文件的 Community 风格指令不参与此模型。产品拥有它推送的路由表；手工修改的行会被覆盖或忽略。

补齐两个网络的回程

具体方案：总部 10.40.0.0/24，分支 10.60.0.0/24，VPN 池 10.90.0.0/24，Access Server 位于总部一侧的私有地址。总部路由器需要通往分支前缀与池的路由。缺了它们，隧道会送出请求，而 应答从默认网关离开，构成典型的半开连接。

分支侧 connector 必须转发并非发给自己的数据包：操作系统中的 IP 转发，以及仅限隧道与 LAN 接口的许可；Linux 上是 net.ipv4.ip_forward=1 配合 forward 链规则，Windows 上是 routing and remote access。随后主机需要回程：要么 connector 是其默认网关，要么现有网关承载具体路由。

connector 的路由表不会重新配置分支 LAN 上的每台主机。如果主机指向别的路由器，回程路由就属于那里，而且它必须接受所见源地址并非本地子网邻居。

把失败当作路径来读

按固定顺序测试。先从 Access Server 到分支主机的已允许服务，再从总部普通主机测同一服务，最后在策略允许时测反向。若前者通过而后者失败，问题在推送的路由或访问规则。若两者都通过却没有应答，检查分支的转发与总部的回程。

接着怀疑主机防火墙：在被路由的访问里，目标看到的源是总部或池地址，为本地子网写的规则不会匹配，数据包被丢弃。

两种设计需要更多工作。站点间前缀重叠会让目标含糊，需要重新编址或转换；集群式 Access Server 要求每个节点都有通往分支 connector 的可用路径，而非只有一个节点持有路由。请通过正常的保存与更新路径应用改动，重连 connector 并从两端验证；重启每台机器并不是流程的一部分。

Access Server 的 site-to-site 教程按产品顺序列出同样的设置。