ip netns exec ja DNS: miks nimed nimeruumi sees ei toimi

Käsk jõuab VPN-i nimeruumi sees 10.8.0.5-ni ilma ühegi kaebuseta ja sama käsk nurjub hetkel, mil see kasutab hostinime. Nimeruumil on oma liidesed, marsruudid ja soklid; sellel ei ole oma resolveri faili. Kui miski ei pane sinna ühte, loeb sees olev protsess hosti /etc/resolv.conf faili ja küsib serverilt, mis ei pruugi sellest võrgupinust kättesaadav olla.

See on faili valiku probleem, mitte marsruutimise probleem, ja just seetõttu numbriline sihtkoht endiselt töötab.

Kontrollige resolveri vaadet, mille protsess tegelikult saab

Ärge eeldage, et kasutatud shell on samaväärne protsessiga, mida silute. Graafiline rakendus, systemd-üksus ja konteiner võivad igaüks siseneda teistsugusesse mount- või võrgukonteksti. Käivitage päring sama käivitusrada pidi ja printige resolveri fail seestpoolt.

ip netns add abil loodud nimeruumi puhul on ainult lugemise kontroll lühike:

ip netns exec vpn cat /etc/resolv.conf

Pange tähele, kas tulemus nimetab kättesaadavat aadressi, loopback-stub'i või sümboolset linki, mis osutab mujale, kus juurdepääsetavus on teistsugune.

Mida exec-abiline tegelikult mount'ib

Tööriist ip-netns dokumenteerib iga nimeruumi konfiguratsiooni asukoha /etc/netns/NAME/ all. Kui see protsessi käivitab, loob abiline mount-nimeruumi ja mount'ib need failid nende tavapäraste teede peale, nii et protsess näeb nimeruumipõhist koopiat. See on selle konkreetse käivitaja mugavus. Võrgu-nimeruumi sisenemine muud teed pidi, näiteks unshare või konteineri runtime'i kaudu, ei taasta seda automaatselt.

Loopback-resolver on siin lõks: 127.0.0.53 tähendab nimeruumi enda loopbacki, mitte hosti stub'i. Stub, mis kuulab ainult hosti nimeruumis, ei muutu uues nimeruumis teenuseks.

Valige resolver, kuhu nimeruum pääseb

Ükskõik millist serverit fail nimetab, see vajab endiselt marsruuti sellest nimeruumist. Avalik resolver võib vastata avalikele nimedele ja siiski sisemise tsooni puhul nurjuda, sest privaatne teenus on kättesaadav ainult tunnelist. Kontrollige marsruuti samal ajal aadressiga, mitte pärast seda, kui päring on juba nurjunud.

Oma resolveriga rakendused, näiteks DNS over HTTPS-i kasutav, võivad faili täiesti eirata. Kui tööriistal on oma DNS-i seade, ei mõjuta resolv.conf muutmine seda ja nimeruum ei olnud kunagi probleem.

Kirjutage fail õigesse kohta

Looge nimeruumipõhine fail asukohas /etc/netns/NAME/resolv.conf ja laske käivitajal see esitada. Hoidke see minimaalne: üks või kaks kättesaadavat serverit ja otsingudomeenid, mida ülesanne vajab. Ärge muutke hosti genereeritud resolveri faili, et parandada ühele protsessirühmale mõeldud vaadet, sest see muudab masina iga rakendust. Kui host kasutab resolverihaldurit, seadistage nimeruumi tee selle halduri kaudu, mitte võidelge sellega.

Kirjutage faili sisu runbooki. Muidu testib järgmine inimene hosti resolverit, näeb töötavat vastust ja järeldab, et nimeruum on korras.

Testige kogu rada uuesti

Testige nimeruumi sees numbrilise aadressiga, sisemise nimega ja avaliku nimega. See järjestus eraldab juurdepääsetavuse lahendamisest ja eraldab sisemised tsoonid avalikest. Seejärel looge nimeruum uuesti ja korrake, sest fail, mis eksisteerib ainult töötavas eksemplaris, kaob koos sellega.

Kinnitage, et faili saab protsess, mitte shell. Päring, mis töötab interaktiivsest shellist ja nurjub teenusest, on mount-konteksti leid ja seda tasub enne järgmist juhtumit kirja panna, mitte nullist uuesti avastada.