VPN-DNS werk, maar .local-name faal steeds: wie los hulle op?

Twee masjiene op dieselfde VPN, dieselfde gasheernaam, en net een van hulle los dit op: die verskil is gewoonlik nie die tonnel nie, maar watter oplosser geantwoord het. Op ’n Linux-lessenaar kan daardie naam deur die naamdiensskakelaar beweeg, deur systemd-resolved se stub, of deur ’n oplosser wat die toepassing saamgebring het, en elkeen van dié pas sy eie reël op dieselfde agtervoegsel toe. Die agtervoegsel is waar die reëls uiteenloop, want .local is nie ’n neutrale etiket nie. Werk uit watter pad die falende program werklik volg voordat jy die volgorde verander waarin enigiets loop.

Twee oplossers, twee verskillende antwoorde

’n Tradisionele glibc-soektog loop deur die hosts:-reël van nsswitch.conf en vra elke module om die beurt totdat een antwoord. ’n Kliënt wat deur die stub-luisteraar met systemd-resolved praat, vra eerder ’n enkele proses, en daardie proses pas per-skakel-beleid plus sy eie spesiale gevalle toe. ’n Toepassing wat sy eie oplosser saambring, of ’n biblioteek koppel wat dit doen, kan albei omseil. Een gasheernaam kan dus drie eienaars op een masjien hê, en net een van hulle weet wat die VPN bedoel het.

Identifiseer die eienaar voordat jy iets verander, want die regstelling verskil vir elkeen van die drie. ’n Blaaier en ’n opdragreëlnut op dieselfde lessenaar kan wettiglik van mening verskil, en daardie verskil is die leidraad eerder as die fout. As die blaaier die naam oplos en die nut nie, ontfout jy ’n oplosserpad en nie ’n VPN-roete nie. Bevestig die roete afsonderlik, sodat ’n roeteringsfout nie vir ’n naamdiensfout aangesien word nie. Wanneer albei saamstem, is die fout stroomop van die gasheer en is die oplosserkonfigurasie hier nie nog ’n wysiging werd nie.

Watter opdrag het werklik jou oplosser gevra

Twee lees-alleen-opdragte beantwoord verwante vrae, en om hulle te vergelyk lokaliseer die probleem vinniger as om konfigurasie te lees. Gebruik ’n werklike interne naam en hou die uitvoer privaat, want interne rekords bly steeds intern. Voer albei uit uit dieselfde sessie waarin die falende program loop:

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

Die eerste vra deur die gekonfigureerde modules, wat ’n tipiese program ervaar. Die tweede vra systemd-resolved direk en rapporteer die skakel, die protokol en die bediener wat geantwoord het. Om die korporatiewe bediener per adres te bevraag, bewys net dat die bediener die rekord hou, want dit sê niks oor of die toepassing ooit gevra het nie. Lees die skakel wat die VPN dra en die domeine wat dit opeis, en vergelyk dan daardie lys met die agtervoegsel in die falende naam.

Waarom .local jou unicast-sone oorslaan

systemd-resolved se verwysing sê dat name met meer as een etiket wat op .local eindig, gewoonlik na multicast-DNS gaan wanneer mDNS geaktiveer is, eerder as na gewone unicast-DNS. RFC 6762 hou daardie naamruimte apart vir skakel-plaaslike multicast, so ’n korporatiewe sone kan ’n korrekte rekord hou wat nooit vir daardie agtervoegsel geraadpleeg word nie. Die tonnel kan die oplosser volmaak roeteer en steeds die wedloop verloor. ’n Ping wat uit ’n kas slaag, sê niks oor die soektog wat pas plaasgevind het nie.

Daar is ’n gedokumenteerde uitsondering, en dit besleg die meeste van hierdie gevalle: wanneer ’n skakel daardie agtervoegsel as ’n soekdomein of ’n roeteringsdomein verklaar, hou die daemon dit op die unicast-pad en slaan die multicast-spesiale geval oor. Dit is per-skakel-beleid eerder as ’n globale voorkeur. Twee masjiene met dieselfde VPN-bediener kan anders optree wanneer een netwerkprofiel die domein verklaar en die ander nie, so lees die profiel wat aktief is in plaas van die een wat jy onthou jy gewysig het.

Die smal uitsondering klop ’n globale herrangskikking

Vir ’n bestaande sone wat jy nie kan hernoem nie, laat die oplosser- en VPN-eienaars die domein verklaar op die verbinding wat dit dra. ’n Roeteringsdomein-inskrywing vir daardie een agtervoegsel plus die beoogde bedieneradres is ’n klein verandering met ’n genoemde eienaar, en dit woon by die skakel eerder as in ’n handmatig geredigeerde lêer.

Dit oorleef ook ’n ontkoppeling, want die skakelbeleid word weer toegepas wanneer die skakel terugkeer. Om die gedeelde nsswitch.conf te wysig, is die verleidelike alternatief en die duurder een, want dit verander soekgedrag vir elke naam op die masjien, plaaslike ontdekking ingesluit. Om die multicast-daemon te deaktiveer is ook nie gelykwaardig nie: dit verwyder die plaaslike gedrag sonder om enige oplosser oor die korporatiewe sone te leer. As die diens nuut is eerder as geërf, plaas dit onder ’n subdomein wat jou organisasie beheer en slaan die kompetisie heeltemal oor. Kies die smal uitsondering wanneer die naam in firmware vasgelê of op ’n etiket gedruk is, en kies ’n nuwe subdomein wanneer jy steeds die kliënt beheer.

Wat om ná die verandering te bewys

Bewys die regstelling met die toepassing se eie soektog eerder as met ’n nut wat jy vir toetsing geïnstalleer het, en maak enige kas leeg wat daarvoor kan antwoord. Bevestig dan die oplosserpad en die skakel wat die antwoord bedien het. Kyk laastens of plaaslike ontdekking steeds optree soos voor die verandering, want die drukker wat ophou verskyn, is die deel wat mense die laaste opmerk. Hierdie drie opdragte kontroleer die naam, die pad en die TLS-identiteit in daardie volgorde:

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

’n Korrekte adres met die verkeerde sertifikaat laat ’n streng kliënt steeds misluk, so kontroleer die naam wat die toepassing verwag sodra oplossing werk. Bevestig dat die diens verbindings vanaf die VPN-adres aanvaar en nie net vanaf die kantoorreeks nie. Skryf die domeinbereik, die bediener en die eienaar in die verbinding se dokumentasie. Anders gryp die volgende persoon wat hierdie fout teëkom na dieselfde globale wysiging wat jy pas vermy het.