在不中断通话的前提下，于运营商路由器旁增加站点 VPN

多数小型站点本来就有一台设备同时负责上网、DHCP 和语音线路，而这台设备不会去跑站点隧道。为私有路径再加一台网关是可行的，前提是在动网线之前就定好每条路由归谁。真正的风险不是隧道，而是悄悄换掉那台维持话机注册的设备。按顺序做完五项检查，哪一项失败就停在那里。

先把已经在工作的角色写下来

记录默认网关、DHCP 服务器、解析器，以及持有运营商语音注册的设备。本例中 ISP 路由器是 10.50.0.1，新网关将位于 10.50.0.2，远端站点是 10.60.0.0/24。该方案不改变前三个角色，关键正在于此。随后确认第二台设备确实能终结你需要的隧道：看协议、预期吞吐量，以及它是否能获得固件或软件包更新。只有 VPN 标志却没有更新途径的设备是负担，不是增益。

如果你说不清语音服务归谁，就停下。在没有回退方案的情况下更换承载注册的路由器，会把 VPN 项目变成电话中断。

让新网关只有一个地址、一项职责

把它的 LAN 地址保留在 DHCP 池之外，避免重启后漂移；除非你想让它成为上网出口，否则不要给它自己的默认路由。它的职责是守住隧道，并为远端前缀作答。在必须访问远端站点的 LAN 主机上，先证明它们现在走哪条路，再证明改动后你希望走哪条；同样两条命令在改动前后各跑一次，是最便宜的证据。

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

如果查询返回的是 ISP 路由器，且 traceroute 在互联网边缘终止，说明主机还没有远端路径，这符合预期。如果返回了意外结果，先解决它，因为后面每一步都以这个基线为前提。

选定远端前缀路由归谁

方案 A 是 ISP 路由器：它为 10.60.0.0/24 保留一条指向网关的静态路由，每台主机照旧走自己的默认网关。方案 B 是按主机配置：只有需要远端站点的机器获得经 10.50.0.2 的显式路由，其余一切保持不变。A 在主机很多时更整洁，但通常要求运营商路由器接受静态路由，有些设备不接受。B 不需要运营商配合，但主机配置的维护落在你身上，因此适合一小批经过批准的机器。

两种方案都必须存在回程方向。若远端应答到达网关，而网关直接转给 LAN 主机，流量就绕过了 ISP 路由器在去程上维持的防火墙状态。当网关不是 LAN 的默认路由器时，这种不对称是设计决定，不是可以忽略的缺陷。

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

通过主机的配置管理来持久化这条记录，不要依赖登录脚本。只在某人登录后才存在的路由，会在机器因无关原因重启时第一次就失效。

准备一个可达的入站端点

网关需要一个远端站点能到达的地址。在 ISP 路由器后面，这意味着端口转发或 DMZ 条目，而两者都取决于运营商是否真的把流量送到你这里。本地转发无法突破运营商侧的运营商级 NAT。如果运营商不给可达端点，就反转方向：让两端都主动连向你掌控的集线点。这是有效的设计，但它为转发、信任和可用性增加了第三重依赖，动态 DNS 并不能替代它。

用网关上的抓包确认转发，不要用扫描端口的网站。监听未绑定前，扫描器会报端口关闭；而从不投递流量的转发，从外面看和关闭的端口一模一样。

同时接受私有服务与语音线路

从 LAN 主机测试预期业务，使用私有 DNS 和应用自身的凭据。被路由的隧道不会让远端浏览看起来像本地以太网段，所以发现与名称解析需要各自的安排。

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

然后确认同一台主机上的日常上网仍然可用，且话机仍处于注册状态；这两项检查能抓住意外的默认路由变更，那正是本项目弄坏它从未想碰的东西的最常见方式。最后写一份恢复说明：哪台设备承担哪个角色、保留的地址，以及如何一步移除远端前缀路由。一条能干净撤回的私有路径，比一条只在今天可用的路径更有价值。