VPN中的DNS与IP流量如何协同工作？

凌晨两点，林澈还在家里改一份跨境项目的方案。窗外安静得只剩空调的低鸣，他随手点开浏览器，准备访问公司内部的知识库。页面转了两圈，没打开。他皱了皱眉，又刷新一次，依旧失败。可微信还能发消息，视频会议也能连上，唯独那个域名像被谁从网络里抹掉了一样。

他打开终端，敲下 nslookup intranet.example.com，结果迟迟不返回。再试 ping 203.0.113.42，却立刻有了响应。林澈愣了一下：IP 能通，域名不通。问题不在“路”上，而在“问路”的方式上。更准确地说，问题出在 VPN 里 DNS 与 IP 流量那场看不见的协同。

很多人以为 VPN 只是把网络流量“加密一下”，然后从另一条隧道送出去。可真正使用过 VPN 的人都知道，事情远没有这么简单。尤其是当 DNS 查询、IP 路由、隧道接口、分流规则和远程内网同时出现时，VPN 就像一座繁忙的机场：DNS 是问询台，IP 是登机口，隧道是跑道，而策略路由是塔台。任何一环配合不好，用户就会看到“网页打不开”“内网访问不了”“时快时慢”“部分应用正常、部分应用异常”这些令人抓狂的现象。

一、从一次“打不开网页”说起：DNS 先走，IP 后到

林澈遇到的情况，其实是一个非常典型的 VPN 场景。

当他在浏览器里输入 intranet.example.com 时，电脑并不会立刻知道这个域名对应的服务器在哪里。它必须先做一件事：DNS 解析。也就是向某个 DNS 服务器提问：“intranet.example.com 的 IP 地址是多少？”

如果他没有连 VPN，这个 DNS 查询通常会发给本地网络分配的公网 DNS，比如运营商 DNS、路由器 DNS，或者手动配置的 8.8.8.8、1.1.1.1。这些服务器会返回公网可解析的结果，或者干脆告诉他“这个域名不存在”。

但公司内网域名 intranet.example.com 通常只在公司内部 DNS 里才有记录。于是，VPN 连接后，系统需要把这类域名的 DNS 查询也送进隧道，交给公司内网的 DNS 服务器解析。公司 DNS 返回一个内网 IP，比如 10.20.30.40。接着，浏览器才会向这个 IP 发起 HTTPS 请求。

注意这里的顺序：

1. 应用输入域名；
2. 系统发起 DNS 查询；
3. DNS 查询通过某种路径到达 DNS 服务器；
4. DNS 返回 IP；
5. 应用再向该 IP 发送真正的业务流量；
6. 业务流量再根据路由表决定是否进入 VPN 隧道。

也就是说，DNS 是“问路”，IP 流量是“走路”。如果问路问错了人，后面走得再对也没用。如果问路问对了，但走路时没进隧道，照样到不了目的地。

林澈的 nslookup 失败，说明 DNS 查询没有正确进入 VPN；而 ping 203.0.113.42 成功，说明至少有一部分 IP 路由已经通过 VPN 或本来就可达。这就是典型的“DNS 与 IP 流量协同断裂”。

二、VPN 建立后，系统里多了什么？

要理解 DNS 与 IP 流量如何协同，先得看 VPN 连接建立后，操作系统内部发生了什么变化。

以常见的远程访问 VPN 为例，客户端连接成功后，通常会做几件事：

1. 创建虚拟网卡

系统里会多出一个虚拟网络接口，比如 tun0、utun3、ppp0 或 Windows 上的“VPN 连接”。这个接口不对应真实网卡，而是 VPN 客户端与远端网关之间的逻辑通道。应用发出的数据包，如果被路由到这个接口，就会进入隧道。

2. 修改路由表

VPN 客户端会根据配置，向系统路由表里添加条目。例如：

• 10.0.0.0/8 走 VPN；
• 192.168.0.0/16 走 VPN；
• 0.0.0.0/0 走 VPN（全局模式）；
• 或者只让 10.20.30.0/24 走 VPN（拆分隧道）。

路由表决定了 IP 数据包的出口。没有匹配的路由，系统就不知道该把包发往哪里。

3. 修改 DNS 配置

VPN 还可能修改系统的 DNS 设置。比如把 DNS 服务器改成公司内网的 10.20.0.53，或者添加一个“按域名解析”的规则：只有 *.example.com 走 VPN DNS，其他域名仍走本地 DNS。

在 Windows、macOS、Linux、Android、iOS 上，DNS 配置方式各不相同。有的系统支持“分裂 DNS”，有的系统一旦 VPN 连接就全局改用 VPN DNS，有的系统则根据应用或网络接口选择 DNS。这也是为什么同一个 VPN，在不同设备上表现可能完全不同。

4. 设置分流规则

很多现代 VPN 客户端还支持“应用分流”或“域名分流”。比如：

• 访问 intranet.example.com 走 VPN；
• 访问 www.google.com 走本地；
• 访问 video.example.com 走本地；
• 访问 git.example.com 走 VPN。

这些规则本质上是在 DNS 解析和 IP 路由两个层面同时做文章。DNS 层决定返回哪个 IP，IP 层决定这个 IP 走哪条路。

三、DNS 查询在 VPN 里的三种命运

当林澈输入域名后，DNS 查询可能面临三种命运。

命运一：查询走本地，返回公网 IP，业务流量走 VPN

这是最常见也最容易出问题的情况。

比如系统把 DNS 查询发给了本地路由器，路由器又转发给运营商 DNS。运营商 DNS 返回了一个公网 IP，或者返回了 CDN 节点 IP。然后，系统根据路由表，把这个公网 IP 的流量送进 VPN。

结果可能有两种：

• 如果公司网关允许访问该公网 IP，业务可能成功，但绕了一圈；
• 如果公司内网域名本应解析到 10.x.x.x，却解析成了公网 IP，业务就会失败，或者访问到错误的服务。

这就是“DNS 泄漏”或“DNS 分流不一致”的典型后果。DNS 走了本地，IP 走了 VPN，两者看到的“世界”不一样。

命运二：查询走 VPN，返回内网 IP，业务流量也走 VPN

这是最理想的协同状态。

系统把 intranet.example.com 的 DNS 查询送进 VPN 隧道，公司内网 DNS 返回 10.20.30.40。系统路由表里又有 10.0.0.0/8 走 VPN 的条目。于是，浏览器向 10.20.30.40 发起的 HTTPS 请求也进入 VPN。DNS 和 IP 流量方向一致，业务顺利打开。

林澈的问题，就是没有达到这个状态。

命运三：查询走 VPN，返回内网 IP，但业务流量走本地

这种情况也很常见，尤其在拆分隧道配置不完整时。

DNS 查询确实通过 VPN 拿到了 10.20.30.40，但系统路由表里没有 10.20.30.0/24 走 VPN 的条目。于是，浏览器试图直接访问 10.20.30.40，数据包却被发到了本地默认网关。本地网关当然不认识这个内网地址，于是丢包、超时，页面打不开。

用户看到的现象是：“域名能解析，但访问不了。”这比 DNS 完全失败更隐蔽，因为 nslookup 可能成功，ping 却失败。

四、IP 流量进入 VPN 后，又发生了什么？

假设 DNS 已经正确返回了内网 IP，接下来就是 IP 流量的旅程。

1. 路由决策

操作系统查看目标 IP，比如 10.20.30.40，然后匹配路由表。如果最具体的路由是 10.20.30.0/24 dev tun0，数据包就会被送到 VPN 虚拟网卡。

2. 封装与加密

VPN 客户端拿到原始 IP 数据包后，会按照协议进行封装。比如：

• OpenVPN 可能把原始包放进 TLS 隧道；
• WireGuard 把包加密后封装进 UDP；
• IPsec 把包封装进 ESP；
• 某些 SSL VPN 则把流量封装进 HTTPS。

封装后的外层数据包，源地址是用户当前公网 IP，目标地址是 VPN 服务器公网 IP。然后，它再经过物理网卡发出去。

3. 穿越公网

外层数据包在公网上传输。中间的路由器只看到 VPN 服务器地址和加密载荷，看不到里面的内网 IP 10.20.30.40。这就是 VPN 的“隧道”效果。

4. 服务端解封装与转发

VPN 服务器收到包后，解封装、解密，得到原始内网请求。然后，它根据公司内网路由，把请求转发给 10.20.30.40。目标服务器响应后，响应包再沿原路返回：公司内网 -> VPN 服务器 -> 加密隧道 -> 用户设备。

5. 返回流量与 DNS 的再次协同

返回流量同样需要正确路由。如果 VPN 服务器配置了 NAT 或路由，响应会回到隧道。如果服务端路由缺失，用户就会看到“请求发出去了，但响应回不来”。

在这个过程中，DNS 的作用已经结束了吗？并没有。因为很多现代应用会做 DNS 重解析、CDN 调度、负载均衡、服务发现。一个页面可能涉及几十个域名，每个域名都要经历“DNS 解析 -> IP 路由 -> 隧道传输”的循环。只要其中一个域名的 DNS 或 IP 路由配置不一致，页面就可能卡住、白屏或部分加载。

五、为什么“全局模式”和“拆分隧道”表现不同？

林澈后来把 VPN 客户端从“拆分隧道”切到“全局模式”，内网知识库立刻能打开了。但他发现，访问本地视频网站变慢了，因为所有流量都绕到了公司出口。

这就是全局模式与拆分隧道的差异。

全局模式

• 路由表：0.0.0.0/0 走 VPN；
• DNS：通常全部走 VPN DNS；
• 优点：配置简单，DNS 与 IP 流量方向一致，内网访问成功率高；
• 缺点：所有公网流量也走 VPN，速度受公司出口影响，可能触发合规审计。

拆分隧道

• 路由表：只有特定网段走 VPN；
• DNS：可能按域名分流，也可能全局走 VPN DNS；
• 优点：公网访问走本地，速度快，减轻 VPN 网关压力；
• 缺点：DNS 与 IP 路由容易不一致，配置复杂，排错困难。

拆分隧道最怕的场景是：

• 域名 a.example.com 解析到内网 IP，但路由没覆盖；
• 域名 b.example.com 解析到公网 IP，但路由却把它送进 VPN；
• DNS 查询走本地，返回了 CDN 公网 IP，但公司网关不允许访问；
• DNS 查询走 VPN，返回内网 IP，但应用使用了本地 DNS 缓存，仍然拿旧 IP。

所以，一个成熟的 VPN 方案，必须同时管理 DNS 解析路径和 IP 路由路径，让它们像一对默契的舞伴，而不是各跳各的。

六、从林澈的排错过程，看协同工作的关键点

林澈最后是怎么解决的？他做了几件事。

第一，确认 DNS 查询走了哪条路

他在终端里执行：

bash scutil --dns

在 macOS 上查看 DNS 解析顺序。结果发现，example.com 的查询仍然走本地路由器，而不是 VPN 提供的 DNS。原因是 VPN 客户端没有正确设置分裂 DNS。

第二，确认 IP 路由是否覆盖内网网段

他执行：

bash netstat -rn

发现 10.20.30.0/24 确实有路由，但 10.20.0.0/16 没有。公司 DNS 返回的地址是 10.20.30.40，这个能走 VPN；但另一个服务返回 10.21.5.8，就走不了 VPN。于是出现“部分内网服务可用，部分不可用”。

第三，检查 DNS 缓存

他清除了系统 DNS 缓存和浏览器缓存。因为之前错误的解析结果可能还被缓存着，即使 VPN 配置修好了，旧 IP 仍然会被使用。

第四，调整 VPN 客户端的 DNS 与路由策略

他把公司内网域名后缀加入 VPN DNS 搜索域，并确保对应内网网段全部走 VPN。然后重新连接，问题消失。

这个过程说明：DNS 与 IP 流量不是两个独立模块，而是一条链上的两个环节。DNS 决定“目标是谁”，IP 路由决定“怎么到达”。VPN 则决定“哪些查询和哪些数据包进入隧道”。

七、企业 VPN 设计中，如何让 DNS 与 IP 流量更好协同？

从企业角度看，要让 VPN 里的 DNS 与 IP 流量协同工作，需要考虑几个层面。

1. DNS 服务器可达性

VPN 客户端必须能访问内网 DNS。如果 DNS 服务器本身在 10.20.0.53，那么 10.20.0.53 的路由必须走 VPN。否则，DNS 查询根本发不出去。

2. DNS 搜索域与分裂解析

企业应明确哪些域名走内网 DNS，哪些走公网 DNS。比如：

• *.corp.example.com 走内网 DNS；
• *.example.com 走内网 DNS；
• 其他走本地 DNS。

这需要 VPN 客户端和操作系统支持分裂 DNS。否则，一旦 VPN 连接，所有 DNS 都走内网，可能导致公网域名解析失败或变慢。

3. 路由精确性

内网 DNS 返回的 IP 段，必须在 VPN 路由表里有对应条目。否则就会出现“解析成功但访问失败”。

4. MTU 与分片

DNS 查询通常很小，但 IP 流量可能很大。VPN 封装会增加开销，导致 MTU 变小。如果 MTU 配置不当，大包可能被分片或丢弃，表现为“网页能打开但下载失败”“小文件能传大文件不行”。这虽然不直接是 DNS 问题，但会影响整体协同体验。

5. 双栈与 IPv6

如果内网 DNS 返回 IPv6 地址，但 VPN 只支持 IPv4，或者路由表没有 IPv6 条目，也会出现解析成功但访问失败。现代 VPN 必须考虑 IPv4/IPv6 双栈协同。

6. 监控与日志

企业应监控 DNS 查询成功率、VPN 路由命中率、隧道吞吐量、DNS 泄漏情况。否则，用户报障时只能靠猜。

八、普通用户能做什么？

如果你不是网络工程师，只是像林澈一样使用 VPN，也可以记住几个实用原则。

• 如果内网域名打不开，先试 IP。IP 能通、域名不通，多半是 DNS 问题。
• 如果域名能解析、IP 访问不了，多半是路由或防火墙问题。
• 切换全局模式和拆分隧道，观察现象是否变化。
• 清除 DNS 缓存，重启 VPN 客户端。
• 不要同时开多个 VPN 或代理，它们可能互相抢 DNS 和路由。
• 如果公司提供“内网 DNS”和“公网 DNS”两套配置，确认自己是否选对。
• 在公共 Wi-Fi 下，优先使用全局模式或可信 VPN，避免 DNS 泄漏。

九、回到那个凌晨两点

林澈最终打开了知识库。页面加载出来的一瞬间，他忽然觉得，VPN 并不只是“加密通道”这么简单。它更像一套精密的交通系统：DNS 是路牌，IP 是车辆，路由表是道路，隧道是高速，策略是交警。任何一个环节不协调，用户就会堵在路上。

而 DNS 与 IP 流量的协同，正是这套系统里最容易被忽视、也最值得理解的部分。DNS 负责把名字翻译成地址，IP 流量负责把数据送到地址。VPN 则负责决定，哪些翻译请求和哪些数据包应该进入隧道。三者配合得好，用户感觉不到它们的存在；配合得不好，就会像林澈那样，在凌晨两点对着一个打不开的页面发呆。

下一次，当你连上 VPN，顺利打开公司内网、又流畅访问公网时，不妨想一想：在你看不见的地方，有一群 DNS 查询和 IP 数据包，正排着队，穿过隧道，完成一场精确到毫秒的接力。