ip netns exec in DNS: zakaj imena v imenskem prostoru spodletijo

Ukaz doseže 10.8.0.5 znotraj imenskega prostora VPN brez kakršne koli pritožbe, isti ukaz pa spodleti v trenutku, ko uporabi ime gostitelja. Imenski prostor ima svoje vmesnike, poti in vtiče; nima svoje datoteke razreševalnika. Če nekaj ne položi ene tja, proces znotraj bere /etc/resolv.conf gostitelja in vpraša strežnik, ki morda ni dosegljiv iz tega omrežnega sklada.

To je težava izbire datoteke, ne pa usmerjanja, in prav zato številčni cilj še vedno deluje.

Preverite pogled razreševalnika, ki ga proces resnično prejme

Ne predpostavljajte, da je uporabljena lupina enaka procesu, ki ga razhroščujete. Grafična aplikacija, enota systemd in vsebnik lahko vsak vstopi v drugačen kontekst priklopa ali omrežja. Poizvedbo izvedite po isti poti zagona in natisnite datoteko razreševalnika od znotraj.

Za imenski prostor, ustvarjen z ip netns add, je preverjanje samo za branje kratko:

ip netns exec vpn cat /etc/resolv.conf

Bodite pozorni, ali rezultat navaja dosegljiv naslov, nadomestni vmesnik loopback ali simbolno povezavo, ki kaže na mesto z drugačno dosegljivostjo.

Kaj pomočnik exec dejansko priklopi

Orodje ip-netns dokumentira konfiguracijo za vsak imenski prostor pod /etc/netns/NAME/. Ko zažene proces, pomočnik ustvari imenski prostor priklopa in priklopi te datoteke nad njihove običajne poti, tako da proces vidi kopijo, specifično za imenski prostor. To je udobnost prav tega zaganjalnika. Vstop v omrežni imenski prostor po drugi poti, na primer prek unshare ali izvajalnega okolja vsebnikov, tega ne ponovi samodejno.

Razreševalnik na loopback je tu past: 127.0.0.53 pomeni lastni loopback imenskega prostora, ne nadomestnega vmesnika gostitelja. Nadomestni vmesnik, ki posluša le v imenskem prostoru gostitelja, v novem ne postane storitev.

Izberite razreševalnik, do katerega imenski prostor lahko doseže

Kateri koli strežnik naj datoteka navede, še vedno potrebuje pot iz tega imenskega prostora. Javni razreševalnik lahko odgovori na javna imena in vseeno spodleti za notranjo cono, ker je zasebna storitev dosegljiva le skozi tunel. Pot preverite hkrati z naslovom, ne šele potem, ko je poizvedba že spodletela.

Aplikacije z lastnim razreševalnikom, na primer tista, ki uporablja DNS prek HTTPS, lahko datoteko popolnoma prezrejo. Če ima orodje lastno nastavitev DNS, sprememba resolv.conf nanj ne bo vplivala in imenski prostor nikoli ni bil težava.

Datoteko zapišite na pravo mesto

Ustvarite datoteko za imenski prostor pod /etc/netns/NAME/resolv.conf in pustite zaganjalniku, da jo predstavi. Naj bo minimalna: en ali dva dosegljiva strežnika in iskalne domene, ki jih naloga potrebuje. Ne urejajte ustvarjene datoteke razreševalnika gostitelja, da bi popravili pogled, namenjen eni skupini procesov, ker to spremeni vsako aplikacijo na stroju. Če gostitelj uporablja upravitelja razreševalnika, nastavite pot imenskega prostora prek tega upravitelja, namesto da bi se z njim borili.

Zapišite vsebino datoteke v runbook. Sicer bo naslednja oseba preizkusila razreševalnik gostitelja, videla delujoč odgovor in sklenila, da je imenski prostor v redu.

Znova preizkusite celotno pot

Preizkusite znotraj imenskega prostora s številčnim naslovom, notranjim imenom in javnim imenom. To zaporedje loči dosegljivost od razreševanja in loči notranje cone od javnih. Nato imenski prostor znova ustvarite in ponovite, ker datoteka, ki obstaja le v delujoči instanci, izgine z njo.

Potrdite, da datoteko prejme proces, ne lupina. Poizvedba, ki deluje iz interaktivne lupine in spodleti iz storitve, je ugotovitev o kontekstu priklopa, in vredno jo je zapisati pred naslednjim incidentom, namesto da bi jo znova odkrivali od začetka.