DNS dividit i VPN: les regles de domini no són rutes IP
El DNS dividit tria un resolutor pel nom, i la resposta encara necessita una ruta. Provi la regla de domini i el camí per separat, a la plataforma que realment fa servir.
El seu portàtil resol intranet.corp a través del túnel mentre gitlab.com continua anant al resolutor del proveïdor, i aquesta és la disposició que funciona tal com es va dissenyar. Dues decisions separades la van produir: una regla de coincidència de noms va triar el resolutor i una ruta va tornar la resposta. Trenqui qualsevol de les dues i el navegador mostra una fallada que des de fora sembla la mateixa. La majoria d’informes de DNS dividit descriuen la segona fallada mentre citen proves sobre la primera.
Les dues meitats viuen en llocs diferents i normalment les editen persones diferents. Una és la política de DNS adjunta al perfil de VPN, l’altra és una ruta que el túnel instal·la o reté. La depuració s’atura quan ningú estableix quina meitat s’ha mogut realment.
Dues decisions amagades en una petició
La meitat del nom és un objecte de política, no una ruta. A Windows és una política de resolució de noms al perfil de VPN; a les plataformes Apple, un conjunt de dominis de coincidència en un objecte de configuració de DNS; a Linux, un domini d’encaminament, una línia de resolutor dividit o l’ordre del commutador de serveis de noms. La meitat del camí és encaminament ordinari, instal·lat pel túnel o a mà, i no té ni idea de què és un nom d’amfitrió. Un perfil que admet un sufix només decideix qui respon; mai no fa que la resposta sigui abastable.
Una prova ràpida de símptomes les separa: substituïu el nom per una adreça. Si l’adreça funciona, el camí està bé i la regla és incorrecta. Si l’adreça també falla, la regla pot ser correcta i el camí pot faltar.
Com expressa cada plataforma la mateixa regla de noms
La intenció és idèntica i els noms dels camps no ho són. Un exemple copiat d’un client a un altre s’analitza net i mai no coincideix. Les tres formes són així:
| 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 domini de coincidència o d’encaminament és una prova de sufix, així que intranet.corp cobreix git.intranet.corp i no cobreix corp.intranet, i invertir-ho és l’error més comú de tota la configuració. Windows porta el mapatge com una política de resolució de noms adjunta al perfil, amb el seu propi ordre de precedència enfront de qualsevol llista de sufixos que la interfície ja tingués. Les plataformes Apple adjunten els dominis de coincidència a l’objecte de configuració de DNS de l’extensió de xarxa, i el sistema els aplica per cada resolutor amb abast. Cap d’aquestes formes no és una ruta, i cap no pot fer abastable una adreça inabastable. La referència política de resolució de noms de Windows llista els noms dels camps i les regles de precedència per a aquesta plataforma, i no són les que fan servir els documents d’Apple o systemd.
Una resposta correcta encara necessita un camí
La resposta d’un resolutor només és una adreça, i l’aplicació encara hi ha d’arribar. Un disseny de túnel dividit sovint empeny 10.20.0.0/16 i reté la ruta per defecte, de manera que el nom intern es resol i la connexió s’encalla després. El cas oposat és igual de comú: la ruta existeix, un resolutor públic respon el nom privat amb NXDOMAIN i la fallada es registra com un problema d’encaminament. Provar el camí primer us deixa mirant rutes per a un nom que mai no s’havia de resoldre.
També hi ha una tercera porta que cap meitat no cobreix. Una ACL a la passarel·la, una regla de tallafoc o una política al costat del client poden deixar caure la connexió després que les dues decisions fossin correctes. Quan el nom es resol, la ruta existeix i la connexió encara expira, deixi de provar el DNS.
Provar noms i camins en un ordre fix
Triï un ordre i mantingui’l, o perseguirà el pas que va fallar més recentment. Resolgui el nom intern complet documentat, confirmi que la resposta és una adreça que la taula d’encaminament pot portar, i després repeteixi amb un nom públic per demostrar que el túnel no ho va capturar tot. En un amfitrió systemd la consulta i el domini d’encaminament del resolutor estan a una ordre de distància:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Un client de Windows fa les mateixes dues preguntes amb cmdlets diferents. El segon informa de la interfície que el sistema faria servir realment:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Si la consulta retorna una adreça i la comprovació del camí anomena la interfície física, la regla de noms va funcionar i la ruta no. Si el nom curt falla mentre el nom complet es resol, la llista de sufixos és incorrecta i no el resolutor.
On sol anar malament la comparació
El primer error és preguntar a un resolutor públic no relacionat sobre un nom privat i llegir el rebuig com a prova sobre la VPN. El segon és suposar que una consulta pública que funciona demostra el camí del resolutor del túnel. El tercer és tractar el túnel dividit i el DNS dividit com una sola decisió de disseny, quan un desplegament pot ser correcte en un i estar trencat en l’altre. Cada error produeix conclusions confiades a partir d’una prova que mai no va exercitar la part acusada.
Un navegador amb el seu propi DNS segur també pot saltar-se la regla del sistema, i per això que un navegador falli mentre un altre funciona no és cap contradicció. Comparï el resolutor que va respondre, no el navegador que es va queixar.
Un cop les dues meitats són visibles, la pregunta restant és una qüestió de política i no tècnica: quins espais de noms pertanyen a l’organització, qui posseeix cada resposta i quins d’ells haurien de sortir de la màquina. Escrigui-ho al costat del perfil, perquè la propera persona que toqui la regla ho necessitarà.