用路由器还是单独一台电脑做 VPN 服务器：如何选择

路由器和一台小电脑都能终结 VPN，而决策很少取决于吞吐量。它取决于谁在凌晨两点打补丁、那台设备重启时还有什么会停，以及当坏掉的正是隧道本身时你还能不能连上控制台。为每个候选回答这三个问题，选择通常就自己浮现了。下面的流程把比较变成一份在动手之前可以逐项核对的小清单。

先想清楚隧道失效时什么必须继续可用

需要为之设计的故障，是 VPN 进程死掉、而你仍然必须够到那台主机。在路由器上，隧道和上网网关同呼吸共命运：一次配置失误就可能把两者一起打掉，而恢复手段往往是物理复位。在单独一台电脑上，网关照常工作，主机仍然可以经局域网访问。你能接受哪一种结果，比任何功能清单都更能决定选择。

把答案写成一句话：如果 VPN 主机重启，家庭或办公室会失去什么？如果答案包含全部上网能力，那你就接受了一个共享的故障域，应当主动说明，而不是事后才发现。

同一台设备上的第二个服务不是备用控制台。它共享电源、固件和管理员账号。

数一数每种主机各自新增的维护面

路由器带来厂商固件，有自己的发布节奏，而 VPN 功能通常只是更大镜像里的一个模块。电脑带来操作系统、包管理器、内核，以及一整套从此归你维护的服务。两者都要打补丁，真正的问题是新鲜劲过去之后你还能坚持哪种节奏。

在 Linux 主机上，让这个节奏可见，而不是指望它。systemctl list-timers 显示已排期的任务，apt list --upgradable 显示还在等待的更新。记录哪些更新需要重启，因为 VPN 主机重启就是服务中断，除非你早有安排。没有无人值守更新通道的路由器，则需要在日历上记一笔——这种管控更弱，但更诚实。

账号也要数。VPN 主机上每多一个管理员登录，就多一份需要轮换的凭据、多一条需要撤销的路径。

跟住私有网络的路径，而不是设备上的标签

客户端并不在乎服务器跑在哪，它们在乎受保护的网段能否到达、有没有回程路径。把服务器放在路由最简单的地方，通常就是直接放在承载资源的那一段。路由器后面的电脑仍然需要端口转发，那个局域网里的资源也仍然需要回到隧道子网的路由。

先查主机上的转发，再怪客户端。sysctl net.ipv4.ip_forward 应当报出 1，nft list ruleset 或 iptables -S 则显示隧道接口到底有没有被允许转发。少一条 masquerade 规则，从客户端看就和隧道坏掉一模一样。

还要定下隧道不该够到什么。放在路由器上的服务器能看见该路由器路由的每个子网，这往往超出访问策略的本意。在单独主机上，同样的隔离只差一条防火墙规则，被攻陷客户端的影响半径也更小。RFC 7296 中 IPsec 网关的描述把这件事当作路由与策略问题，而不是硬件问题；在策略写下来之前，两种形态谁都不默认更安全。

留一个不依赖隧道的恢复控制台

你用来修 VPN 的控制台，不能就是 VPN 本身。准备一个在隧道挂掉时仍然可用的局域网地址、串口控制台或服务商控制台，并在真正需要之前至少用过一次。从未演练过的带外路径只是计划，不是能力。

把配置备份到主机自己删不掉的地方。tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn 会抓住密钥和服务定义，而副本必须离开这台机器。把防火墙规则和客户端清单也带上，因为只恢复密钥、却没有对端列表，得到的是一台谁都连不上的服务器。把归档放在恢复控制台够得到的地方。

把回滚步骤写进同一份笔记。没有书面回滚步骤的配置变更就是永久变更，不管初衷如何。

用一次重启和一次更新来验证选择

要按它会坏的方式测试，而不是按它顺利时的方式。重启主机、应用一个待装的更新，然后确认隧道无需手工步骤就能回来。

重启之后，检查最容易坏的三件事。systemctl is-active wg-quick@wg0 报告接口是否回来，ss -lunp 显示端口上有没有在监听，wg show 列出完成握手的对端。服务处于活动状态却没有握手，说明错的是防火墙或路由，而不是守护进程。

换一个与你配置时不同的网络，从那个网络的客户端再检查一遍。如果隧道扛过了重启、更新和客户端换网，主机选择就算暂时定了。如果没有，缺的通常是一步写下来的操作，而不是另一台设备。