ip netns exec en DNS: waarom name binne die naamruimte misluk

’n Opdrag bereik 10.8.0.5 in die VPN-naamruimte sonder enige klagte, en dieselfde opdrag misluk sodra dit ’n masjiennaam gebruik. Die naamruimte het sy eie koppelvlakke, roetes en sissette; dit het nie ’n eie oplosserlêer nie. Tensy iets een daar plaas, lees die proses daarbinne die gasheer se /etc/resolv.conf en vra dit ’n bediener wat dalk nie vanaf daardie netwerkstapel bereikbaar is nie.

Dit is ’n lêerseleksieprobleem eerder as ’n roeteprobleem, en juis daarom werk die numeriese bestemming steeds.

Kyk na die oplosseraansig wat die proses werklik kry

Moenie aanneem dat die dop wat jy gebruik het, dieselfde is as die proses wat jy ontfout nie. ’n Grafiese toepassing, ’n systemd-eenheid en ’n houer kan elk ’n ander monteer- of netwerkkonteks betree. Voer die opsoek deur dieselfde bekendstellingsroete uit, en druk die oplosserlêer van binne daardie konteks.

Vir ’n naamruimte wat met ip netns add geskep is, is die lees-alleen-kontrole kort:

ip netns exec vpn cat /etc/resolv.conf

Let op of die resultaat ’n bereikbare adres, ’n loopback-stomp of ’n simskakel noem wat na ’n plek met ander bereikbaarheid wys.

Wat die exec-hulp werklik monteer

Die ip-netns-gereedskap dokumenteer per-naamruimte-konfigurasie onder /etc/netns/NAME/. Wanneer dit ’n proses lanseer, skep die hulp ’n monteernaamruimte en bind daardie lêers oor hul gewone paaie vas, sodat die proses die naamruimte-spesifieke kopie sien. Dit is ’n gerief van hierdie spesifieke lanseerder. Om ’n netwerknaamruimte via ’n ander roete te betree, soos unshare of ’n houer-tydren, reproduseer dit nie outomaties nie.

’n Loopback-oplosser is die lokval hier: 127.0.0.53 beteken die naamruimte se eie loopback, nie die gasheer se stomp nie. ’n Stomp wat net in die gasheernaamruimte luister, word nie ’n diens in die nuwe een nie.

Kies ’n oplosser wat die naamruimte kan bereik

Watter bediener die lêer ook al noem het steeds ’n roete vanaf daardie naamruimte nodig. ’n Openbare oplosser kan openbare name beantwoord en steeds vir ’n interne sone misluk, want die private diens is net deur die tonnel bereikbaar. Kontroleer die roete op dieselfde tyd as die adres, nie nadat die opsoek reeds misluk het nie.

Toepassings met hul eie oplosser, soos een wat DNS oor HTTPS gebruik, kan die lêer heeltemal ignoreer. As die gereedskap sy eie DNS-instelling het, sal die verandering van resolv.conf dit nie raak nie, en die naamruimte was nooit die probleem nie.

Skryf die lêer op die regte plek

Skep die per-naamruimte-lêer onder /etc/netns/NAME/resolv.conf en laat die lanseerder dit aanbied. Hou dit minimaal: een of twee bereikbare bedieners en die soekdomeine wat die taak nodig het. Moenie die gasheer se gegenereerde oplosserlêer wysig om ’n aansig vir een groep prosesse reg te maak nie, want dit verander elke toepassing op die masjien. As die gasheer ’n oplosserbestuurder gebruik, stel die naamruimte-pad deur daardie bestuurder op eerder as om teen dit te veg.

Teken die lêerinhoud in die runbook aan. Anders toets die volgende persoon die gasheer se oplosser, sien ’n werkende antwoord en kom tot die gevolgtrekking dat die naamruimte reg is.

Toets die hele pad weer

Toets binne die naamruimte met ’n numeriese adres, ’n interne naam en ’n openbare naam. Daardie volgorde skei bereikbaarheid van oplossing en skei interne sones van openbare sones. Skep dan die naamruimte weer en herhaal, want ’n lêer wat net in ’n lopende instansie bestaan, verdwyn saam met dit.

Bevestig dat die proses, nie die dop nie, die lêer ontvang. ’n Opsoek wat uit ’n interaktiewe dop werk en uit ’n diens misluk, is ’n monteerkonteks-bevinding, en dit is die moeite werd om dit voor die volgende voorval neer te skryf eerder as om dit van nuuts af weer te ontdek.