ip netns exec ja DNS: miksi nimet epäonnistuvat nimiavaruuden sisällä

Komento saavuttaa 10.8.0.5 VPN-nimiavaruuden sisällä ilman valituksia, ja sama komento epäonnistuu heti, kun se käyttää isäntänimeä. Nimiavaruudella on omat rajapintansa, reittinsä ja sokettinsa; sillä ei ole omaa resolveritiedostoa. Jollei jokin laita sellaista sinne, sisällä oleva prosessi lukee isännän /etc/resolv.conf-tiedoston ja kysyy palvelimelta, joka ei ehkä ole saavutettavissa tuosta verkkopinosta.

Kyse on tiedoston valinnasta eikä reitityksestä, ja juuri siksi numeerinen kohde toimii edelleen.

Tarkista resolverin näkymä, jonka prosessi todella saa

Älä oleta, että käyttämäsi komentotulkki vastaa prosessia, jota virität. Graafinen sovellus, systemd-yksikkö ja kontti voivat kukin siirtyä toisenlaiseen liitospiste- tai verkkoympäristöön. Suorita haku samaa käynnistyspolkua pitkin ja tulosta resolveritiedosto sen sisältä.

Nimiavaruudelle, joka on luotu komennolla ip netns add, vain luku -tarkistus on lyhyt:

ip netns exec vpn cat /etc/resolv.conf

Huomioi, nimeääkö tulos saavutettavan osoitteen, loopback-stubin vai symbolisen linkin, joka osoittaa paikkaan, jossa saavutettavuus on erilainen.

Miten exec-apuohjelma todella liittää

Työkalu ip-netns dokumentoi nimiavaruuskohtaisen kokoonpanon polun /etc/netns/NAME/ alle. Kun se käynnistää prosessin, apuohjelma luo liitosnimiavaruuden ja liittää nämä tiedostot niiden tavallisten polkujen päälle, joten prosessi näkee nimiavaruuskohtaisen kopion. Tämä on juuri tämän käynnistimen mukavuus. Verkkonimiavaruuteen siirtyminen toista kautta, esimerkiksi unshare-komennolla tai konttiajoympäristöllä, ei toista tätä automaattisesti.

Loopback-resolveri on tässä ansa: 127.0.0.53 tarkoittaa nimiavaruuden omaa loopbackia, ei isännän stubia. Stub, joka kuuntelee vain isännän nimiavaruudessa, ei muutu palveluksi uudessa.

Valitse resolveri, johon nimiavaruus pääsee

Minkä palvelimen tiedosto nimeääkin, se tarvitsee yhä reitin tuosta nimiavaruudesta. Julkinen resolveri voi vastata julkisiin nimiin ja epäonnistua silti sisäisen vyöhykkeen kohdalla, koska yksityinen palvelu on saavutettavissa vain tunnelin kautta. Tarkista reitti samaan aikaan osoitteen kanssa, älä vasta sen jälkeen kun haku on jo epäonnistunut.

Sovellukset, joilla on oma resolveri, kuten DNS over HTTPS -protokollaa käyttävä, voivat jättää tiedoston kokonaan huomiotta. Jos työkalulla on oma DNS-asetus, resolv.conf-tiedoston muuttaminen ei vaikuta siihen, eikä nimiavaruus ollut koskaan ongelma.

Kirjoita tiedosto oikeaan paikkaan

Luo nimiavaruuskohtainen tiedosto polun /etc/netns/NAME/resolv.conf alle ja anna käynnistimen esittää se. Pidä se mahdollisimman pienenä: yksi tai kaksi saavutettavaa palvelinta ja tehtävän tarvitsemat hakutoimialueet. Älä muokkaa isännän luomaa resolveritiedostoa korjataksesi näkymää, joka on tarkoitettu yhdelle prosessiryhmälle, sillä se muuttaa jokaista koneen sovellusta. Jos isäntä käyttää resolverin hallintaohjelmaa, määritä nimiavaruuden polku sen kautta sen sijaan, että taistelisit sitä vastaan.

Kirjaa tiedoston sisältö runbookiin. Muuten seuraava henkilö testaa isännän resolveria, näkee toimivan vastauksen ja päättelee, että nimiavaruus on kunnossa.

Testaa koko polku uudelleen

Testaa nimiavaruuden sisällä numeerisella osoitteella, sisäisellä nimellä ja julkisella nimellä. Tämä järjestys erottaa saavutettavuuden nimien ratkaisemisesta ja erottaa sisäiset vyöhykkeet julkisista. Luo sitten nimiavaruus uudelleen ja toista, sillä tiedosto, joka on olemassa vain käynnissä olevassa ilmentymässä, katoaa sen mukana.

Varmista, että tiedoston saa prosessi, ei komentotulkki. Haku, joka toimii interaktiivisesta komentotulkista ja epäonnistuu palvelusta, on liitosympäristöä koskeva löydös, ja se kannattaa kirjata ennen seuraavaa tapausta sen sijaan, että sen löytäisi uudelleen alusta.