Quin enllaç respon: dominis d’encaminament per al DNS d’una VPN amb túnel dividit

Manteniu la navegació ordinària a l’enllaç local mentre els noms de l’empresa es resolen a través del servidor DNS que proporciona el túnel. Desactivar la ruta per defecte de la VPN us dona la primera meitat i deixa la segona sense construir. El que segueix és el paràmetre que falta, la puntuació que en canvia el significat i l’única ordre que mostra quin enllaç ha respost realment. Se suposen NetworkManager i systemd-resolved al llarg del text, perquè és en aquesta parella on sol començar la confusió.

Pas u: separeu la ruta del resolutor

ipv4.never-default respon una pregunta d’encaminament i impedeix que NetworkManager instal·li aquesta connexió com a camí per a tot el trànsit IPv4. Un domini d’encaminament DNS respon una altra pregunta: quins servidors de noms de quin enllaç reben una consulta per a un sufix coincident. Cap dels dos no implica l’altre, i un perfil pot portar-ne un durant anys mentre li falta l’altre. Només ruta vol dir que el túnel transporta les subxarxes de l’empresa i que el seu resolutor respon els noms de l’empresa, mentre que tota la resta es deixa tranquil·la.

Definiu només la propietat de ruta i els noms interns fallen, normalment amb un temps d’espera que sembla un túnel trencat. Definiu només el domini i heu afegit en silenci un sufix de cerca a cada nom curt de la màquina. Tots dos errors envien el tiquet al servidor VPN, que poques vegades és la part que està malament.

Pas dos: afegiu un domini només d’encaminament al perfil

Suposeu que la connexió es diu corp-vpn, que el sufix de l’empresa és internal.example i que el resolutor del túnel ja és abastable. Llegiu primer els valors actuals, perquè les ordres de sota canvien propietats que ja poden contenir entrades.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Substituïu el nom de connexió i el sufix pels vostres, perquè els valors de dalt són il·lustratius. El signe més importa més del que sembla: amb ell el valor s’afegeix a la llista existent, mentre que sense ell la propietat se substitueix i dominis no relacionats desapareixen d’un perfil que ahir funcionava. La titlla canvia el comportament, no l’estil, i el paràgraf de sota explica què selecciona. Manteniu la lectura abans de l’escriptura, perquè la forma de substitució no us sorprengui mai.

Una titlla inicial marca un domini només d’encaminament, de manera que les consultes coincidents van als servidors d’aquest enllaç i el sufix no s’afegeix als noms curts. Traieu la titlla i la mateixa cadena també es converteix en un sufix de cerca, que és un resultat diferent que la gent poques vegades vol. Els dos paràmetres de dalt són IPv4, així que un perfil de doble pila necessita ipv6.never-default i el mateix domini d’encaminament a ipv6.dns-search, o el costat IPv6 continua usant la ruta per defecte i els noms interns hi fallen.

Pas tres: pregunteu a resolvectl quin enllaç ha respost

Executeu resolvectl status i llegiu els servidors DNS i els dominis de cada enllaç, i després executeu resolvectl query host.internal.example contra un nom intern real que tingueu permís per consultar. La segona ordre és l’única prova directa que el domini d’encaminament fa la seva feina, perquè anomena l’enllaç que ha respost. Un llistat d’estat només prova la configuració; la consulta prova la resolució.

systemd-resolved tria el domini d’encaminament que coincideix millor, així que un domini més específic en un altre enllaç encara pot guanyar la cursa. Si la consulta torna d’un enllaç que no esperàveu, llegiu les llistes de dominis abans de tocar el servidor DNS de la VPN. Un domini arrel de ~. coincideix amb tot, i si ja hi és, el vostre domini específic encara guanya per als seus noms mentre l’enllaç respon molt més del que heu demanat. Elimineu o estretiu aquella entrada arrel quan la intenció era només noms de l’empresa.

Si l’enllaç de la VPN no llista cap servidor DNS, el client no n’ha registrat mai cap. Un domini d’encaminament sense servidor al darrere falla de manera diferent d’un domini que falta, així que primer arregleu el registre.

Pas quatre: quan el nom es resol però el servei no

Una resposta correcta només prova que la resolució ha funcionat, i l’aplicació encara necessita una ruta cap a l’adreça que ha rebut. Aquesta ruta ha de sobreviure a la ruta per defecte dividida que acabeu de configurar, així que comproveu-la abans de tornar a culpar el DNS. Després comproveu l’abastabilitat al port del servei, perquè un recurs compartit o un servei de directori falla en la resolució, l’encaminament o l’autenticació i produeix missatges molt semblants en cada cas. Manteniu aquestes tres capes separades quan informeu del resultat, o la persona següent torna a comprovar un DNS que ja era correcte.

El canvi de Samba que circula al costat d’aquesta pregunta tracta la capa d’accés, no l’elecció de DNS. Aplicar-lo a una fallada de resolució de noms és com un problema petit n’adquireix un segon.

Pas cinc: no substituïu el resolutor per arreglar un domini que falta

El consell que sobreescriu el fitxer del resolutor o instal·la un altre gestor de resolutor resol un problema diferent. Són canvis d’integració del sistema amb els seus propis modes de fallada, i cap d’ells afegeix un domini d’encaminament que mai no s’ha configurat. Establiu quin component posseeix la resolució de noms a la màquina abans de substituir-lo, perquè en un escriptori amb NetworkManager i systemd-resolved aquesta propietat ja està definida. Barallar-s’hi és com una configuració que funciona es converteix en una cosa que ningú no pot reproduir.

Ordre de treball: confirmeu que el túnel proporciona un resolutor, afegiu el domini només d’encaminament, torneu a connectar mitjançant els controls del perfil, verifiqueu l’enllaç que respon i després proveu el servei al seu port. Aquesta seqüència deixa un resultat que podeu lliurar a la persona següent sense una segona entrevista.