ip netns exec e DNS: por que fallan os nomes dentro do espazo de nomes

Unha orde chega a 10.8.0.5 dentro do espazo de nomes da VPN sen queixa ningunha, e a mesma orde falla no momento en que usa un nome de host. O espazo de nomes ten as súas propias interfaces, rutas e sockets; non ten o seu propio ficheiro de resolución. A menos que algo coloque un alí, o proceso de dentro le o /etc/resolv.conf do host e pregunta a un servidor que pode non ser alcanzable desde esa pila de rede.

Trátase dun problema de selección de ficheiro e non de encamiñamento, e por iso mesmo o destino numérico segue funcionando.

Comprobe a vista do resolvedor que o proceso recibe realmente

Non dea por feito que a consola que usou equivale ao proceso que está depurando. Unha aplicación gráfica, unha unidade de systemd e un contedor poden entrar cada un nun contexto de montaxe ou de rede distinto. Execute a consulta pola mesma ruta de lanzamento e imprima o ficheiro do resolvedor desde dentro.

Para un espazo de nomes creado con ip netns add, a comprobación de só lectura é breve:

ip netns exec vpn cat /etc/resolv.conf

Fíxese en se o resultado nomea un enderezo alcanzable, un stub de loopback ou unha ligazón simbólica que apunta a un lugar cunha alcanzabilidade distinta.

Que monta realmente o axudante exec

A ferramenta ip-netns documenta a configuración por espazo de nomes en /etc/netns/NAME/. Cando lanza un proceso, o axudante crea un espazo de nomes de montaxe e monta eses ficheiros sobre as súas rutas habituais, de xeito que o proceso ve a copia específica do espazo de nomes. Iso é unha comodidade deste lanzador concreto. Entrar nun espazo de nomes de rede por outra vía, como unshare ou un runtime de contedores, non o reproduce automaticamente.

O resolvedor de loopback é a trampa aquí: 127.0.0.53 significa o loopback do propio espazo de nomes, non o stub do host. Un stub que só escoita no espazo de nomes do host non se converte nun servizo no novo.

Escolla un resolvedor ao que o espazo de nomes poida chegar

Sexa cal sexa o servidor que o ficheiro nomee, segue necesitando unha ruta desde ese espazo de nomes. Un resolvedor público pode responder nomes públicos e aínda así fallar para unha zona interna, porque o servizo privado só é alcanzable a través do túnel. Comprobe a ruta ao mesmo tempo que o enderezo, non despois de que a consulta xa fallase.

As aplicacións con resolvedor propio, como unha que use DNS sobre HTTPS, poden ignorar o ficheiro por completo. Se a ferramenta ten a súa propia configuración de DNS, cambiar resolv.conf non a afectará, e o espazo de nomes nunca foi o problema.

Escriba o ficheiro no lugar correcto

Cree o ficheiro por espazo de nomes en /etc/netns/NAME/resolv.conf e deixe que o lanzador o presente. Mantéñao mínimo: un ou dous servidores alcanzables e os dominios de busca que a tarefa necesita. Non edite o ficheiro de resolvedor xerado do host para arranxar unha vista pensada para un grupo de procesos, porque iso cambia todas as aplicacións da máquina. Se o host usa un xestor de resolvedor, configure a ruta do espazo de nomes a través dese xestor en lugar de pelearse con el.

Rexiste o contido do ficheiro no runbook. Se non, a seguinte persoa probará o resolvedor do host, verá unha resposta que funciona e concluirá que o espazo de nomes está ben.

Volva probar todo o percorrido

Probe dentro do espazo de nomes cun enderezo numérico, un nome interno e un nome público. Esa secuencia separa a alcanzabilidade da resolución e separa as zonas internas das públicas. Despois recree o espazo de nomes e repita, porque un ficheiro que só existe nunha instancia en execución desaparece con ela.

Confirme que é o proceso, e non a consola, quen recibe o ficheiro. Unha consulta que funciona desde unha consola interactiva e falla desde un servizo é un achado de contexto de montaxe, e paga a pena anotalo antes do seguinte incidente en lugar de volver descubrilo desde cero.