Per què fallen els noms DNS privats als clients VPN i on cal mirar

Obres un portàtil en una habitació d’hotel, engegues el client, escrius el nom del servidor de fitxers intern i no reps res. El túnel diu connectat, i un ping a una adreça dins de la mateixa subxarxa encara respon, així que el transport està bé. Només falla el nom, i aquest buit redueix el problema a dos llocs: a quin resolutor va preguntar el client i si la resposta que va obtenir pot tornar pel túnel. Encerta’n un i omet l’altre, i la fallada simplement es desplaça.

Abans d’editar qualsevol perfil, confirma què fa el client amb el nom. A Linux, resolvectl query files.corp.example mostra quin enllaç i quin resolutor van produir la resposta. A Windows, Resolve-DnsName files.corp.example mostra el servidor que va respondre i l’adreça que va retornar.

Llegeix la resposta abans de canviar res

Si el nom torna com a NXDOMAIN en uns mil·lisegons, la consulta no va arribar mai a la teva zona i va respondre algun resolutor públic o de l’hotel. Si torna després d’una pausa llarga, alguna cosa està descartant el port UDP 53 pel camí i el client va acabar recorrent a un altre. Si respon amb l’adreça correcta però la connexió continua encallada, la consulta està bé i el teu problema és l’encaminament o el servei mateix.

Aquesta divisió en tres estalvia una hora de conjectures. També et diu si has de tocar la VPN: un nom que es resol a l’adreça privada correcta ja ha demostrat el camí del resolutor, així que la feina que queda és al camí de les dades.

Reparteix el resolutor des de dins del túnel

Els clients es divideixen en dos grups. A un se li pot indicar un resolutor des del servidor durant l’establiment de la connexió; l’altre guarda l’ajust en un fitxer local que cap passarel·la pot canviar en remot.

OpenVPN és al primer grup. Al servidor, push "dhcp-option DNS 10.8.0.53" i push "dhcp-option DOMAIN corp.example" baixen pel canal de control, però només si la configuració del client encara té pull activat. Un client editat a mà que porti pull-filter ignore "dhcp-option" no els veurà mai, i aquesta sola línia explica un nombre sorprenent de casos de «el servidor ho empeny però el meu portàtil no hi està d’acord».

WireGuard és al segon grup, perquè el protocol no té cap negociació d’opcions. El resolutor i el domini de cerca van al bloc [Interface] del mateix client com a DNS = 10.8.0.53, corp.example. wg-quick ho aplica mitjançant resolvconf o systemd-resolved, i a Windows el client oficial instal·la regles NRPT que només existeixen mentre el túnel és obert: Get-DnsClientNrptPolicy les llista, cosa que el converteix en una manera ràpida de veure si el client va arribar a aplicar el teu fitxer.

IPsec/IKEv2 queda al mig. El connector attr de strongSwan pot retornar un servidor DNS tret d’un pool, i un client Windows normalment l’accepta, però un perfil que fixa el seu propi servidor de noms guanya el que ofereixi la passarel·la. En un client Linux el pas manual equivalent és resolvectl dns wg0 10.8.0.53 seguit de resolvectl domain wg0 '~corp.example'; tots dos desapareixen quan ho fa la interfície, que és just el que vols per a un ajust delimitat al túnel.

Delimita el sufix en lloc d’empassar-te cada consulta

Apuntar tota la llista de resolutors del client al teu servidor intern és fàcil i gairebé sempre erroni. Llavors cada nom públic es resol des de la sortida del teu centre de dades, les CDN retornen adreces llunyanes i una caiguda del resolutor s’endú la navegació de l’usuari.

Envia cap a dins només el sufix privat. A systemd-resolved, un domini que comença per ~ és només d’encaminament, així que ~corp.example vol dir que les consultes sota aquest sufix van als servidors d’aquell enllaç mentre tota la resta continua usant la xarxa física. Windows fa el mateix amb regles NRPT delimitades a un espai de noms, i macOS amb un fitxer de resolutor suplementari sota /etc/resolver/.

Els noms de multidifusió mereixen la seva pròpia resposta. Els noms .local són locals a l’enllaç per disseny (RFC 6762) i una interfície tun punt a punt no transporta aquest grup de multidifusió, així que afegir un resolutor públic no els publica i preguntar-los a un resolutor intern d’unidifusió retorna NXDOMAIN. Un reflector com avahi en mode reflector pot unir dos segments, però això és una decisió del costat del servidor que cap client pot demanar. Si una impressora o un NAS ha de ser accessible pel nom, dona-li un registre A a la teva zona.

Demostra que la resposta pot tornar

Una resposta correcta que apunta a una adreça inabastable sembla exactament un problema de resolutor fins que comproves la ruta. Pregunta al nucli on aniria la resposta: ip route get 10.20.5.20 anomena la interfície i, més útil, l’adreça d’origen que faria servir.

Vigila l’adreça del resolutor. Un client amb DNS = 10.8.0.53 al costat de AllowedIPs = 10.20.0.0/16 envia les seves consultes per la NIC física, on moren en silenci, perquè el resolutor no és dins de cap prefix que el túnel reivindiqui. Aquesta discordança és la fallada de causa única més comuna en tota aquesta àrea, i és invisible tret que comparis l’ajust de DNS amb els prefixos permesos línia per línia.

Els rangs solapats causen la fallada contrària. La resposta és correcta, la ruta existeix i apunta a l’amfitrió equivocat, perquè 192.168.0.0/24 a casa és més específica que la ruta del túnel al mateix rang. Renumera un costat o empeny una ruta més estreta, i després confirma el tallafoc i el camí de tornada de l’amfitrió del servei; les notes de strongSwan sobre el reenviament cobreixen la part sysctl d’aquest camí.

Els certificats són una comprovació d’identitat a part que la gent carrega al DNS. Si el navegador informa d’un desajust de nom en lloc d’un error de resolució, la consulta ja va funcionar i el que cal arreglar és el SAN del certificat. Prova HTTPS contra el nom, mai contra la IP nua.

Torna a provar des del client, no des de la passarel·la

Prova dins de l’aplicació de la qual es queixa l’usuari, perquè una consulta a la línia d’ordres no demostra que el navegador segueixi el mateix camí. El DNS segur de Chrome i network.trr.mode de Firefox poden saltar-se el resolutor del sistema del tot, i quan ho fan, un nom privat falla o es filtra a un resolutor públic. Comparar resolvectl query amb un dig @10.8.0.53 files.corp.example executat a mà et diu quina de les dues coses va passar.

Després desconnecta i torna a connectar abans de donar-ho per arreglat. Els ajustos aplicats a mà a una interfície desapareixen amb la interfície, i un perfil que només semblava correcte per una edició local oblidada fallarà al proper arrencament.

Una llista curta per a la màquina següent: el nom es resol pel resolutor del túnel, el sufix està delimitat en lloc de global, l’adreça del resolutor cau dins dels prefixos permesos, l’amfitrió de la resposta respon al port del servei i el certificat cobreix el nom que va escriure l’usuari.