Fuga de DNS coa VPN en Windows: por que a métrica gaña á ruta
Windows escolle o resolutor pola métrica da interface, non só pola ruta. Un adaptador de túnel situado por baixo do Wi-Fi pode filtrar consultas mentres cada paquete segue pasando polo túnel.
Unha consulta sae do equipo e chega ao router da casa mentres cada paquete vai polo túnel. A conclusión natural é que falta unha ruta, e a ruta adoita estar ben. Windows pode escoller que resolutor de interface consultar segundo a métrica, e un adaptador de túnel a miúdo perde esa comparación co sen fíos.
Dúas explicacións para unha fuga
A explicación por rutas di que parte do tráfico se escapa do túnel, así que a ruta por defecto ou a lista do túnel dividido deben estar mal. Esa explicación pódese probar cun só comando, e cando a ruta por defecto apunta ao túnel xa está resolta. Compáraa primeiro porque é barata, e despois déixaa de lado cando volva limpa.
A explicación por clasificación di que o tráfico vai de todo polo túnel e que a consulta se segue enviando a outro resolutor. Windows trata a escolla de resolutor como unha propiedade por interface cunha orde, así que un adaptador físico con mellor métrica pode fornecer DNS para un nome aínda que os paquetes do enderezo resolto viaxen polo túnel. As dúas explicacións producen o mesmo síntoma nunha páxina de proba de fugas, por iso a proba non é o diagnóstico. Só unha delas se repara editando rutas.
Compare métricas e resolutores xuntos
Anote as interfaces, as súas métricas e os seus servidores configurados mentres o túnel está activo. Lea todo como unha táboa e non como dúas listas separadas, porque a pregunta é que resolutor vai primeiro, non que resolutores existen.
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceIndex, InterfaceAlias, InterfaceMetric
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, ServerAddresses
Se o adaptador de túnel leva un número maior ca o físico, o seu resolutor non é preferente, e un nome interno irá ao que ofreza o lado físico. Ese router pode responder desde a caché, reenviar a consulta ou rexeitala, e ningún deses resultados é o deseño que vostede pretendía. A clasificación é unha preferencia, así que perde en silencio en lugar de xerar un erro.
Un adaptador de túnel sen ningún resolutor configurado é unha variante igual de habitual. O cliente levanta a interface sen empurrar DNS, así que a pregunta da clasificación nin sequera se expón.
Suba o túnel na lista e volva comprobar
Dea á interface do túnel a métrica máis baixa, ou suba o valor do adaptador físico, nunha consola elevada. Ambas son axustes por interface e ambas son reversibles, o que importa cando cambia un equipo diante do cal quizais non estea.
Set-NetIPInterface -InterfaceIndex 27 -InterfaceMetric 1
Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric
O cambio vese de inmediato, e o cliente DNS e outros consumidores gardan na caché a escolla que xa fixeron. Reconecte o túnel, ou reinicie, antes de sacar conclusións dun resultado de consulta. Unha proba feita demasiado pronto reproducirá o comportamento antigo e parecerá unha reparación errada.
Despois consulte un nome interno e un público e comprobe que servidor respondeu. A referencia sobre as métricas automáticas de Microsoft explica por que se prefire o valor máis baixo e como se deriva a asignación automática.
Faga que sobreviva a unha reconexión
Unha métrica manual nun adaptador que se recrea en cada conexión é un axuste que desaparece. Se o cliente reconstrúe a interface, a substitución necesita un script posterior á conexión, unha política ou unha configuración de cliente que posúa o DNS mentres dura a conexión.
Os servidores configurados de forma estática no adaptador físico teñen o mesmo problema de durabilidade ao revés. Seguen respondendo por esa interface ata que se eliminan, e o DHCP volverá enchelos co seguinte arrendamento, así que eliminalos é unha medición e non un deseño. O deseño duradeiro é unha política de resolución de nomes para o espazo de nomes interno, ou un cliente que asuma o DNS durante a conexión. De calquera xeito, anote a lista de resolutores antes e despois dunha reconexión, restaure a métrica orixinal cando remate as probas e confirme que volveu o comportamento anterior.