Miksi /etc/hosts-merkintäsi ei saavuta VPN:n DNS:ää

Lisäsit nimen tiedostoon /etc/hosts, yhdistit VPN:ään ja odotit, että tietue näkyisi kaikille. Niin ei käy, ja yllätys tulee yleensä toisen oireen kanssa: nimi ratkeaa koneellasi ja epäonnistuu kollegalla, mikä näyttää rikkinäiseltä VPN:n DNS-palvelulta ja on oikeasti hosts-tiedosto tekemässä täsmälleen sitä, mihin se on suunniteltu. Hosts-tiedosto on paikallinen nimien ratkaisun asetustiedosto, ei vyöhykkeen päivitys, eikä mikään tavallisessa VPN-yhteydessä lataa sitä.

Hosts on paikallinen ohitus, ei vyöhykkeen päivitys

Tiedosto on luettelo kuvauksista, joita nimipalvelukirjastot tarkistavat ennen DNS-palvelimelta kysymistä tai sen sijaan. Rivi kuten 10.40.0.20 build.corp.example muuttaa sitä, mitä sovellukset tuolla yhdellä koneella päättelevät. Se ei luo tietuetta, se ei kulje tunnelin läpi, eikä DNS-palvelin, johon tunneli osoittaa, tiedä sen olemassaolosta mitään.

Siksi epäonnistuminen on epäsymmetristä. Asiakkaasi saa vastauksen tiedostosta. Toinen asiakas kysyy VPN:n DNS-palvelimelta, joka ei palauta mitään, ja sovellus ilmoittaa, ettei nimeä ole olemassa. Molemmat koneet käyttäytyvät oikein; vain toisella on ohitus, jota toinen ei ole koskaan nähnyt.

Kaksi komentoa, kaksi eri komponenttia

Nopein tapa lopettaa väittely on tehdä ero näkyväksi kahdessa komennossa, jotka molemmat ajetaan asiakkaalla, jolla hosts-merkintä on:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Ensimmäinen kysyy järjestelmän omaa hakupolkua, joka tyypillisessä glibc-järjestelmässä lukee paikalliset tiedostot ennen DNS:ää. Toinen lähettää DNS-kyselyn suoraan kyseisessä osoitteessa olevalle palvelimelle eikä tarkista paikallisia tiedostoja lainkaan. Kun ensimmäinen palauttaa merkintäsi ja toinen palauttaa NXDOMAIN, olet todistanut, ettei tietuetta ole DNS:ssä ja että koneesi vastaa paikallisesta ohituksesta.

Järjestys on määritettävissä, ja se kannattaa tarkistaa ennen kuin päättelet mitään tietystä jakelusta. Katso rivin hosts: kohtaa tiedostossa /etc/nsswitch.conf; hosts: files dns tarkistaa tiedostot ensin. Älä kopioi tuota esimerkkiä toimivan kokoonpanon päälle vain järjestyksen muuttamiseksi, koska todelliset järjestelmät luettelevat usein lisälähteitä ja ehdollisia palvelumerkintöjä, joita esimerkissä ei ole.

systemd-resolved hämärtää testin

Järjestelmässä, joka käyttää systemd-resolvedia, paikallinen stub palvelee myös nimiä hosts-tietokannasta. Siksi 127.0.0.53:n kysely ei ole itsenäinen testi etäpalvelimelle, vaikka se näyttää DNS-kyselyltä ja käyttäytyy kuin sellainen. Voit vahvistaa, mitä resolver tietää ja miltä palvelimilta se kysyisi, näin:

resolvectl query build.corp.example
resolvectl status

Status-tuloste nimeää DNS-palvelimet linkeittäin, ja näin saat selville, saiko VPN-linkki ylipäätään resolverin. Tämä kysymys on erillinen hosts-merkinnästä ja se kannattaa kysyä, kun yksityinen nimi epäonnistuu kaikilla käyttäjillä eikä yhdellä.

Sovellukset voivat lisätä vielä yhden kerroksen. Selain, jolla on oma DNS-over-HTTPS-asetus, kontti, jolla on oma resolver-kokoonpano, tai ajonaikainen ympäristö, joka välimuistittaa haut prosessin koko eliniän ajan, voivat kukin vastata eri tavalla kuin järjestelmä. Testaa sovellusta, josta välität, sen sijaan että olettaisit yhden komennon kuvaavan jokaista koneen ohjelmaa.

Mikä oikeastaan jakaa nimen VPN:n yli

Jos yksityisen nimen on toimittava kaikille, se tarvitsee omistajan, johon kaikkien resolver pääsee. Puhdas vastaus on julkaista tietue hallitulla vyöhykkeellä ja tehdä vyöhykkeestä ratkeava aiottuun VPN:n DNS-reittiin. Silloin tietueella on yksi totuuden lähde, auditointijälki ja elinkaari, eikä kenenkään tarvitse muistaa, mikä kannettava kantaa paikallista ohitusta.

Hosts-tiedostojen jakelu on laillinen vaihtoehto, ja se on päätepisteiden hallintaa eikä nimipalvelu. Jos valitset sen, tiedoston on otettava käyttöön, versioitava ja poistettava sen toimesta, joka hallitsee laivastoa, ja niin se pitää suunnittelussa kuvata. “VPN hoitaa sen” ei ole kuvaus tuosta prosessista.

Dynaaminen DNS-rekisteröinti on kolmas mekanismi, jolla on omat käyttöoikeutensa, päivitysten todennus ja tietueen elinikä. Se ei seuraa hosts-merkinnästä, eikä se seuraa asiakkaan pelkästä yhdistämisestä, ellei palvelinta ja asiakasta ole molempia asetettu tekemään sitä. Itsestään ilmestyvä tietue on merkki siitä, että joku otti käyttöön turvalliset päivitykset ja asiakas, joka rekisteröi itsensä, ja se asetus kuuluu suunnittelutietueeseen eikä vianetsintäketjuun. Jos kukaan ei osaa nimetä kyseisen asetuksen omistajaa, käsittele automaattista tietuetta vahvistamattomana ja pidä hallittua vyöhykettä totuuden lähteenä.

Ratkennut nimi ei ole reitti

Nimien ratkaisu ja tavoitettavuus ovat erillisiä, ja vanhentunut paikallinen kuvaus on klassinen tapa sekoittaa ne. Hosts-merkintä, joka osoittaa osoitteeseen, joka on muuttanut, valitsee vanhentuneen isännän vielä kauan DNS:n korjaamisen jälkeen, ja oire näyttää reititysvirheeltä nimellä, joka ratkeaa hyvin.

Kun raportti siis kuuluu “nimi ratkeaa mutta palvelu ei ole tavoitettavissa”, vertaa järjestelmän hakua nimenomaiseen kyselyyn VPN:n DNS-palvelimelle ja tarkista sitten saamasi osoite sitä vasten, jota palvelu todella käyttää. systemd-resolved-viite dokumentoi paikalliset lähteet, joita se tarkistaa, ja se on kartta, jonka tarvitset tuota vertailua varten.

Korjaa sitten ohitus sen omistajan kautta. Rivin poistaminen omasta hosts-tiedostostasi ei tee mitään niille kahdelletoista kannettavalle, jotka saivat saman rivin käyttöönottoskriptistä, ja se on tämän ongelman se versio, joka ihmisillä oikeasti on.