Waarom jou /etc/hosts-inskrywing nie die VPN se DNS bereik nie

Jy het ’n naam by /etc/hosts gevoeg, die VPN gekoppel en verwag dat die rekord vir almal moet verskyn. Dit gebeur nie, en die verrassing kom gewoonlik saam met ’n tweede simptoom: die naam los op jou masjien en misluk by ’n kollega, wat soos ’n stukkende VPN-DNS-diens lyk en eintlik is die hosts-lêer besig om presies te doen waarvoor dit ontwerp is. ’n Hosts-lêer is plaaslike naamresolusie-konfigurasie, nie ’n sone-opdatering nie, en niks in ’n normale VPN-verbinding laai dit op nie.

Hosts is ’n plaaslike oorheersing, nie ’n sone-opdatering nie

Die lêer is ’n lys karterings wat naamdiensbiblioteke raadpleeg voordat, of in plaas van, hulle ’n DNS-bediener vra. ’n Reël soos 10.40.0.20 build.corp.example verander wat toepassings op daardie een masjien aflei. Dit skep nie ’n rekord nie, dit reis nie deur die tonnel nie, en die DNS-bediener waarna die tonnel wys, het geen idee dat dit bestaan nie.

Dis hoekom die mislukking asimmetries is. Jou kliënt kry ’n antwoord uit die lêer. ’n Ander kliënt vra die VPN-DNS-bediener, wat niks terugstuur nie, en die toepassing rapporteer dat die naam nie bestaan nie. Albei masjiene gedra hulle korrek; net een van hulle het ’n oorheersing wat die ander nog nooit gesien het nie.

Twee opdragte, twee verskillende komponente

Die vinnigste manier om die argument te stop, is om die verskil sigbaar te maak in twee opdragte wat albei op die kliënt met die hosts-inskrywing uitgevoer word:

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

Die eerste vra die stelsel se eie opsoekpad, wat op ’n tipiese glibc-stelsel plaaslike lêers voor DNS lees. Die tweede stuur ’n DNS-navraag direk na die bediener by daardie adres en raadpleeg glad nie plaaslike lêers nie. Wanneer die eerste jou inskrywing teruggee en die tweede NXDOMAIN teruggee, het jy bewys dat die rekord nie in DNS bestaan nie en dat jou masjien uit ’n plaaslike oorheersing antwoord.

Die orde is konfigureerbaar, wat die moeite werd is om na te gaan voordat jy enigiets oor ’n bepaalde verspreiding aflei. Kyk na die hosts:-reël in /etc/nsswitch.conf; hosts: files dns raadpleeg lêers eerste. Moenie daardie voorbeeld oor ’n werkende konfigurasie kopieer net om die orde te verander nie, want werklike stelsels lys dikwels bykomende bronne en voorwaardelike diensinskrywings wat die voorbeeld nie bevat nie.

systemd-resolved vertroebel die toets

Op ’n stelsel wat systemd-resolved gebruik, dien die plaaslike stopper ook name uit die hosts-databasis. Om 127.0.0.53 te bevraag is dus nie ’n onafhanklike toets van die afgeleë bediener nie, al lyk dit soos ’n DNS-navraag en gedra dit hom so. Jy kan bevestig wat die resolveerder weet en watter bedieners dit sou vra met:

resolvectl query build.corp.example
resolvectl status

Die status-uitset noem die DNS-bedieners per skakel, en dis hoe jy uitvind of die VPN-skakel hoegenaamd ’n resolveerder ontvang het. Daardie vraag is apart van die hosts-inskrywing en is die een wat die moeite werd is om te vra wanneer ’n private naam vir elke gebruiker eerder as vir een misluk.

Toepassings kan weer ’n ander laag byvoeg. ’n Blaaier met sy eie DNS-over-HTTPS-instelling, ’n houer met sy eie resolveerder-konfigurasie, of ’n looptyd wat opsoeke vir die lewe van die proses kas, kan elkeen anders as die stelsel antwoord. Toets die toepassing waaroor jy omgee eerder as om aan te neem dat een opdrag elke program op die masjien beskryf.

Wat eintlik ’n naam oor die VPN deel

As ’n private naam vir almal moet werk, het dit ’n eienaar nodig wat almal se resolveerder kan bereik. Die skoon antwoord is om die rekord in ’n bestuurde sone te publiseer en daardie sone deur die beoogde VPN-DNS-pad oplosbaar te maak. Die rekord het dan een bron van waarheid, ’n ouditspoor en ’n lewensiklus, en niemand hoef te onthou watter skootrekenaar ’n plaaslike oorheersing dra nie.

Om hosts-lêers te versprei is ’n wettige alternatief, en dit is eindpuntbestuur eerder as naamdiens. As jy dit kies, moet die lêer ontplooi, weergee en verwyder word deur wat die vloot bestuur, en dit moet so in die ontwerp beskryf word. “Die VPN hanteer dit” is nie ’n beskrywing van daardie proses nie.

Dinamiese DNS-registrasie is ’n derde meganisme, met sy eie toestemmings, opdateringsverifikasie en rekordlewensduur. Dit volg nie uit ’n hosts-inskrywing nie, en dit volg ook nie uit ’n kliënt wat bloot koppel nie, tensy die bediener en die kliënt albei gekonfigureer is om dit te doen. ’n Rekord wat vanself verskyn, is ’n teken dat iemand veilige opdaterings geaktiveer het en ’n kliënt wat homself registreer, en daardie konfigurasie hoort in die ontwerprekord eerder as in ’n foutspooringsdraad. As niemand kan sê wie daardie instelling besit nie, behandel die outomatiese rekord as onverifieer en hou die bestuurde sone as die bron van waarheid.

’n Opgeloste naam is nie ’n roete nie

Naamresolusie en bereikbaarheid is apart, en ’n verouderde plaaslike kartering is die klassieke manier om hulle te verwar. ’n Hosts-inskrywing wat na ’n adres wys wat geskuif het, sal aanhou om die verouderde gasheer te kies lank nadat DNS reggestel is, en die simptoom lyk soos ’n roetefout op ’n naam wat goed oplos.

Dus, wanneer die verslag sê “die naam los op maar die diens is onbereikbaar”, vergelyk die stelselopsoek met ’n eksplisiete navraag aan die VPN-DNS-bediener, en kyk dan of die adres wat jy gekry het, ooreenstem met die een wat die diens werklik gebruik. Die systemd-resolved-verwysing dokumenteer die plaaslike bronne wat dit raadpleeg, en dit is die kaart wat jy vir daardie vergelyking nodig het.

Maak dan die oorheersing reg via sy eienaar. Om ’n reël uit jou eie hosts-lêer te verwyder, doen niks vir die twaalf skootrekenaars wat dieselfde reël uit ’n ontplooiingskrip ontvang het nie, en dit is die weergawe van hierdie probleem wat mense werklik het.