Wêrom jo /etc/hosts-ynstjoer de DNS fan de VPN net berikt

Jo hawwe in namme tafoege oan /etc/hosts, de VPN ferbûn en ferwachten dat it record foar elkenien ferskine soe. Dat bart net, en de ferrassing komt meastentiids mei in twadde symptoom: de namme lost op jo masine op en mislearret by in kollega, wat lykst as in stikken VPN-DNS-tsjinst en eins is it hosts-bestân dwaande krekt te dwaan wêr’t it foar ûntwurpen is. In hosts-bestân is lokale konfiguraasje foar namme-oplossing, gjin sône-bywurking, en neat yn in normale VPN-ferbining uploadet it.

Hosts is in lokale oerskriuwing, gjin sône-bywurking

It bestân is in list fan mappings dy’t namme-tsjinstbibleteken rieplachtsje foardat, of ynstee fan, se in DNS-tsjinner freegje. In rigel lykas 10.40.0.20 build.corp.example feroaret wat applikaasjes op dat iene masine konkludearje. It makket gjin record, it reizget net troch de tunnel, en de DNS-tsjinner dêr’t de tunnel nei wiist hat gjin idee dat it bestiet.

Dêrom is de mislearring asymmetrysk. Jo klient krijt in antwurd út it bestân. In oare klient freget de VPN-DNS-tsjinner, dy’t neat weromjout, en de applikaasje rapportearret dat de namme net bestiet. Beide masines gedrage har korrekt; allinnich ien hat in oerskriuwing dy’t de oare nea sjoen hat.

Twa opdrachten, twa ferskate komponinten

De fluchste manier om de diskusje te stopjen is it ferskil sichtber te meitsjen yn twa opdrachten, beide útfierd op de klient mei de hosts-ynstjoer:

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

De earste freget it eigen opspoarpaad fan it systeem, dat op in typysk glibc-systeem lokale bestannen lêst foar DNS. De twadde stjoert in DNS-fraach direkt nei de tsjinner op dat adres en rieplachtet hielendal gjin lokale bestannen. As de earste jo ynstjoer weromjout en de twadde NXDOMAIN, hawwe jo bewiisd dat it record net yn DNS bestiet en dat jo masine fan in lokale oerskriuwing antwurdet.

De oarder is konfigurearber, en it is de muoite wurdich om dat te kontrolearjen foardat jo wat oer in bepaalde distribúsje konkludearje. Sjoch nei de rigel hosts: yn /etc/nsswitch.conf; hosts: files dns rieplachtet earst bestannen. Kopiearje dat foarbyld net oer in wurkjende konfiguraasje allinnich om de oarder te feroarjen, want echte systemen listje faak ekstra boarnen en betingstige tsjinstynstjoeren op dy’t it foarbyld net hat.

systemd-resolved fertroebelt de test

Op in systeem dat systemd-resolved brûkt, tsjinnet de lokale stub ek nammen út de hosts-databank. Dêrom is it freegjen fan 127.0.0.53 gjin ûnôfhinklike test fan ’e fiere tsjinner, ek al liket it as in DNS-fraach en gedraacht it him sa. Jo kinne befêstigje wat de resolver wit en hokker tsjinners it freegje soe mei:

resolvectl query build.corp.example
resolvectl status

De status-útfier neamt de DNS-tsjinners per keppeling, en sa komme jo derachter oft de VPN-keppeling hielendal in resolver krigen hat. Dy fraach stiet los fan ’e hosts-ynstjoer en is dejinge dy’t de muoite wurdich is as in privee namme foar elke brûker mislearret en net foar ien.

Applikaasjes kinne wer in oare laach tafoegje. In browser mei syn eigen DNS-over-HTTPS-ynstelling, in container mei syn eigen resolver-konfiguraasje, of in runtime dy’t opspoaringen foar de hiele libbensdoer fan it proses cachet, kinne elk oars as it systeem antwurdzje. Test de applikaasje dy’t jo oanbelanget ynstee fan oan te nimmen dat ien opdracht elk programma op ’e masine beskriuwt.

Wat eins in namme oer de VPN dielt

As in privee namme foar elkenien wurkje moat, hat it in eigner nedich dy’t de resolver fan elkenien berikke kin. It skjinne antwurd is it record yn in behearde sône publisearje en dy sône troch it bedoelde VPN-DNS-paad oplosber meitsje. Dan hat it record ien boarne fan wierheid, in auditspoar en in libbenssyklus, en nimmen hoecht te ûnthâlden hokker laptop in lokale oerskriuwing draacht.

It fersprieden fan hosts-bestannen is in legitime alternative, en it is einpuntbehear ynstee fan namme-tsjinst. As jo dat kieze, moat it bestân útrôle, ferzjeare en fuorthelle wurde troch wat de float beheart, en sa moat it yn it ûntwerp beskreaun wurde. “De VPN docht dat” is gjin beskriuwing fan dat proses.

Dynamyske DNS-registraasje is in tredde meganisme, mei syn eigen tastimmingen, bywurkingsautentikaasje en record-libbenstiid. It folget net út in hosts-ynstjoer, en it folget ek net út in klient dy’t gewoan ferbynt, útsein as de tsjinner en de klient beide konfigurearre binne om dat te dwaan. In record dat fan sels ferskynt is in teken dat immen feilige bywurkingen ynskeakele hat en in klient dy’t himsels registrearret, en dy konfiguraasje heart yn it ûntwerp-record en net yn in probleemoplossingsdraad. As nimmen neame kin wa’t dy ynstelling besit, behannelje it automatyske record as net ferifiearre en hâld de behearde sône as boarne fan wierheid.

In oploste namme is gjin rûte

Namme-oplossing en berikberens binne apart, en in ferâldere lokale mapping is de klassike manier om se te betizjen. In hosts-ynstjoer dy’t nei in adres wiist dat ferhuze is, sil de ferâldere host bliuwe kiezen lang neidat DNS korrizjearre is, en it symptoom liket op in rûtefout by in namme dy’t goed oplost.

Dus as it rapport is “de namme lost op mar de tsjinst is net berikber”, fergelykje it systeemopspoaren mei in eksplisite fraach oan de VPN-DNS-tsjinner, en kontrolearje dan it adres dat jo krigen hawwe tsjin dat de tsjinst eins brûkt. De systemd-resolved-referinsje dokumintearret de lokale boarnen dy’t it rieplachtet, en dat is de kaart dy’t jo foar dy fergeliking nedich hawwe.

Reparearje dan de oerskriuwing fia syn eigner. It fuortheljen fan in rigel út jo eigen hosts-bestân docht neat foar de tolve laptops dy’t deselde rigel fan in útrôlskript krigen hawwe, en dat is de ferzje fan dit probleem dy’t minsken eins hawwe.