ip netns exec și DNS: de ce eșuează numele în spațiul de nume

O comandă ajunge la 10.8.0.5 în interiorul spațiului de nume VPN fără nicio reclamație, iar aceeași comandă eșuează în momentul în care folosește un nume de gazdă. Spațiul de nume are propriile interfețe, rute și socketuri; nu are propriul fișier de rezolvare. Dacă ceva nu pune unul acolo, procesul din interior citește /etc/resolv.conf al gazdei și întreabă un server care poate să nu fie accesibil din acel stivă de rețea.

Aceasta este o problemă de selecție a fișierului, nu de rutare, și exact de aceea destinația numerică încă funcționează.

Verificați vizualizarea resolverului pe care procesul o primește de fapt

Nu presupuneți că shell-ul folosit este echivalent cu procesul pe care îl depanați. O aplicație grafică, o unitate systemd și un container pot fiecare intra în un alt context de montare sau de rețea. Rulați căutarea prin aceeași cale de lansare și tipăriți fișierul resolverului din interior.

Pentru un spațiu de nume creat cu ip netns add, verificarea doar pentru citire este scurtă:

ip netns exec vpn cat /etc/resolv.conf

Observați dacă rezultatul numește o adresă accesibilă, un stub de loopback sau o legătură simbolică ce indică un loc cu altă accesibilitate.

Ce montează de fapt ajutorul exec

Instrumentul ip-netns documentează configurația per spațiu de nume sub /etc/netns/NAME/. Când lansează un proces, ajutorul creează un spațiu de nume de montare și montează acele fișiere peste căile lor obișnuite, astfel încât procesul vede copia specifică spațiului de nume. Aceasta este o comoditate a acestui lansator anume. Intrarea într-un spațiu de nume de rețea pe altă cale, cum ar fi unshare sau un runtime de containere, nu reproduce asta automat.

Resolverul de loopback este capcana aici: 127.0.0.53 înseamnă loopback-ul propriu al spațiului de nume, nu stub-ul gazdei. Un stub care ascultă doar în spațiul de nume al gazdei nu devine serviciu în cel nou.

Alegeți un resolver la care spațiul de nume poate ajunge

Orice server ar numi fișierul, are în continuare nevoie de o rută din acel spațiu de nume. Un resolver public poate răspunde la nume publice și totuși eșua pentru o zonă internă, deoarece serviciul privat este accesibil doar prin tunel. Verificați ruta în același timp cu adresa, nu după ce căutarea a eșuat deja.

Aplicațiile cu resolver propriu, cum ar fi una care folosește DNS peste HTTPS, pot ignora complet fișierul. Dacă instrumentul are propria setare DNS, schimbarea resolv.conf nu o va afecta, iar spațiul de nume nu a fost niciodată problema.

Scrieți fișierul în locul potrivit

Creați fișierul per spațiu de nume sub /etc/netns/NAME/resolv.conf și lăsați lansatorul să îl prezinte. Țineți-l minim: unul sau două servere accesibile și domeniile de căutare de care are nevoie sarcina. Nu editați fișierul de resolver generat al gazdei pentru a repara o vizualizare destinată unui grup de procese, pentru că asta schimbă fiecare aplicație de pe mașină. Dacă gazda folosește un manager de resolver, configurați calea spațiului de nume prin acel manager în loc să vă luptați cu el.

Înregistrați conținutul fișierului în runbook. Altfel, următoarea persoană va testa resolverul gazdei, va vedea un răspuns care funcționează și va concluziona că spațiul de nume este în regulă.

Testați din nou întreaga cale

Testați în interiorul spațiului de nume cu o adresă numerică, un nume intern și un nume public. Această secvență separă accesibilitatea de rezolvare și separă zonele interne de cele publice. Apoi recreați spațiul de nume și repetați, pentru că un fișier care există doar într-o instanță în execuție dispare odată cu ea.

Confirmați că fișierul este primit de proces, nu de shell. O căutare care funcționează dintr-un shell interactiv și eșuează dintr-un serviciu este o constatare despre contextul de montare și merită notată înainte de următorul incident, în loc să fie redescoperită de la zero.