在 Linux 上启动 VPN 时究竟会发生什么

按下连接，Linux 机器上会有三件事发生变化：出现一个接口，装好路由，解析器开始以不同方式应答。多数配置失败都源于这三件事中有一件发生而其余没有，或者两个程序对它们归谁管无法达成一致。理解这个顺序，比读客户端的日志输出更快地解释故障。

在任何东西开始工作之前，接口先出现

隧道客户端打开一个虚拟接口，把数据包交给它。TUN 设备承载 IP 数据包，这是路由型 VPN 需要的；TAP 设备承载以太网帧，这是桥接型设计需要的。内核模块提供该设备，客户端在会话持续期间拥有它。

接口起来并不等于隧道能用。即使对端不可达，接口也可以带着地址存在，所以接口列表是第一个检查项，而不是最后一个。自称已经起来的状态，描述的是内核眼中一条虚拟链路的情况，而不是对端是否愿意应答。

不要改动提供的接口模式。把 TUN 配置改成 TAP 并不会让路由型服务器变成桥接型，而且通常会得到一个能建立连接却什么都不转发的配置。

路由由拥有隧道的那个服务安装

路由是第二个变化，而它归谁管比内容本身更重要。NetworkManager 配置、systemd 单元和手动运行的客户端都能安装路由，其中两个同时这么做，就会产生一张后来谁也解释不清的路由表。

ip -br addr show
ip route show
ip -6 route show

全隧道配置会替换默认路由；分离隧道配置会添加更具体的路由，并保持默认路由不变。两者都正常，后者正是为什么在一台远程管理的机器上删除默认路由是糟糕的第一项测试。删除它也是丢掉你正在用来修问题的那条会话的最快方式。

去读路由表，而不是想当然。一条更具体的路由或一条策略规则可以在默认路由仍指向物理接口时把流量送进隧道，这在读完整个表之前看起来很矛盾。这种组合对分离隧道是正常的，对期待一行就能描述设计的人来说却很费解。要找与实际目的地匹配的那条路由，而不是与示意图匹配的那条。

解析器换了主人

DNS 是第三个变化，也是最可能在你没看过的地方被管理的一项。在桌面上，NetworkManager 可能按连接下发解析器设置。在使用 systemd-resolved 的系统上，设置按链路生效，/etc/resolv.conf 可能是存根或符号链接，而不是你该去编辑的文件。

resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

如果对手工修改解析器文件的改动在重新连接后消失，这就是信号：去找到维护它的组件，改为修改配置。编辑生成的文件，是一次会被重新连接抹掉的改动。

私有名称通常需要内部解析器和运营方提供的搜索域。换成公共解析器可能恰好弄坏 VPN 存在的目的资源，症状看起来像路由故障而不是 DNS 故障。把名称和地址分开测试，因为一个成功另一个失败，会准确告诉你该往哪里看。仅这一项对比就能省下一小时的路由排查。

每个连接只用一个管理器

配置格式决定哪个程序能用它。OpenVPN 配置需要 OpenVPN 或兼容插件，WireGuard 配置有自己的一套格式，带对端密钥和允许的前缀。导入对话框不会把一种翻译成另一种，无论文件扩展名暗示什么。

选一个管理器，让它拥有这个连接。用两个工具把同一条隧道拉起来，会让路由表和重连行为变得含糊，而第二个启动的往往以难以复现的方式胜出。

安装你的发行版支持的软件包，并从运营方取得配置。把它当作凭据对待，因为它通常包含私钥或等价材料，要放在你其余机密所在的地方。留在下载文件夹里的配置，就是留在桌上的钥匙。

起来了却不工作时该查什么

在接口已经起来、客户端报告成功的情况下，向外逐层排查：路由表为目的地选中了隧道吗，解析器为私有名称给出应答了吗，远端有回程路径吗。每一项都有自己的命令和各自的负责人。

nmcli connection show --active
nmcli device status
wg show

nmcli 参考记录了状态和连接命令，如果你需要完整的一套。这里要紧的是区分配置处于激活状态和设备正在承载流量，因为两者可能不一致。

在宣布配置完成之前，用同一个管理器重连一次，并检查断开之后 DNS 仍然可用。只在第一次网络变化之前可用的配置不算完成，它只是此刻恰好能用。