VPN 客户端已卸载，隧道却仍在开机时启动

你的发行版删掉了软件包，菜单里也没有了条目，可下次重启后隧道仍然会起来。商业 VPN 客户端会留下包管理器从未追踪过的部件，所以卸得干净并不等于机器干净。其中四类部件几乎解释了所有幽灵连接：一个单元、一个连接配置文件、一个特权辅助程序和一个厂商软件源。在删除任何东西之前，先把这四类都读一遍，然后顺着各自所属的组件逐一移除。

卸载程序从未记录的东西

包管理器只会删除它自己登记过的文件，别的什么都不动。它没有记录客户端在运行时创建的连接配置文件，没有记录安装后才启用的单元，也没有记录一个以提权方式运行时自我注册的辅助程序。这些各自属于不同的子系统，而且都能比软件包多活一次或几次重启。正是这个缺口，解释了为什么软件已经不存在，隧道却还健康。

残留物总有归属，可能是 systemd、NetworkManager、软件源配置，也可能是某个用户级自启动项。先定位归属，才能避免一次清理把机器变成半配置状态。直接删文件通常只撑到归属方把它重新生成，所以下面的命令都从查询开始。

四个归属方，先只读

从查询而不是删除入手，并记下返回的确切名称。厂商常在元包旁边再发一个带版本号的包，因此同一个产品可能以两个名字出现。同时出现在两张清单里的名字，是一个产品有两个归属方，两边都得移除。第一批覆盖软件包和单元，多数残留就是在这里现形的。

dpkg -l | grep -i acmevpn
systemctl list-unit-files | grep -i acmevpn
systemctl list-units --type=service --state=running | grep -i acmevpn

第二批覆盖最常幸存下来的两个部件，也就是连接配置文件和厂商软件源。要看 UUID 那一列而不是名字，因为重名很常见，而删除命令要的是标识符。即使今天不删，软件源那一行也值得读：一个已经死掉的厂商主机，几个月后可能拖垮一处毫不相关的安装。两份清单都不改动任何东西，这正是先跑它们的原因。

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show --active
grep -ril acmevpn /etc/apt/sources.list.d/ /etc/apt/sources.list

清理后仍然活着的进程，要么是活动单元，要么是别的程序的子进程。在指责一个已经不存在的服务之前，先读进程表和它的父进程链。用户级自启动项也要同样过一遍，而且它们只会在新的登录 shell 里出现，不会在 root 会话里出现。

三个不能互换的动词

停止结束当前运行，禁用移除开机链接，而屏蔽把单元指向 /dev/null。只有第三个还会挡住经由套接字、定时器或依赖关系的激活，因此它是三者中最强的。你还在决定怎么处置这台机器时，顺序很重要。在这个决定期间，屏蔽才是正确状态，因为它在下次开机时会大声失败，而不是悄悄起来。

重新安装之前要先解除屏蔽，否则新包会因为一个没人记录过的原因显得是坏的。同样的谨慎适用于打包差异：有的版本提供的单元可以停止，有的则根本不留服务。选动词之前先确认自己是哪种打包，因为清理路径并不一样。

通配符就是这样删错配置文件的

用你记下的 UUID 删除配置文件，绝不要用通配符。keyfile 目录里还存着机器上每一个 Wi-Fi 和以太网配置，宽泛匹配会连你还需要的东西一起删掉。手工删除的 keyfile 可能被拥有它的策略重新生成，于是删除看起来毫无效果。

nmcli connection delete uuid <uuid>

如果那份配置是你手里唯一的副本，先导出网关和身份，因为本地删除不会吊销服务器上的任何东西。软件源也遵循同一条规则：移除那一个厂商文件和它的密钥环，然后刷新软件包列表，重试你真正想要的那次安装。留下过期的第三方条目，可能把旧依赖钉死，也可能完全不应答。两处移除都很小，而且都能从你保留的副本里撤回。

重启之后还在跑的东西

宣布胜利之前先重启，然后找的是残留物而不是应用。旧客户端留下的隧道接口、过期分离路由和逐链路 DNS，各自都需要自己的命令。这三样都能在一次成功删掉所有包的清理之后继续存在。

ip link
ip route
resolvectl status

也开一个新的登录 shell，因为自启动项只在那里触发。然后读 /etc/NetworkManager/dispatcher.d/，找一个在接口状态变化时把连接拉起来的脚本——这正好解释了背后没有服务、隧道却会回来的现象。如果还有东西在往外拨，就顺着进程追到它的父进程，而不是一直删文件直到症状消失。清理机器和吊销账号仍是两件独立的事，重启看起来平静时，只完成了其中一件。