2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
上个月，我为一位从事安全研究的客户配置了一个加固的开发环境。他们要求工作站的所有流量都必须通过虚拟专用网络隧道传输，没有任何例外。听起来很简单，对吧？安装 WireGuard，打开开关，搞定。
随后我运行了一次泄漏测试，结果发现报告中出现了互联网服务提供商分配的真实域名系统服务器。流量确实走了隧道，但域名系统查询却没有。我们在一种虚假的隐私安全感下工作了一周。
这类错误不会导致任何程序崩溃，也不会抛出错误，却在悄无声息中破坏了你最初配置虚拟专用网络的整个目的。让我们逐步了解实际发生的情况，以及如何彻底修复它。
令人沮丧的问题
你已经把所有步骤都做对了。你已连接到虚拟专用网络。curl ifconfig.me 返回的是虚拟专用网络的出口互联网协议地址。你的路由表看起来也很干净。然而，当你访问域名系统泄漏测试网站时，结果中却显示了你互联网服务提供商的解析器。
更糟糕的是：在某些情况下，你的虚拟专用网络隧道对超文本传输协议和超文本传输安全协议流量是正常的，但域名系统流量却在带外传输。你访问的每个域名仍然对你互联网服务提供商、咖啡馆的网络，或位于你与非预期解析器之间的任何其他方可见。
如果你在一组开发机器或与内部服务通信的持续集成运行器上运行此设置，后果会更加严重。内部主机名可能会泄漏给公共解析器。主机名通常与查询内容本身一样敏感。
根本原因：默认情况下，域名系统不属于你的虚拟专用网络隧道
大多数虚拟专用网络教程都略过了这一点。虚拟专用网络隧道负责路由互联网协议数据包。而域名系统解析发生在操作系统层面，通常在进行数据包路由决策之前，使用的是由动态主机配置协议租约、/etc/resolv.conf 文件或 systemd-resolved 存根配置的任意解析器。
通常有三个罪魁祸首：
- systemd-resolved 保留每个网络接口的域名系统配置，即使流量被路由到其他地方，它仍可能继续使用原始接口的域名系统服务器。
- 启用基于超文本传输协议的域名系统的浏览器（如 Firefox、Chrome）完全绕过操作系统解析器，直接通过超文本传输协议与硬编码的基于超文本传输协议的域名系统端点通信——这虽然确实通过虚拟专用网络隧道传输，但会流向你可能不信任的第三方。
-
使用自身解析器的应用程序——设置了
GODEBUG=netdns=go的 Go 语言二进制文件、某些容器运行时以及特定语言的解析器库可能会忽略系统设置。
虚拟专用网络看到加密的基于超文本传输协议的域名系统请求，并尽职地将其通过隧道传输。而操作系统解析器则通过错误的网络接口发送其明文用户数据报协议/53 查询。这两种路径可以在同一台机器上共存，这使得调试过程如此令人困惑。
第一步：确认泄漏
在修复任何问题之前，先证明确实存在泄漏。最廉价且可靠的测试方法是在触发查找时，在物理网络接口（而非虚拟专用网络接口）上使用 tcpdump。
# 在一个终端中，监控物理网卡上的域名系统流量
sudo tcpdump -i wlan0 -n 'udp port 53 or tcp port 53'
# 在另一个终端中，触发一次新的查找
# 使用一个独特的域名，以免缓存的答案掩盖问题
dig $(uuidgen | tr A-Z a-z).example.com
如果第一个终端中出现任何内容，说明存在泄漏。如果只有虚拟专用网络接口（wg0、tun0 等）上出现域名系统流量，则说明你是安全的。
你还可以检查什么
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
