VPN DNS veikia, bet .local vardai vis tiek nepavyksta: kas juos išsprendžia?

Du kompiuteriai tame pačiame VPN, tas pats pagrindinio kompiuterio vardas, ir tik vienas jų jį išsprendžia: skirtumas dažniausiai ne tunelyje, o tame, kuris sprendiklis atsakė. Linux darbalaukyje tas vardas gali eiti per vardų tarnybos perjungiklį, per systemd-resolved stubą arba per sprendiklį, kurį programa atsinešė, ir kiekvienas jų taiko savo taisyklę tam pačiam priesagui. Būtent prie priesagos taisyklės išsiskiria, nes .local nėra neutrali žymė. Išsiaiškinkite, kokiu keliu iš tikrųjų eina nepavykstanti programa, prieš keisdami tvarką, kuria kažkas paleidžiama.

Du sprendikliai, du skirtingi atsakymai

Tradicinė glibc paieška eina per nsswitch.conf hosts: eilutę ir iš eilės klausia kiekvieno modulio, kol vienas atsako. Klientas, kuris per stub klausytoją kalba su systemd-resolved, vietoj to klausia vieno proceso, ir tas procesas taiko politiką kiekvienai jungčiai bei savo specialius atvejus. Programa, kuri atsineša savo sprendiklį arba susieja biblioteką, kuri tai daro, gali apeiti abu. Taigi vienas pagrindinio kompiuterio vardas gali turėti tris savininkus viename kompiuteryje, ir tik vienas jų žino, ko siekė VPN.

Nustatykite savininką prieš ką nors keisdami, nes pataisa kiekvienam iš trijų skirtinga. Naršyklė ir komandinės eilutės įrankis tame pačiame darbalaukyje gali teisėtai nesutarti, ir tas nesutarimas yra užuomina, o ne klaida. Jei naršyklė išsprendžia vardą, o įrankis ne, jūs derinate sprendiklio kelią, o ne VPN maršrutą. Patikrinkite maršrutą atskirai, kad maršrutizavimo gedimas nebūtų supainiotas su vardų tarnybos gedimu. Kai abu sutaria, gedimas yra aukščiau pagrindinio kompiuterio, ir čia esanti sprendiklio konfigūracija neverta dar vieno pakeitimo.

Kuri komanda iš tikrųjų paklausė jūsų sprendiklio

Dvi tik skaitymo komandos atsako į susijusius klausimus, ir jų palyginimas lokalizuoja problemą greičiau nei konfigūracijos skaitymas. Naudokite tikrą vidinį vardą ir laikykite išvestį privačia, nes vidiniai įrašai lieka vidiniai. Paleiskite abi toje pačioje sesijoje, kurioje veikia nepavykstanti programa:

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

Pirmoji klausia per sukonfigūruotus modulius, ką patiria tipinė programa. Antroji klausia tiesiogiai systemd-resolved ir praneša apie jungtį, protokolą ir serverį, kuris atsakė. Serverio užklausa pagal adresą įrodo tik tai, kad serveris turi įrašą, nes ji nieko nesako apie tai, ar programa jo kada nors klausė. Perskaitykite jungtį, kuri neša VPN, ir domenus, kuriuos ji teigia, tada palyginkite tą sąrašą su nepavykstančio vardo priesaga.

Kodėl .local praleidžia jūsų unicast zoną

systemd-resolved nuoroda teigia, kad kelių žymių vardai, besibaigiantys .local, kai mDNS įjungtas, paprastai patenka į multicast DNS, o ne į įprastą unicast DNS. RFC 6762 atskiria tą vardų erdvę link-local multicast, todėl įmonės zona gali turėti teisingą įrašą, kurio šiai priesagai niekada neklausiama. Tunelis gali nepriekaištingai maršrutizuoti sprendiklį ir vis tiek pralaimėti lenktynes. Sėkmingas ping iš podėlio nieko nesako apie ką tik įvykusią paiešką.

Yra dokumentuota išimtis, ir ji išsprendžia daugumą šių atvejų: kai jungtis paskelbia tą priesagą kaip paieškos domeną arba maršrutizavimo domeną, demonas laiko ją unicast kelyje ir praleidžia specialų multicast atvejį. Tai kiekvienos jungties politika, o ne pasaulinė pirmenybė. Du kompiuteriai su tuo pačiu VPN serveriu gali elgtis skirtingai, kai vienas tinklo profilis paskelbia domeną, o kitas ne, todėl skaitykite aktyvų profilį, o ne tą, kurį prisimenate redagavę.

Siaura išimtis nugali pasaulinį pertvarkymą

Esamai zonai, kurios negalite pervadinti, paprašykite sprendiklio ir VPN savininkų paskelbti domeną jungtyje, kuri ją neša. Maršrutizavimo domeno įrašas tai vienai priesagai ir numatytas serverio adresas yra mažas pakeitimas su įvardytu savininku, ir jis gyvena su jungtimi, o ne rankiniu būdu redaguotame faile.

Jis išgyvena ir atsijungimą, nes jungties politika vėl taikoma, kai jungtis grįžta. Bendro nsswitch.conf redagavimas yra viliojanti ir brangesnė alternatyva, nes ji keičia paieškos elgseną kiekvienam kompiuterio vardui, įskaitant vietinį aptikimą. Multicast demono išjungimas taip pat nėra lygiavertis: jis pašalina vietinę elgseną nemokydamas nė vieno sprendiklio įmonės zonos. Jei paslauga nauja, o ne paveldėta, įdėkite ją į subdomeną, kurį kontroliuoja jūsų organizacija, ir visiškai praleiskite konkurenciją. Rinkitės siaurą išimtį, kai vardas užfiksuotas programinėje įrangoje arba atspausdintas etiketėje, ir rinkitės naują subdomeną, kai dar kontroliuojate klientą.

Ką įrodyti po pakeitimo

Įrodykite pataisą pačios programos paieška, o ne įrankiu, kurį įdiegėte testavimui, ir išvalykite bet kokį podėlį, kuris galėtų atsakyti už ją. Tada patvirtinkite sprendiklio kelią ir jungtį, kuri pateikė atsakymą. Galiausiai patikrinkite, ar vietinis aptikimas elgiasi kaip prieš pakeitimą, nes spausdintuvas, kuris nustoja rodytis, yra ta dalis, kurią žmonės pastebi paskiausiai. Šios trys komandos tikrina vardą, kelią ir TLS tapatybę tokia tvarka:

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

Tinkamas adresas su netinkamu sertifikatu vis tiek sužlugdo griežtą klientą, todėl patikrinkite vardą, kurio tikisi programa, kai sprendimas pradės veikti. Patvirtinkite, kad paslauga priima jungtis iš VPN adreso, o ne tik iš biuro diapazono. Įrašykite domeno apimtį, serverį ir savininką į jungties dokumentaciją. Priešingu atveju kitas žmogus, susidūręs su šiuo gedimu, griebsis to paties pasaulinio pakeitimo, kurio ką tik išvengėte.