VPN-i DNS töötab, aga .local-nimed ikka ei lahene: kes neid lahendab?

Kaks masinat samas VPN-is, sama hostinimi, ja ainult üks neist lahendab selle: erinevus pole tavaliselt tunnelis, vaid selles, milline resolver vastas. Linuxi töölaual võib see nimi liikuda nime teenuse lüliti kaudu, systemd-resolved-i stubi kaudu või resolveri kaudu, mille rakendus ise kaasa tõi, ja igaüks neist rakendab samale sufiksile oma reeglit. Just sufiksi juures lähevad reeglid lahku, sest .local ei ole neutraalne silt. Enne kui muudate järjekorda, milles miski jookseb, tehke kindlaks, millist teed ebaõnnestuv programm tegelikult läheb.

Kaks resolverit, kaks erinevat vastust

Traditsiooniline glibc-otsing käib läbi nsswitch.conf-i hosts: rea ja küsib iga moodulit järjest, kuni üks vastab. Klient, kes räägib systemd-resolved-iga stub-kuulaja kaudu, küsib selle asemel ühte protsessi, ja see protsess rakendab iga lingi kohta käivat poliitikat pluss oma erijuhtumeid. Rakendus, mis toob oma resolveri kaasa või linkib teegi, mis seda teeb, võib mõlemast mööda minna. Seega võib ühel hostinimel olla ühes masinas kolm omanikku, ja ainult üks neist teab, mida VPN silmas pidas.

Tehke omanik kindlaks enne millegi muutmist, sest parandus erineb iga kolme puhul. Brauser ja käsureatööriist samal töölaual võivad õiguspäraselt eriarvamusel olla, ja see eriarvamus on vihje, mitte viga. Kui brauser lahendab nime ja tööriist mitte, silute te resolveri teed, mitte VPN-i marsruuti. Kinnitage marsruut eraldi, et marsruutimise riket ei aetaks segamini nime teenuse rikkega. Kui mõlemad nõustuvad, on rike hostist ülesvoolu ja siinne resolveri konfiguratsioon ei ole veel üht muudatust väärt.

Milline käsk tegelikult teie resolverilt küsis

Kaks ainult lugemiseks mõeldud käsku vastavad seotud küsimustele, ja nende võrdlemine lokaliseerib probleemi kiiremini kui konfiguratsiooni lugemine. Kasutage tõelist sisemist nime ja hoidke väljund privaatsena, sest sisemised kirjed jäävad sisemisteks. Käivitage mõlemad samas sessioonis, milles ebaõnnestuv programm jookseb:

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

Esimene küsib konfigureeritud moodulite kaudu, mida tüüpiline programm kogeb. Teine küsib otse systemd-resolved-ilt ja teatab lingi, protokolli ja serveri, mis vastas. Ettevõtte serveri küsimine aadressi järgi tõestab vaid seda, et serveril on kirje olemas, sest see ei ütle midagi selle kohta, kas rakendus üldse küsis. Lugege linki, mis VPN-i kannab, ja domeene, mida see väidab, seejärel võrrelge seda loendit ebaõnnestuva nime sufiksiga.

Miks .local teie unicast-tsoonist mööda läheb

systemd-resolved-i viide märgib, et mitme sildiga nimed, mis lõpevad .local-ga, lähevad mDNS-i lubatud korral tavaliselt multicast-DNS-ile, mitte tavalisele unicast-DNS-ile. RFC 6762 jätab selle nimeruumi link-local multicastile, nii et ettevõtte tsoon võib hoida õiget kirjet, mille kohta selle sufiksi puhul kunagi ei küsita. Tunnel võib resolveri suurepäraselt marsruutida ja ikkagi võidujooksu kaotada. Vahemälust õnnestuv ping ei ütle midagi otsingu kohta, mis just toimus.

On dokumenteeritud erand, ja see lahendab enamiku neist juhtudest: kui link deklareerib selle sufiksi otsingudomeeniks või marsruutimisdomeeniks, hoiab deemon seda unicast-teel ja jätab multicast-erijuhu vahele. See on lingipõhine poliitika, mitte globaalne eelistus. Kaks sama VPN-serveriga masinat võivad käituda erinevalt, kui üks võrguprofiil deklareerib domeeni ja teine mitte, seega lugege aktiivset profiili, mitte seda, mida mäletate redigeerituna.

Kitsas erand võidab globaalse ümberkorralduse

Olemasoleva tsooni puhul, mida te ei saa ümber nimetada, laske resolveri ja VPN-i omanikel deklareerida domeen ühendusel, mis seda kannab. Marsruutimisdomeeni kirje selle ühe sufiksi ja kavandatud serveriaadressi jaoks on väike muudatus nimetatud omanikuga, ja see elab lingi juures, mitte käsitsi redigeeritud failis.

See elab üle ka katkestuse, sest lingipoliitikat rakendatakse uuesti, kui link naaseb. Ühise nsswitch.conf redigeerimine on ahvatlev ja kallim alternatiiv, sest see muudab otsingukäitumist iga nime jaoks masinas, sealhulgas kohalikku avastamist. Multicast-deemoni keelamine ei ole samuti samaväärne: see eemaldab kohaliku käitumise, õpetamata ühelegi resolverile ettevõtte tsooni. Kui teenus on uus, mitte päritud, pange see subdomeeni alla, mida teie organisatsioon kontrollib, ja jätke võistlus täiesti vahele. Valige kitsas erand, kui nimi on püsivaras fikseeritud või etiketile trükitud, ja valige uus subdomeen, kui kontrollite veel klienti.

Mida pärast muudatust tõestada

Tõestage parandust rakenduse enda otsinguga, mitte tööriistaga, mille testmiseks paigaldasite, ja tühjendage iga vahemälu, mis võiks selle eest vastata. Seejärel kinnitage resolveri tee ja vastuse andnud link. Lõpuks kontrollige, et kohalik avastamine käitub nagu enne muudatust, sest printer, mis lakkab ilmumast, on see osa, mida inimesed kõige hiljem märkavad. Need kolm käsku kontrollivad nime, teed ja TLS-identiteeti selles järjekorras:

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

Õige aadress vale sertifikaadiga nurjab range kliendi ikka, seega kontrollige nime, mida rakendus ootab, kui lahendamine töötab. Kinnitage, et teenus võtab vastu ühendusi VPN-i aadressilt, mitte ainult kontori vahemikust. Kirjutage domeeni ulatus, server ja omanik ühenduse dokumentatsiooni. Vastasel juhul haarab järgmine inimene, kes selle rikkega kokku puutub, sama globaalse muudatuse järele, mida te just vältisite.