ip netns exec kaj DNS: kial nomoj malsukcesas ene de la nomspaco

Komando atingas 10.8.0.5 ene de la VPN-nomspaco sen plendo, kaj la sama komando malsukcesas tuj kiam ĝi uzas gastigantan nomon. La nomspaco havas proprajn interfacojn, itinerojn kaj ingojn; ĝi ne havas propran solvilan dosieron. Se io ne metas unu tien, la procezo interne legas la /etc/resolv.conf de la gastiganto kaj demandas servilon, kiu eble ne atingeblas el tiu retstako.

Tio estas dosier-elekta problemo, ne itinera problemo, kaj ĝuste tial la numera celo ankoraŭ funkcias.

Kontrolu la solvilan vido, kiun la procezo fakte ricevas

Ne supozu, ke la ŝelo, kiun vi uzis, estas ekvivalenta al la procezo, kiun vi sencimigas. Grafika aplikaĵo, systemd-unuo kaj ujo povas ĉiu eniri alielan muntan aŭ retan kuntekston. Rulu la serĉon tra la sama lanĉa vojo, kaj presu la solvilan dosieron de interne.

Por nomspaco kreita per ip netns add, la nurlega kontrolo estas mallonga:

ip netns exec vpn cat /etc/resolv.conf

Rimarku, ĉu la rezulto nomas atingeblan adreson, loopback-stubon aŭ simbola ligilo, kiu montras al loko kun alia atingeblo.

Kion la exec-helpanto fakte muntas

La ilo ip-netns dokumentas agordon por ĉiu nomspaco sub /etc/netns/NAME/. Kiam ĝi lanĉas procezon, la helpanto kreas muntan nomspacon kaj muntas tiujn dosierojn super iliaj kutimaj vojoj, tiel ke la procezo vidas la nomspaco-specifan kopion. Tio estas oportunaĵo de ĉi tiu konkreta lanĉilo. Eniri retan nomspacon per alia vojo, ekzemple per unshare aŭ uja runtime, ne reproduktas tion aŭtomate.

La loopback-solvilo estas la kaptilo ĉi tie: 127.0.0.53 signifas la propran loopback de la nomspaco, ne la stubon de la gastiganto. Stubo, kiu aŭskultas nur en la gastiganta nomspaco, ne fariĝas servo en la nova.

Elektu solvilon, kiun la nomspaco povas atingi

Kiun ajn servilon la dosiero nomas, ĝi ankoraŭ bezonas itinero el tiu nomspaco. Publika solvilo povas respondi publikajn nomojn kaj tamen malsukcesi por interna zono, ĉar la privata servo atingeblas nur tra la tunelo. Kontrolu la itinerojn samtempe kun la adreso, ne post kiam la serĉo jam malsukcesis.

Aplikaĵoj kun propra solvilo, ekzemple tiu, kiu uzas DNS over HTTPS, povas tute ignori la dosieron. Se la ilo havas propran DNS-agordon, ŝanĝi resolv.conf ne efikos al ĝi, kaj la nomspaco neniam estis la problemo.

Skribu la dosieron en la ĝustan lokon

Kreu la dosieron por nomspaco sub /etc/netns/NAME/resolv.conf kaj lasu la lanĉilon prezenti ĝin. Tenu ĝin minimuma: unu aŭ du atingeblaj serviloj kaj la serĉaj domajnoj, kiujn la tasko bezonas. Ne redaktu la generitan solvilan dosieron de la gastiganto por ripari vido destinitan al unu grupo da procezoj, ĉar tio ŝanĝas ĉiun aplikaĵon sur la maŝino. Se la gastiganto uzas solvilan administrilon, agordu la nomspacan vojon tra tiu administrilo anstataŭ batali kontraŭ ĝi.

Notu la dosieran enhavon en la runbook. Alie la sekva persono testos la solvilon de la gastiganto, vidos funkciantan respondon kaj konkludos, ke la nomspaco estas en ordo.

Retestu la tutan vojon

Testu ene de la nomspaco per numera adreso, interna nomo kaj publika nomo. Tiu sinsekvo apartigas atingeblon de solvado kaj apartigas internajn zonojn de publikaj. Poste rekrei la nomspacon kaj ripetu, ĉar dosiero, kiu ekzistas nur en kuranta okazo, malaperas kun ĝi.

Konfirmu, ke la procezo, ne la ŝelo, ricevas la dosieron. Serĉo, kiu funkcias el interaga ŝelo kaj malsukcesas el servo, estas trovo pri munta kunteksto, kaj indas skribi ĝin antaŭ la sekva incidento anstataŭ remalkovri ĝin de nulo.