VPN:n DNS toimii, mutta .local-nimet epäonnistuvat yhä: kuka ne ratkaisee?

Kaksi konetta samassa VPN:ssä, sama isäntänimi, ja vain yksi niistä ratkaisee sen: ero ei yleensä ole tunnelissa vaan siinä, mikä ratkaisija vastasi. Linux-työpöydällä nimi voi kulkea nimipalvelukytkimen kautta, systemd-resolvedin stubin kautta tai ratkaisijan kautta, jonka sovellus toi mukanaan, ja jokainen niistä soveltaa omaa sääntöään samaan päätteeseen. Juuri päätteessä säännöt erkanevat, koska .local ei ole neutraali merkintä. Selvitä, minkä polun epäonnistuva ohjelma todella kulkee, ennen kuin muutat järjestystä, jossa mikään ajetaan.

Kaksi ratkaisijaa, kaksi eri vastausta

Perinteinen glibc-haku kulkee nsswitch.conf:n hosts:-rivin läpi ja kysyy kutakin moduulia vuorollaan, kunnes yksi vastaa. Stub-kuuntelijan kautta systemd-resolvedin kanssa puhuva asiakas kysyy sen sijaan yhdeltä prosessilta, ja tuo prosessi soveltaa linkkikohtaista käytäntöä sekä omia erikoistapauksiaan. Sovellus, joka tuo mukanaan oman ratkaisijansa tai linkittää kirjaston, joka tekee niin, voi ohittaa molemmat. Yhdellä isäntänimellä voi siis olla kolme omistajaa yhdellä koneella, ja vain yksi heistä tietää, mitä VPN tarkoitti.

Tunnista omistaja ennen kuin muutat mitään, koska korjaus on erilainen jokaiselle kolmelle. Selain ja komentorivityökalu samalla työpöydällä voivat laillisesti olla eri mieltä, ja se erimielisyys on vihje, ei vika. Jos selain ratkaisee nimen eikä työkalu, korjaat ratkaisijan polkua etkä VPN:n reittiä. Vahvista reitti erikseen, jotta reititysvikaa ei sekoiteta nimipalveluvikaan. Kun molemmat ovat yhtä mieltä, vika on isännän yläpuolella eikä täkäläinen ratkaisijan kokoonpano ansaitse uutta muokkausta.

Mikä komento todella kysyi ratkaisijaltasi

Kaksi vain luku -komentoa vastaavat toisiinsa liittyviin kysymyksiin, ja niiden vertailu paikantaa ongelman nopeammin kuin kokoonpanon lukeminen. Käytä todellista sisäistä nimeä ja pidä tuloste yksityisenä, koska sisäiset tietueet pysyvät sisäisinä. Aja molemmat samassa istunnossa, jossa epäonnistuva ohjelma toimii:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Ensimmäinen kysyy määritettyjen moduulien kautta, mitä tyypillinen ohjelma kokee. Toinen kysyy suoraan systemd-resolvedilta ja raportoi linkin, protokollan ja palvelimen, joka vastasi. Yrityspalvelimelta osoitteella kysyminen todistaa vain, että palvelimella on tietue, koska se ei kerro mitään siitä, kysyikö sovellus sitä koskaan. Lue linkki, joka kantaa VPN:n, ja verkkotunnukset, joita se väittää, ja vertaa sitten luetteloa epäonnistuvan nimen päätteeseen.

Miksi .local ohittaa unicast-vyöhykkeesi

systemd-resolvedin viite toteaa, että usean tunnisteen nimet, jotka päättyvät .local, menevät yleensä multicast-DNS:ään, kun mDNS on käytössä, eivät tavalliseen unicast-DNS:ään. RFC 6762 varaa kyseisen nimiavaruuden link-local multicastille, joten yritysvyöhykkeellä voi olla oikea tietue, jota ei koskaan kysytä kyseiselle päätteelle. Tunneli voi reitittää ratkaisijan täydellisesti ja silti hävitä kilpailun. Välimuistista onnistuva ping ei kerro mitään juuri tapahtuneesta hausta.

On dokumentoitu poikkeus, ja se ratkaisee useimmat näistä tapauksista: kun linkki ilmoittaa kyseisen päätteen hakuverkkotunnukseksi tai reititysverkkotunnukseksi, daemon pitää sen unicast-polulla ja ohittaa multicastin erikoistapauksen. Se on linkkikohtainen käytäntö, ei maailmanlaajuinen mieltymys. Kaksi konetta samalla VPN-palvelimella voivat käyttäytyä eri tavoin, kun yksi verkkoprofiili ilmoittaa verkkotunnuksen eikä toinen, joten lue aktiivinen profiili, älä sitä jonka muistat muokanneesi.

Kapea poikkeus voittaa maailmanlaajuisen uudelleenjärjestelyn

Olemassa olevalle vyöhykkeelle, jota et voi nimetä uudelleen, pyydä ratkaisijan ja VPN:n omistajia ilmoittamaan verkkotunnus yhteydellä, joka sitä kantaa. Reititysverkkotunnuksen merkintä tuolle yhdelle päätteelle sekä aiottu palvelinosoite on pieni muutos, jolla on nimetty omistaja, ja se elää linkin mukana eikä käsin muokatussa tiedostossa.

Se kestää myös yhteyden katkeamisen, koska linkin käytäntö otetaan uudelleen käyttöön, kun linkki palaa. Jaetun nsswitch.conf:n muokkaaminen on houkutteleva ja kalliimpi vaihtoehto, koska se muuttaa hakukäyttäytymistä jokaiselle koneen nimelle, mukaan lukien paikallinen löytäminen. Multicast-daemonin poistaminen käytöstä ei ole myöskään vastaavaa: se poistaa paikallisen käyttäytymisen opettamatta millekään ratkaisijalle yritysvyöhykettä. Jos palvelu on uusi eikä peritty, aseta se aliverkkotunnukseen, jota organisaatiosi hallitsee, ja ohita kilpailu kokonaan. Valitse kapea poikkeus, kun nimi on kiinnitetty laiteohjelmistoon tai painettu tarraan, ja valitse uusi aliverkkotunnus, kun vielä hallitset asiakasta.

Mitä muutoksen jälkeen pitää todistaa

Todista korjaus sovelluksen omalla haulla, älä työkalulla, jonka asensit testaamista varten, ja tyhjennä kaikki välimuisti, joka voisi vastata sen puolesta. Vahvista sitten ratkaisijan polku ja vastauksen tarjonnut linkki. Tarkista lopuksi, että paikallinen löytäminen käyttäytyy kuten ennen muutosta, koska tulostin, joka lakkaa ilmestymästä, on se osa, jonka ihmiset huomaavat viimeksi. Nämä kolme komentoa tarkistavat nimen, polun ja TLS-identiteetin tässä järjestyksessä:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Oikea osoite väärällä varmenteella kaataa silti tiukan asiakkaan, joten tarkista nimi, jota sovellus odottaa, kun ratkaisu toimii. Vahvista, että palvelu hyväksyy yhteydet VPN-osoitteesta eikä vain toimiston alueelta. Kirjoita verkkotunnuksen laajuus, palvelin ja omistaja yhteyden dokumentaatioon. Muuten seuraava tähän vikaan törmäävä henkilö tarttuu samaan maailmanlaajuiseen muokkaukseen, jonka juuri välstit.