ip netns exec i DNS: per què fallen els noms dins de l’espai de noms

Una ordre arriba a 10.8.0.5 dins de l’espai de noms de la VPN sense cap queixa, i la mateixa ordre falla en el moment en què fa servir un nom d’amfitrió. L’espai de noms té les seves pròpies interfícies, rutes i sockets; no té el seu propi fitxer de resolució. Si res no hi posa un fitxer, el procés de dins llegeix el /etc/resolv.conf de l’amfitrió i pregunta a un servidor que potser no és abastable des d’aquesta pila de xarxa.

Això és un problema de selecció de fitxer i no d’encaminament, i és exactament per això que la destinació numèrica encara funciona.

Comproveu la visió del resolutor que el procés rep realment

No assumeixis que l’intèrpret d’ordres que has fet servir equival al procés que estàs depurant. Una aplicació gràfica, una unitat de systemd i un contenidor poden entrar cadascun en un context de muntatge o de xarxa diferent. Executeu la consulta pel mateix camí de llançament i imprimiu el fitxer del resolutor des de dins.

Per a un espai de noms creat amb ip netns add, la comprovació de només lectura és curta:

ip netns exec vpn cat /etc/resolv.conf

Fixeu-vos si el resultat anomena una adreça abastable, un stub de loopback o un enllaç simbòlic que apunta a un lloc amb una abastabilitat diferent.

Què munta realment l’ajudant exec

L’eina ip-netns documenta la configuració per espai de noms sota /etc/netns/NAME/. Quan llança un procés, l’ajudant crea un espai de noms de muntatge i munta aquests fitxers sobre els seus camins habituals, de manera que el procés veu la còpia específica de l’espai de noms. Això és una comoditat d’aquest llançador concret. Entrar en un espai de noms de xarxa per una altra via, com ara unshare o un runtime de contenidors, no ho reprodueix automàticament.

El resolutor de loopback és el parany aquí: 127.0.0.53 vol dir el loopback propi de l’espai de noms, no el stub de l’amfitrió. Un stub que només escolta a l’espai de noms de l’amfitrió no es converteix en un servei al nou.

Trieu un resolutor al qual l’espai de noms pugui arribar

Sigui quin sigui el servidor que el fitxer anomena, encara necessita una ruta des d’aquest espai de noms. Un resolutor públic pot respondre noms públics i tot i així fallar per a una zona interna, perquè el servei privat només és abastable a través del túnel. Comproveu la ruta al mateix temps que l’adreça, no després que la consulta ja hagi fallat.

Les aplicacions amb resolutor propi, com ara una que fa servir DNS sobre HTTPS, poden ignorar el fitxer del tot. Si l’eina té la seva pròpia configuració de DNS, canviar resolv.conf no l’afectarà, i l’espai de noms mai no era el problema.

Escriviu el fitxer al lloc correcte

Creeu el fitxer per espai de noms sota /etc/netns/NAME/resolv.conf i deixeu que el llançador el presenti. Manteniu-lo mínim: un o dos servidors abastables i els dominis de cerca que la tasca necessita. No editeu el fitxer de resolutor generat de l’amfitrió per arreglar una visió pensada per a un grup de processos, perquè això canvia totes les aplicacions de la màquina. Si l’amfitrió fa servir un gestor de resolutor, configureu el camí de l’espai de noms a través d’aquest gestor en lloc de lluitar-hi.

Registreu el contingut del fitxer al runbook. Si no, la propera persona provarà el resolutor de l’amfitrió, veurà una resposta que funciona i conclourà que l’espai de noms està bé.

Torneu a provar tot el camí

Proveu dins de l’espai de noms amb una adreça numèrica, un nom intern i un nom públic. Aquesta seqüència separa l’abastabilitat de la resolució i separa les zones internes de les públiques. Després recrea l’espai de noms i repetiu-ho, perquè un fitxer que només existeix en una instància en execució desapareix amb ella.

Confirmeu que és el procés, i no l’intèrpret d’ordres, qui rep el fitxer. Una consulta que funciona des d’un intèrpret interactiu i falla des d’un servei és una troballa de context de muntatge, i val la pena escriure-la abans del proper incident en lloc de tornar-la a descobrir des de zero.