实验
关于在 Windows 客户端上使用split-dns. 太多了，我决定收集一些证据，看看它指向哪里。我在连接 VPN 的 Windows 客户端和该客户端连接的 ASA 上设置了同步数据包捕获。这是测试设置的图表：
随着数据包捕获的运行，我在客户端上启动了 DNS 解析。为此，我srv1.internal.example.com在 Google Chrome 中按下了 Enter 。以下是调整后的数据包捕获以同步它们的时钟并合并在一起。
ID 以“C”开头的数据包来自 Windows [C]lient。
以“A”开头的数据包来自 [A]SA。
分析
在橙色中，我们可以看到 Windows/Chrome 尝试进行的四个单独的 DNS 查询：四个 DNS 查询的目的地如下：
- 8.8.8.8 - 与 Wifi 适配器关联的 DNS 服务器（数据包
C69）
- 10.10.10.3 - 第一个与 VPN 适配器关联的 DNS 服务器（数据包
C70）
- 8.8.8.8 - 与 Wifi 适配器关联的 DNS 服务器（数据包
C78）
- 10.10.10.4 - 与 VPN 适配器关联的第二个 DNS 服务器（数据包
C81）
最能说明问题的是，显然发送到 8.8.8.8 的两个 DNS 查询以数据包的形式出现在 ASA，A95并且A105源和目标 IP 已从外部地址转换为内部地址。来自 DNS 服务器的对这些已转换查询的响应位于A97和A106，然后它们本身又分别以数据包C74和转换为外部地址C84。这些 DNS 查询最终会成功。
对原始问题的回答
如果 Windows 选择将内部域的 DNS 查询发送到 VPN 适配器以外的适配器，VPN 客户端如何确保所有内部域的 DNS 查询都通过隧道传输到内部 DNS 服务器？
根据上述证据，VPN 客户端似乎拦截了与使用非 VPN适配器split-dns value上的命令配置的域匹配的 DNS 查询。
我在这里错过了什么吗？是否有什么奇特的事情以某种方式允许 VPN 客户端拦截 Windows 发送到错误适配器的 DNS 查询？
缺少的花哨部分是 VPN 客户端执行某种网络地址转换，以使 Windows 看起来内部域的 DNS 查询正在由Windows 向其发送请求的公共DNS 服务器提供服务。事实上，这些请求由内部 DNS 服务器提供服务。
我不确定这是如何完成的，而且思科似乎没有任何文件说明这一点。我承认 VPN 客户端在 Windows 端执行了一些魔法来实现功能分离的 DNS。
适配器绑定顺序注意事项
我修改了经常引用的适配器绑定顺序。这是我发现的。适配器顺序似乎对 VPN 客户端拦截和转换内部域的 DNS 查询能力的功效没有影响。
将 VPN 适配器置于绑定顺序的最高位置似乎会导致 Windows最初仅向 VPN 适配器上的 DNS 服务器发送 DNS 请求。这些请求似乎完全被 VPN 客户端丢弃（大概是因为它们与内部域不匹配）。这会导致 Windows 超时（或一系列超时），直到最终 Windows 尝试使用非 VPN 适配器进行 DNS 解析。这会在浏览时产生明显且令人恼火的延迟。
基于此，似乎在拆分 DNS 配置中，VPN 适配器不应该是最高优先级。
