O teu túnel dividido chega á aplicación pero non ao seu servidor DNS
Un túnel dividido pode encamiñar a subrede da aplicación e aínda así deixar caer o resolutor que está ao lado. Engade a ruta do host e despois comproba que servidor escolle realmente Windows.
Encamiñar a subrede da aplicación é a parte obvia dun túnel dividido, e non é todo o traballo. O resolutor adoita estar nun enderezo distinto da aplicación á que serve, así que un túnel que funciona pode deixar a consulta fóra del. Un perfil que leva 10.80.0.0/16 e nada máis envía a consulta de 10.90.0.53 pola interface local, onde non existe ningunha zona privada. Engade a ruta do resolutor e despois mira a outra metade do problema: que servidor escolle realmente o cliente.
O mito: unha ruta cobre todo o servizo
Un túnel dividido é unha lista de destinos que pasan pola conexión, non unha descrición dun servizo. A subrede da aplicación e o enderezo do resolutor son dous destinos, e un perfil pode levar un sen o outro. Cando iso ocorre, a aplicación é accesible por enderezo mentres o seu nome falla, o que parece un fallo de DNS máis ca un oco de encamiñamento.
A subrede que rodea o resolutor tampouco queda cuberta automaticamente. Unha ruta de host a un único enderezo abonda para ese resolutor e non abre os seus veciños. Ese é o sentido dunha ruta de host: estreita por deseño e fácil de esquecer cando o seguinte servizo aparece na mesma subrede.
Tres cousas deben cumprirse para que a consulta funcione: o cliente encamiña o enderezo do resolutor polo túnel, a pasarela admite e reenvía esa petición, e o resolutor acepta a fonte que recibe. A resposta tamén ten que volver polo camiño acordado. Se falta calquera delas, o síntoma é idéntico, por iso convén escribir a táboa de enderezos antes de tocar unha configuración.
Determina que enderezos debe levar o perfil
Enumera os destinos por orde: a rede da aplicación, o enderezo do resolutor e o punto final público que remata o propio túnel. O terceiro nunca debe encamiñarse dentro do túnel, porque a conexión exterior precisa un camiño que exista antes ca o túnel.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Inclúe tanto UDP como TCP para DNS, xa que se espera que as implementacións admitan TCP ademais de UDP, e un camiño TCP bloqueado produce fallos lentos e parciais en lugar de limpos. Se a zona privada tamén se serve por IPv6, a excepción de host equivalente usa un enderezo e un prefixo IPv6 e é unha entrada aparte.
Anota o que o perfil xa cobre antes de engadir nada. Unha ruta duplicada é inofensiva, pero unha ruta existente inesperada diche que o perfil deseñouse para un plan de enderezos distinto do que che deron.
Engade a ruta de host a través do propietario da conexión
Nun perfil nativo de Windows xestionado localmente, a ruta pertence á conexión e non á táboa de encamiñamento global da máquina. Previsualiza primeiro a adición e despois aplícaa co mesmo ámbito que usa o perfil.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
O primeiro comando previsualiza o cambio sen instalar nada, e o segundo enumera as rutas que o perfil leva agora. A referencia de Add-VpnConnectionRoute de Microsoft documenta os ámbitos por usuario e para todos os usuarios; un perfil para todos os usuarios necesita o seu propio parámetro de ámbito, e un comando por usuario contra un perfil para todos os usuarios falla ou acaba no lugar equivocado.
Cando o perfil se xestiona ou procede dun cliente de provedor, o cambio pertence a ese propietario. Apilar unha ruta de sistema permanente sobre unha política de conexión funciona ata que a política se volve aplicar e a ruta desaparece, o que adoita ocorrer nunha chamada de soporte e non durante as probas. Ese fallo é silencioso: a ruta desaparece, o nome deixa de resolverse e ninguén relaciona os dous feitos. Pon o cambio no rexistro propio do propietario para que a seguinte reaplicación o leve en lugar de borralo.
Despois de aplicalo, volve conectar o perfil en lugar de supoñer que a ruta xa fai efecto. Os cambios de ruta nunha conexión activa non sempre se recollen, e volver conectar tamén reproduce o estado que os teus usuarios terán realmente.
Comproba que resolutor usou realmente o cliente
Unha ruta controla os paquetes dirixidos ao resolutor. Non decide que nomes deben enviarse alí, e esa selección é un mecanismo aparte. En Windows, as regras efectivas de espazo de nomes poden escoller un resolutor por dominio, mentres que a configuración DNS do perfil fornece un valor predeterminado. Esas dúas capas poden discrepar sen producir ningún erro, por iso unha consulta directa só é a metade da proba.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
O primeiro comando imprime a política de espazo de nomes vixente, e o segundo pregunta directamente ao resolutor privado polo nome da aplicación. Unha resposta directa demostra que o camiño e o resolutor funcionan; non demostra que a consulta propia da aplicación escollese ese servidor. Compáraa cunha consulta normal do mesmo nome e coa resposta que recibe a aplicación.
Ten en conta as cachés e o DNS seguro do navegador, que pode saltar por completo o resolutor do sistema para os nomes que escribiu un usuario. Un sufixo de busca é outra pista falsa: amplía un nome curto a un totalmente cualificado e non ten nada que ver con que servidor responde.
Remata volvendo conectar e repetindo a consulta normal, e despois confirma que a navegación ordinaria segue a súa política aprobada. Substituír o resolutor privado por un público para que resolva un nome non relacionado non é unha solución, e move en silencio as consultas privadas alí onde nunca deberon ir.