深信服 VPN 异常退出导致 Ubuntu 系统 DNS 解析瘫痪
适用系统： Ubuntu 20.04 LTS 及其他使用 systemd-resolved 的 Linux 发行版
触发条件： 未在客户端断开深信服 (Sangfor) VPN 直接重启/关闭系统
影响范围： 网页无法打开、常规域名解析失败；长连接应用（飞书/微信等）可能部分正常
一、 故障现象描述
1. 用户侧表现
浏览器行为： 无法访问任何网页，报错提示类似 ERR_NAME_NOT_RESOLVED（域名无法解析）。
客户端行为： 飞书、微信等办公软件仍能正常收发消息、在线通信，形成“网络半瘫痪”的假象。
2. 终端侧表现
在终端中执行 DNS 状态管理命令 resolvectl 或 resolvectl status 时，系统抛出 D-Bus 错误：
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
二、 根本原因分析 (Root Cause)
该故障的核心本质是：VPN 客户端生命周期异常中止，导致其对底层网络的修改未能触发“逆向清理脚本”，致使系统默认 DNS 服务保持挂起状态。
1. 为什么飞书等应用依然可用？
标准域名解析依赖： 浏览器严格依赖系统的标准 DNS 流程。当本地 DNS 解析服务崩溃时，域名转换为 IP 的通道关闭，网页无法加载。
应用内缓存与直连： 飞书、微信等现代客户端在运行期间会将常用服务器 IP 缓存在内存中，或在底层采用固定的 IP 列表进行长连接直连。部分应用甚至支持自身的 DNS-over-HTTPS (DoH) 技术。因此能绕过系统的 systemd-resolved 服务，继续维持通信。
2. VPN 劫持 DNS 的底层逻辑
正常连接时（劫持）： 启动深信服 VPN 后，客户端为了解析内网域名，会自动执行脚本将系统自带的 systemd-resolved 服务禁用（Disable）并停止（Stop），随后将系统的 DNS 请求强行重定向到 VPN 虚拟网卡（如 tun0）及内网 DNS。
正常退出时（还原）： 正常点击“断开/退出”时，客户端触发钩子脚本，撤销网络重定向，并重新拉起（Enable & Start）系统的 systemd-resolved。
异常重启时（残留 Bug）： 若未在客户端断开 VPN 直接重启，Ubuntu 关机信号会强制杀掉（Kill）VPN 进程。由于清理脚本未来得及执行，系统重启后直接继承了关机前的状态——即 systemd-resolved 依然处于 disabled（禁用）和 inactive（死锁）状态。此时 VPN 虚拟网卡已消失，导致系统彻底失去标准 DNS 解析能力。
三、 标准解决方案 (Standard Operating Procedure)
通过以下三步排查并强制恢复系统自带的 DNS 解析服务：
步骤一：状态确认
在终端中执行以下命令检查服务状态：
sudo systemctl status systemd-resolved
关键异常指标：
Loaded: loaded (...; disabled; ...) -> 证明服务被永久禁用（这是导致 resolvectl 找不到服务的根本原因）。
Active: inactive (dead) -> 证明服务当前未运行。
步骤二：强制恢复并激活服务
使用 --now 参数，一步到位完成服务的恢复与即时拉起：
sudo systemctl enable --now systemd-resolved
(注：该命令在底层等同于串行执行 systemctl enable 与 systemctl start)
步骤三：有效性验证
服务检查： 再次执行状态检查命令，确认输出中包含绿色的 active (running) 字样。
命令验证： 执行 resolvectl，确认能够正常输出本地物理网卡的 DNS 配置，不再提示 D-Bus 报错。
业务验证： 刷新浏览器，确认任意公网域名均能正常解析和访问。
四、 防范建议与最佳实践
- 规范操作规程： 运维及开发人员在日常闭班关机或重启系统前，务必养成先在 VPN 客户端手动点击“断开连接”或“退出”的习惯。