不少中小工作室、小型企业为了保障网络冗余，clash会同时接入两条不同运营商的宽带搭建双WAN网络环境，但这类场景下接入VPN时，DNS解析异常的故障占比远高于单宽带环境，很多运维人员排查时只参照单线路的配置逻辑，忽略了双线路策略路由分流带来的DNS请求泄露、路由冲突问题。本文围绕双宽带环境VPN的DNS配置检查核心需求，梳理可落地的检查步骤、验证方法和常见故障的排查思路。
双宽带环境VPN DNS配置的前置前提
多数双宽带部署方案都会使用多WAN口路由器承载两条物理线路，两条线路分属不同运营商，默认配置下路由器会把两条WAN口获取的运营商DNS都加入全局DNS池，随机分配给内网设备使用，而VPN隧道建立后，DNS请求很容易被内置的负载均衡策略分流到非VPN绑定的物理线路上，这是绝大多数DNS异常故障的根源。
运维人员正在双宽带网络环境下排查VPN相关的DNS配置异常问题
正式开始配置检查前，首先要明确当前使用的VPN类型，无论是站点到站点的IPsec VPN，还是员工远程接入的OpenVPN，都需要先在多WAN路由器中给VPN对应的内网虚拟网段，绑定固定的VPN流量出口，禁止VPN相关的流量被随机分流到任意一条物理宽带线路，从规则层面避免DNS请求的路由冲突。
双宽带环境VPN的DNS配置分步检查流程
第一步先核查VPN服务端的DNS推送规则，比如OpenVPN服务端配置文件里的DNS推送命令，要确认填写的地址是VPN对端内网的合法DNS服务器，不能图省事填入本地双宽带任意一条线路的公网运营商DNS，这类本地公网地址在VPN隧道的路由路径里没有可达性，自然无法完成解析。
第二步核查多WAN路由器的DNS策略路由规则，要给所有从VPN虚拟网卡发出来的、目的端口为53的DNS请求，指定下一跳为VPN隧道对应的虚拟接口，不能把这类请求的出口设置为WAN1或者WAN2任意一条物理宽带，避免DNS请求绕过VPN隧道直接从本地公网发出。
第三步核查VPN客户端侧的DNS优先级设置，以Windows系统为例，可以在网络适配器属性里找到VPN对应的虚拟网卡，调整DNS服务器的跃点数，clash verge把数值改到远低于本地双宽带物理网卡的跃点数，确保VPN连接成功后，系统会优先调用VPN推送的DNS服务器发起请求，不会随机选用本地物理网卡自带的运营商DNS。
配置有效性的实操验证方法
完成所有配置调整后，先正常连接VPN，打开系统自带的命令提示符工具，Windows系统执行ipconfig /all命令，macOS或Linux系统执行对应的网络信息查询命令，查看当前活跃的DNS服务器列表，排在第一位的必须是VPN服务端推送的对端内网DNS，不能出现本地两条宽带的运营商DNS排在优先级首位的情况。
接下来执行域名解析测试，先断开VPN的状态下，用nslookup工具查询VPN对端的专属内网域名，记录返回的解析结果，再重新连接VPN发起同样的查询，如果两次返回的IP地址完全不同，说明DNS请求确实走了VPN隧道传输，没有泄露到本地双宽带的公网线路上。
常见故障场景的排查思路
如果遇到VPN连接之后只能用IP访问对端内网资源、所有域名都无法解析的问题，首先排查双宽带的其中一条线路是否出现临时断网，clash verge路由器自动切换默认路由后，把VPN相关的DNS请求导到了离线的WAN口上，这类场景下需要把VPN相关的路由规则设置为不受全局默认路由切换影响，绑定独立的专用路由表。
如果出现部分对端内网域名可以正常解析、部分域名解析失败的情况，大概率是双宽带路由器的DNS转发规则里，开启了运营商域名智能分流功能，把部分域名的请求直接转发到了本地公网DNS服务器，没有走VPN隧道，只需要把所有VPN对端的专属内网域名，添加到强制走VPN隧道的DNS代理白名单里即可解决。
排查时还要注意不要在双宽带环境下随意开启浏览器全局DNS over HTTPS功能，这类加密DNS请求会直接绕过系统层面的DNS优先级设置，直接从本地物理宽带线路发起请求，导致之前配置的所有VPN DNS规则完全失效，出现看似配置正确但解析结果完全不符合预期的问题。
