DNS dividido e VPN: as regras de dominio non son rutas IP
O DNS dividido elixe un resolutor por nome, e a resposta segue necesitando unha ruta. Probe a regra de dominio e o camiño por separado, na plataforma que realmente executa.
O seu portátil resolve intranet.corp a través do túnel mentres gitlab.com segue indo ao resolutor do provedor, e esa é a disposición que funciona tal como se deseñou. Dúas decisións separadas producírona: unha regra de coincidencia de nomes escolleu o resolutor e unha ruta trouxo a resposta de volta. Rompa calquera das dúas e o navegador amosa un fallo que desde fóra parece o mesmo. A maioría dos informes de DNS dividido describen o segundo fallo mentres citan probas sobre o primeiro.
As dúas metades viven en sitios distintos e normalmente edítaas xente distinta. Unha é a política de DNS ligada ao perfil de VPN, a outra é unha ruta que o túnel instala ou retén. A depuración detense cando ninguén establece que metade se moveu realmente.
Dúas decisións agachadas nunha petición
A metade do nome é un obxecto de política, non unha ruta. En Windows é unha política de resolución de nomes no perfil de VPN; nas plataformas Apple, un conxunto de dominios de coincidencia nun obxecto de axustes de DNS; en Linux, un dominio de encamiñamento, unha liña de resolutor dividido ou a orde do conmutador de servizos de nomes. A metade do camiño é encamiñamento corrente, instalado polo túnel ou a man, e non ten idea do que é un nome de host. Un perfil que admite un sufixo só decide quen responde; nunca fai que a resposta sexa alcanzable.
Unha proba rápida de síntomas sepáraas: substitúa o nome por un enderezo. Se o enderezo funciona, o camiño está ben e a regra é incorrecta. Se o enderezo tamén falla, a regra pode ser correcta e faltar o camiño.
Como expresa cada plataforma a mesma regra de nomes
A intención é idéntica e os nomes dos campos non. Un exemplo copiado dun cliente a outro analízase limpiamente e nunca coincide. As tres formas son así:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Un dominio de coincidencia ou de encamiñamento é unha proba de sufixo, así que intranet.corp cobre git.intranet.corp e non cobre corp.intranet, e invertelo é o erro máis común de toda a configuración. Windows leva a asignación como unha política de resolución de nomes ligada ao perfil, coa súa propia orde de precedencia fronte a calquera lista de sufixos que a interface xa tivese. As plataformas Apple ligam os dominios de coincidencia ao obxecto de axustes de DNS da extensión de rede, e o sistema aplícaos por cada resolutor con ámbito. Ningunha destas formas é unha ruta, e ningunha pode facer alcanzable un enderezo inalcanzable. A referencia política de resolución de nomes de Windows enumera os nomes de campo e as regras de precedencia para esa plataforma, e non son as que usan os documentos de Apple ou systemd.
Unha resposta correcta aínda necesita un camiño
A resposta dun resolutor só é un enderezo, e a aplicación aínda ten que chegar a ela. Un deseño de túnel dividido adoita empurrar 10.20.0.0/16 e retén a ruta por defecto, así que o nome interno resólvese e a conexión colga despois. O caso contrario é igual de común: a ruta existe, un resolutor público responde ao nome privado con NXDOMAIN e o fallo arquívase como problema de encamiñamento. Probar o camiño primeiro déixalle mirando rutas para un nome que nunca se ía resolver.
Tamén hai unha terceira porta que ningunha metade cobre. Unha ACL na pasarela, unha regra de cortafuegos ou unha política do lado do cliente poden deixar caer a conexión despois de que ambas decisións fosen correctas. Cando o nome se resolve, a ruta existe e a conexión segue esgotando o tempo, deixe de probar DNS.
Probar nomes e camiños nunha orde fixa
Escolla unha orde e mantéñaa, ou perseguirá o paso que fallou máis recentemente. Resolva o nome interno completo documentado, confirme que a resposta é un enderezo que a táboa de rutas pode levar, e logo repita cun nome público para demostrar que o túnel non o capturou todo. Nun host systemd a consulta e o dominio de encamiñamento do resolutor están a un comando de distancia:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Un cliente de Windows fai as mesmas dúas preguntas con outros cmdlets. O segundo informa da interface que o sistema usaría realmente:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Se a busca devolve un enderezo e a comprobación do camiño nomea a interface física, a regra de nomes funcionou e a ruta non. Se o nome curto falla mentres o nome completo se resolve, a lista de sufixos é incorrecta e non o resolutor.
Onde adoita ir mal a comparación
O primeiro erro é preguntar a un resolutor público non relacionado por un nome privado e ler o rexeitamento como proba sobre a VPN. O segundo é supoñer que unha busca pública que funciona demostra o camiño do resolutor do túnel. O terceiro é tratar o túnel dividido e o DNS dividido como unha soa decisión de deseño, cando un despregamento pode ser correcto nun e estar roto no outro. Cada erro produce conclusións seguras a partir dunha proba que nunca exercitou a parte acusada.
Un navegador co seu propio DNS seguro tamén pode saltar a regra do sistema, por iso que un navegador falle mentres outro funciona non é unha contradición. Compare o resolutor que respondeu, non o navegador que se queixou.
Unha vez que ambas metades son visibles, a pregunta restante é de política e non técnica: que espazos de nomes pertencen á organización, quen posúe cada resposta e cales deles deberían saír da máquina. Escríbao xunto ao perfil, porque a seguinte persoa que toque a regra necesitarao.