ip netns exec e DNS: perché i nomi falliscono dentro lo spazio dei nomi

Un comando raggiunge 10.8.0.5 dentro lo spazio dei nomi della VPN senza alcuna lamentela, e lo stesso comando fallisce nel momento in cui usa un nome host. Lo spazio dei nomi ha le proprie interfacce, rotte e socket; non ha il proprio file di risoluzione. A meno che qualcosa non ne metta uno lì, il processo all’interno legge il /etc/resolv.conf dell’host e interroga un server che potrebbe non essere raggiungibile da quello stack di rete.

È un problema di selezione del file e non di instradamento, ed è proprio per questo che la destinazione numerica funziona ancora.

Verificate la vista del resolver che il processo riceve davvero

Non date per scontato che la shell usata sia equivalente al processo che state depurando. Un’applicazione grafica, un’unità systemd e un contenitore possono ciascuno entrare in un contesto di mount o di rete diverso. Eseguite la ricerca attraverso lo stesso percorso di avvio e stampate il file del resolver dall’interno.

Per uno spazio dei nomi creato con ip netns add, il controllo in sola lettura è breve:

ip netns exec vpn cat /etc/resolv.conf

Notate se il risultato nomina un indirizzo raggiungibile, uno stub di loopback o un collegamento simbolico che punta a un luogo con raggiungibilità diversa.

Che cosa monta davvero l’helper exec

Lo strumento ip-netns documenta la configurazione per spazio dei nomi sotto /etc/netns/NAME/. Quando avvia un processo, l’helper crea uno spazio dei nomi di mount e monta quei file sopra i loro percorsi abituali, così il processo vede la copia specifica dello spazio dei nomi. È una comodità di questo particolare lanciatore. Entrare in uno spazio dei nomi di rete per un’altra via, come unshare o un runtime di container, non lo riproduce automaticamente.

Il resolver di loopback è la trappola qui: 127.0.0.53 significa il loopback dello spazio dei nomi stesso, non lo stub dell’host. Uno stub che ascolta solo nello spazio dei nomi dell’host non diventa un servizio in quello nuovo.

Scegliete un resolver che lo spazio dei nomi possa raggiungere

Qualunque server il file nomini, ha comunque bisogno di una rotta da quello spazio dei nomi. Un resolver pubblico può rispondere a nomi pubblici e fallire comunque per una zona interna, perché il servizio privato è raggiungibile solo attraverso il tunnel. Controllate la rotta insieme all’indirizzo, non dopo che la ricerca è già fallita.

Le applicazioni con un proprio resolver, come quella che usa DNS su HTTPS, possono ignorare del tutto il file. Se lo strumento ha la propria impostazione DNS, modificare resolv.conf non lo influenzerà, e lo spazio dei nomi non è mai stato il problema.

Scrivete il file nel posto giusto

Create il file per spazio dei nomi sotto /etc/netns/NAME/resolv.conf e lasciate che il lanciatore lo presenti. Mantenetelo minimo: uno o due server raggiungibili e i domini di ricerca che il compito richiede. Non modificate il file di resolver generato dell’host per correggere una vista pensata per un gruppo di processi, perché questo cambia ogni applicazione della macchina. Se l’host usa un gestore di resolver, configurate il percorso dello spazio dei nomi tramite quel gestore invece di combatterlo.

Registrate il contenuto del file nel runbook. Altrimenti la persona successiva proverà il resolver dell’host, vedrà una risposta che funziona e concluderà che lo spazio dei nomi è a posto.

Provate di nuovo l’intero percorso

Provate dentro lo spazio dei nomi con un indirizzo numerico, un nome interno e un nome pubblico. Questa sequenza separa la raggiungibilità dalla risoluzione e separa le zone interne da quelle pubbliche. Poi ricreate lo spazio dei nomi e ripetete, perché un file che esiste solo in un’istanza in esecuzione scompare con essa.

Confermate che è il processo, e non la shell, a ricevere il file. Una ricerca che funziona da una shell interattiva e fallisce da un servizio è un riscontro sul contesto di mount, e vale la pena scriverlo prima del prossimo incidente invece di riscoprirlo da zero.