ip netns exec y DNS: por qué fallan los nombres dentro del espacio de nombres

Un comando llega a 10.8.0.5 dentro del espacio de nombres de la VPN sin queja alguna, y el mismo comando falla en el momento en que usa un nombre de host. El espacio de nombres tiene sus propias interfaces, rutas y sockets; no tiene su propio archivo de resolución. Salvo que algo coloque uno allí, el proceso de dentro lee el /etc/resolv.conf del host y pregunta a un servidor que puede no ser alcanzable desde esa pila de red.

Se trata de un problema de selección de archivo y no de enrutamiento, y por eso mismo el destino numérico sigue funcionando.

Compruebe la vista del resolutor que el proceso recibe realmente

No dé por hecho que el intérprete de órdenes que usó equivale al proceso que está depurando. Una aplicación gráfica, una unidad de systemd y un contenedor pueden entrar cada uno en un contexto de montaje o de red distinto. Ejecute la consulta por la misma ruta de lanzamiento e imprima el archivo del resolutor desde dentro.

Para un espacio de nombres creado con ip netns add, la comprobación de solo lectura es breve:

ip netns exec vpn cat /etc/resolv.conf

Fíjese en si el resultado nombra una dirección alcanzable, un stub de loopback o un enlace simbólico que apunta a un lugar con otra alcanzabilidad.

Qué monta realmente el ayudante exec

La herramienta ip-netns documenta la configuración por espacio de nombres en /etc/netns/NAME/. Cuando lanza un proceso, el ayudante crea un espacio de nombres de montaje y monta esos archivos sobre sus rutas habituales, de modo que el proceso ve la copia específica del espacio de nombres. Eso es una comodidad de este lanzador concreto. Entrar en un espacio de nombres de red por otra vía, como unshare o un runtime de contenedores, no lo reproduce automáticamente.

El resolutor de loopback es la trampa aquí: 127.0.0.53 significa el loopback del propio espacio de nombres, no el stub del host. Un stub que solo escucha en el espacio de nombres del host no se convierte en un servicio en el nuevo.

Elija un resolutor al que el espacio de nombres pueda llegar

Sea cual sea el servidor que el archivo nombre, sigue necesitando una ruta desde ese espacio de nombres. Un resolutor público puede responder nombres públicos y aun así fallar para una zona interna, porque el servicio privado solo es alcanzable a través del túnel. Compruebe la ruta al mismo tiempo que la dirección, no después de que la consulta ya haya fallado.

Las aplicaciones con resolutor propio, como una que use DNS sobre HTTPS, pueden ignorar el archivo por completo. Si la herramienta tiene su propia configuración de DNS, cambiar resolv.conf no la afectará, y el espacio de nombres nunca fue el problema.

Escriba el archivo en el lugar correcto

Cree el archivo por espacio de nombres en /etc/netns/NAME/resolv.conf y deje que el lanzador lo presente. Manténgalo mínimo: uno o dos servidores alcanzables y los dominios de búsqueda que la tarea necesita. No edite el archivo de resolutor generado del host para arreglar una vista pensada para un grupo de procesos, porque eso cambia todas las aplicaciones de la máquina. Si el host usa un gestor de resolutor, configure la ruta del espacio de nombres a través de ese gestor en lugar de pelearse con él.

Registre el contenido del archivo en el runbook. De lo contrario, la siguiente persona probará el resolutor del host, verá una respuesta que funciona y concluirá que el espacio de nombres está bien.

Vuelva a probar todo el recorrido

Pruebe dentro del espacio de nombres con una dirección numérica, un nombre interno y un nombre público. Esa secuencia separa la alcanzabilidad de la resolución y separa las zonas internas de las públicas. Después recree el espacio de nombres y repita, porque un archivo que solo existe en una instancia en ejecución desaparece con ella.

Confirme que es el proceso, y no el intérprete de órdenes, quien recibe el archivo. Una consulta que funciona desde un intérprete interactivo y falla desde un servicio es un hallazgo de contexto de montaje, y merece la pena anotarlo antes del siguiente incidente en lugar de volver a descubrirlo desde cero.