Wêrom’t ynterne hostnammen wol resolvje yn dig, mar misse yn curl op in VPN

Dyn laptop is op ’e VPN, dig service.internal.example antwurdet mei in 10.x-adres, en curl einiget noch altiten mei Could not resolve host. De tunnel is it probleem net: hy ferfierde de dig-fraach sûnder klachten. Wat ferskilt, is wa’t de fraach stelt. dig stjoert ien fraach nei ien tsjinner dy’tsto oanwiist, wylst curl troch de opsochketen fan it bestjoeringssysteem giet, en dy keten hat eigen regels oer hokker tsjinner frege wurdt.

Twa opsochten foar deselde namme

dig is in eigen stub-resolver. It lêst /etc/resolv.conf, kiest in nametsjinner, stjoert ien inkele A- of AAAA-fraach en prints it antwurd. It slacht nsswitch folslein oer en wit neat fan ’e per-keppeling-tastân dy’t systemd-resolved of NetworkManager bûten dat bestân hâldt, en dêrom kin in dig-antwurd korrekt wêze en dochs neat sizze oer wat dyn applikaasje sjocht.

Applikaasjes roppe getaddrinfo oan, en getaddrinfo rint in langere keten del: de modulefolchoarder fan nsswitch, dan de module dy’t de namme behannelet, en dan de resolver dy’t út ’e aktuele keppelingskonfiguraasje boud is. Op in systemd-masine giet de fraach nei 127.0.0.53 en systemd-resolved kiest in upstream-tsjinner per keppeling op grûn fan it routingdomein dat oan it tun-ynterface honget.

Twa kommando’s skiede dy lagen sûnder te rieden:

getent ahosts service.internal.example
resolvectl query service.internal.example

getent brûkt itselde paad as curl, dus in getent-flater neist in wurkjende dig lokaliseart de fout yn it opsochbelied en net yn ’e pakketrouting. resolvectl query prints ek it ynterface en de upstream dy’t it antwurd joech, wat sjen lit oft de tunnellink of de fysike link de beslissing wûn hat.

Lês de resolver dy’t de applikaasje echt brûkt

/etc/resolv.conf wurdt op ’e measte desktops generearre, en in VPN-klant hat trije manieren om dermei om te gean: in nametsjinner foaroan sette, it bestân oerskriuwe, of syn tsjinners oan NetworkManager jaan en de daemon it wer skriuwe litte. Allinnich it tredde patroan behâldt DNS per keppeling, om’t de tsjinners oan in ynterface keppele bliuwe ynstee fan ta ien globale list flakmakke te wurden.

Op NetworkManager-systemen hinget de útkomst ôf fan ’e backend yn /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Mei dns=default wurde de tsjinners fan ’e klant yn resolv.conf gearfoege yn hokker folchoarder dan ek wint, en in privee-opsoch kin noch altiten nei de iepenbiere resolver stjoerd wurde. Mei in backend dy’t keppelings begrypt, systemd-resolved of dnsmasq, bliuwe de tsjinners fan ’e tunnel beheind ta de tunnel en geane allinnich nammen dy’t by syn routingdomein passe dêrhinne. Dy beheining is wat split DNS yn ’e praktyk betsjut, en dat is it stik dat it faakst ûntbrekt as in klant beweart it te stypjen.

Lês de tastân foardatsto eat feroarest:

resolvectl status
resolvectl dns tun0

Do wolst it tun-ynterface neamd sjen mei in DNS-tsjinner en in routingdomein foar it privee-suffiks, werjûn as ~internal.example. Gjin tsjinner op ’e keppeling betsjut dat de klant neat stjoerd hat. In tsjinner sûnder domein betsjut dat opsochten allegearre dêrhinne geane of hielendal net, ôfhinklik fan ’e klant, en gjin fan beide is split DNS.

Wêr’t nsswitch it opsochten betiid beëiniget

In standertrigel op in desktop sjocht der sa út:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

mdns4_minimal regelet multicast-DNS en makket oanspraak op elke namme dy’t op .local einiget. In Kubernetes-tsjinst lykas api.infra.svc.cluster.local einiget ek op .local. As de mDNS-module NOTFOUND rapportearret, beëiniget de aksje [NOTFOUND=return] it hiele opsochten ynstee fan troch te gean nei de dns-module, dus de namme wurdt nea nei de VPN-resolver stjoerd. dig giet it bestân folslein foarby, en dat is krekt wêrom’t de twa helpmiddels it net iens binne.

Dat is it skerpste kontrast yn dit probleem, en it komt del op ien wurd yn in konfiguraasjebestân dat âlder is as dyn VPN. De aksje feroarje yn [NOTFOUND=continue] behâldt mDNS foar printers en lokale apparaten wylst DNS de namme sjen kin. De rigel ferfange troch hosts: files dns wurket ek en is rûwer: it lit de .local-resolúsje falle foar de printer dy’tsto echt brûkst.

Nammen dy’t yn krekt ien netwurk libje

Privee-sônes binne op krekt ien plak gesachhawwend. In AWS-namme lykas ip-10-0-4-31.eu-west-1.compute.internal wurdt beantwurde fia de VPC-resolver fan dat gebiet, en allinnich salang’t dyn VPN-einpunt yn itselde gebiet sit as de boarne. Ferbyn mei in einpunt yn Frankfurt, sykje in compute.internal-namme út Ierlân op, en gjin inkelde lokale ynstelling helpt: de sône mei it record is dêrwei net berikber.

Sykdomeinen jouwe it spegelbyld. In keale service wurdt oanfolle mei it suffiks dat de resolver fan tapassing achtet, en mei in VPN-keppeling kin it lokale domein it bedriuwsdomein winne. Sykje mei in punt oan ’e ein om it rieden fuort te heljen, getent ahosts service.internal.example., en as dat wurket wylst de koarte namme mist, dan is it sykdomein op ’e tunnel de oplossing, net it tsjinneradres.

Behearders kliïnten foegje in tredde laach ta boppe de resolver fan it bestjoeringssysteem. In Windows-VPN-profyl kin syn eigen namme-resolúsjebelied, regels per applikaasje en in NRPT-tabel drage dy’t jildt sels as de tunnel del is. Applikaasjes mei in eigen DNS-cache, gewoan yn .NET- en Java-runtimes, hâlde in ferâldere flater lang fêst neidat de keten reparearre is. Apple-kliïnten konfigurearje split DNS fia match-domeinen yn ’e DNS-ynstellings ynstee fan fia resolv.conf, en Chromium of Firefox yn secure-DNS-modus kinne de systeemresolver foar iepenbiere nammen foarby gean. Microsoft syn naslachwurk oer VPN-namme-resolúsje beskriuwt de Windows-kant fan dy beliedslaach.

Beslis hokker laach te reparearjen

Wurk fan it symptoom nei de laach ynstee fan fixes yn folchoarder te probearjen:

Twa rigen drage it measte gewicht. In timeout is in berikberensprobleem: de privee-resolver antwurdet net troch de tunnel, dus kontrolearje de rûte nei syn adres en oft de DNS-tsjinner op ’e keppeling dejinge is dy’tsto tinkst. NXDOMAIN is in gesachsprobleem: eat hat antwurde en ken de namme net, wat op ’e sône, it gebiet of in resolver wiist dy’t de fraach nea krije moatten hie.

De lêste rigel is dejinge dy’t minsken misse om’t beide helten op súkses lykje. In koarte namme dy’t oars resolvet as de FQDN is in suffiks-mismatch, en de tunnel wer ferbinen sil net feroarje hokker suffiks de klant stjoert.

Fêstlizze de tastân foardatsto in konfiguraasjebestân bewurkest, sadatsto sjen kinst oft de bewurking eat dien hat:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Fier de kontrôles yn dizze folchoarder út en stop by de earste dy’t mist. getent en resolvectl query moatte oerienkomme; as getent mist wylst dig antwurdet, bliuw dan yn ’e opsochketen en lit routing gewurde. resolvectl status moat in DNS-tsjinner en in routingdomein op it tun-ynterface sjen litte. nsswitch mei by NOTFOUND net betiid weromkomme foar it suffiks datsto testest. De namme moat gesachhawwend wêze yn it netwurk dêr’t dyn einpunt oan keppele is, test mei in punt oan ’e ein. De applikaasje mei gjin eigen cache of in secure-DNS-oerhearsking hâlde.

Reparearje allinnich de earste laach dy’t mist en fier dan deselde kommando’s wer út. Twa feroarings tagelyk litte dy net sizze hokker ien ta saak die, en de folgjende steuring begjint it ûndersyk wer by nul.