ip netns exec ir DNS: kodėl vardai nepavyksta vardų erdvėje

Komanda pasiekia 10.8.0.5 VPN vardų erdvės viduje be jokių nusiskundimų, o ta pati komanda nepavyksta tą akimirką, kai naudoja pagrindinio kompiuterio vardą. Vardų erdvė turi savo sąsajas, maršrutus ir lizdus; ji neturi savo resolverio failo. Jei kas nors neįdeda ten vieno, viduje esantis procesas skaito pagrindinio kompiuterio /etc/resolv.conf ir klausia serverio, kuris gali būti nepasiekiamas iš to tinklo kamino.

Tai failo pasirinkimo problema, o ne maršrutizavimo problema, ir būtent todėl skaitmeninė paskirtis vis dar veikia.

Patikrinkite resolverio vaizdą, kurį procesas iš tikrųjų gauna

Nedarykite prielaidos, kad naudota shell yra lygiavertė procesui, kurį derinate. Grafinė programa, systemd blokas ir konteineris gali kiekvienas patekti į kitą prijungimo ar tinklo kontekstą. Vykdykite užklausą tuo pačiu paleidimo keliu ir išspausdinkite resolverio failą iš vidaus.

Vardų erdvei, sukurtai su ip netns add, tik skaitymo patikra trumpa:

ip netns exec vpn cat /etc/resolv.conf

Atkreipkite dėmesį, ar rezultatas nurodo pasiekiamą adresą, loopback stub, ar simbolinę nuorodą, kuri rodo į vietą su kitokiu pasiekiamumu.

Ką exec pagalbininkas iš tikrųjų prijungia

Įrankis ip-netns dokumentuoja kiekvienos vardų erdvės konfigūraciją po /etc/netns/NAME/. Kai jis paleidžia procesą, pagalbininkas sukuria prijungimo vardų erdvę ir prijungia tuos failus virš jų įprastų kelių, todėl procesas mato vardų erdvei būdingą kopiją. Tai šio konkretaus paleidiklio patogumas. Į tinklo vardų erdvę patekti kitu keliu, pavyzdžiui, per unshare ar konteinerių runtime, to automatiškai nekartoja.

Loopback resolveris čia yra spąstai: 127.0.0.53 reiškia pačios vardų erdvės loopback, o ne pagrindinio kompiuterio stub. Stub, kuris klausosi tik pagrindinio kompiuterio vardų erdvėje, naujojoje netampa tarnyba.

Pasirinkite resolverį, kurį vardų erdvė gali pasiekti

Kad ir kurį serverį failas nurodytų, jam vis tiek reikia maršruto iš tos vardų erdvės. Viešas resolveris gali atsakyti į viešus vardus ir vis tiek nepavykti vidinės zonos atveju, nes privati tarnyba pasiekiama tik per tunelį. Tikrinkite maršrutą kartu su adresu, o ne po to, kai užklausa jau nepavyko.

Programos su savo resolveriu, pavyzdžiui, naudojanti DNS over HTTPS, gali visiškai nepaisyti failo. Jei įrankis turi savo DNS nustatymą, resolv.conf pakeitimas jam neturės įtakos, o vardų erdvė niekada nebuvo problema.

Įrašykite failą tinkamoje vietoje

Sukurkite vardų erdvei būdingą failą po /etc/netns/NAME/resolv.conf ir leiskite paleidikliui jį pateikti. Laikykite jį minimalų: vieną ar du pasiekiamus serverius ir paieškos domenus, kurių užduočiai reikia. Neredaguokite sugeneruoto pagrindinio kompiuterio resolverio failo, kad sutvarkytumėte vaizdą, skirtą vienai procesų grupei, nes tai pakeistų kiekvieną mašinos programą. Jei pagrindinis kompiuteris naudoja resolverio tvarkyklę, sukonfigūruokite vardų erdvės kelią per tą tvarkyklę, o ne kovokite su ja.

Užrašykite failo turinį runbooke. Priešingu atveju kitas žmogus išbandys pagrindinio kompiuterio resolverį, pamatys veikiantį atsakymą ir padarys išvadą, kad vardų erdvė tvarkinga.

Iš naujo išbandykite visą kelią

Išbandykite vardų erdvės viduje su skaitmeniniu adresu, vidiniu vardu ir viešu vardu. Ši seka atskiria pasiekiamumą nuo sprendimo ir atskiria vidines zonas nuo viešų. Tada iš naujo sukurkite vardų erdvę ir pakartokite, nes failas, kuris egzistuoja tik veikiančioje instancijoje, išnyksta kartu su ja.

Patvirtinkite, kad failą gauna procesas, o ne shell. Užklausa, kuri veikia iš interaktyvaus shell ir nepavyksta iš tarnybos, yra radinys apie prijungimo kontekstą, ir verta jį užrašyti prieš kitą incidentą, o ne atrasti iš naujo nuo nulio.