Zakaj se interna imena gostiteljev razrešijo z dig, a spodletijo pri curl v VPN

Vaš prenosnik je v VPN, dig service.internal.example odgovori z naslovom 10.x, curl pa se še vedno konča z Could not resolve host. Tunel ni težava: prenesel je poizvedbo dig brez pritožb. Razlika je v tem, kdo postavi vprašanje. dig pošlje eno poizvedbo enemu strežniku, ki ga navedete, medtem ko curl gre skozi iskalno verigo operacijskega sistema, in ta veriga ima svoja pravila o tem, kateri strežnik je vprašan.

Dve iskanji za isto ime

dig je svoj stub resolver. Prebere /etc/resolv.conf, izbere imenski strežnik, pošlje eno poizvedbo A ali AAAA in izpiše odgovor. nsswitch povsem preskoči in ne ve nič o stanju na povezavi, ki ga systemd-resolved ali NetworkManager hranita zunaj te datoteke, zato je lahko odgovor dig pravilen in vam še vedno ne pove ničesar o tem, kaj bo videla vaša aplikacija.

Aplikacije kličejo getaddrinfo, in getaddrinfo prehodi daljšo verigo: vrstni red modulov nsswitch, nato modul, ki obravnava ime, in nazadnje resolver, zgrajen iz trenutne konfiguracije povezave. Na sistemu systemd gre poizvedba na 127.0.0.53 in systemd-resolved izbere nadrejeni strežnik za posamezno povezavo glede na usmerjevalno domeno, pripeto na vmesnik tun.

Dva ukaza ločita ti plasti brez ugibanja:

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

getent uporablja isto pot kot curl, zato napaka getent ob delujočem digu loci napako v iskalni politiki in ne v usmerjanju paketov. resolvectl query izpiše tudi vmesnik in nadrejeni strežnik, ki je dal odgovor, kar pokaže, ali je odločitev dobila povezava tunela ali fizična povezava.

Preberite resolver, ki ga aplikacija dejansko uporablja

/etc/resolv.conf se ustvari na večini namizij, in odjemalec VPN ima tri načine interakcije z njim: doda imenski strežnik na začetek, prepiše datoteko ali preda svoje strežnike NetworkManageru in pusti demonu, da jo prepiše. Samo tretji vzorec ohrani DNS na povezavo, ker strežniki ostanejo pripeti na vmesnik, namesto da bi bili sploščeni v en globalni seznam.

V sistemih NetworkManager je izid odvisen od zaledja v /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Z dns=default se odjemalčevi strežniki zlijejo v resolv.conf v vrstnem redu, ki zmaga, in zasebna poizvedba je lahko še vedno poslana javnemu resolverju. Z zaledjem, ki razume povezave, systemd-resolved ali dnsmasq, ostanejo strežniki tunela omejeni na tunel in tja gredo samo imena, ki ustrezajo njegovi usmerjevalni domeni. Ta omejitev je tisto, kar split DNS pomeni v praksi, in to je del, ki najpogosteje manjka, ko odjemalec trdi, da ga podpira.

Preberite stanje, preden kar koli spremenite:

resolvectl status
resolvectl dns tun0

Želite videti vmesnik tun naveden s strežnikom DNS in usmerjevalno domeno za zasebno pripono, prikazano kot ~internal.example. Noben strežnik na povezavi pomeni, da odjemalec ni poslal ničesar. Strežnik brez domene pomeni, da gredo poizvedbe vse tja ali nobena, odvisno od odjemalca, in nobeno od tega ni split DNS.

Kjer nsswitch iskanje konča prezgodaj

Običajna namizna vrstica je videti takole:

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

mdns4_minimal obravnava multicast DNS in zahteva vsako ime, ki se konča z .local. Storitev Kubernetes, kot je api.infra.svc.cluster.local, se prav tako konča z .local. Ko modul mDNS sporoči NOTFOUND, dejanje [NOTFOUND=return] konča celotno iskanje, namesto da bi nadaljevalo do modula dns, zato ime nikoli ni poslano resolverju VPN. dig zaobide datoteko v celoti, in prav zato se orodji ne strinjata.

To je najostrejše nasprotje v tej težavi in se zvede na eno besedo v konfiguracijski datoteki, ki je starejša od vašega VPN. Če dejanje spremenite v [NOTFOUND=continue], mDNS ostane za tiskalnike in lokalne naprave, medtem ko lahko DNS vidi ime. Zamenjava vrstice z hosts: files dns prav tako deluje in je bolj groba: opusti razreševanje .local za tiskalnik, ki ga dejansko uporabljate.

Imena, ki živijo v natanko enem omrežju

Zasebne cone so avtoritativne na natanko enem mestu. Ime AWS, kot je ip-10-0-4-31.eu-west-1.compute.internal, se odgovori prek resolverja VPC tiste regije in le dokler je vaša končna točka VPN v isti regiji kot vir. Povežite se s končno točko v Frankfurtu, poizvedite po imenu compute.internal z Irske, in nobena lokalna nastavitev ne bo pomagala: cona, ki hrani zapis, od tam ni dosegljiva.

Iskalne domene ustvarijo zrcalno sliko. Golo service se dopolni s pripono, ki jo resolver šteje za veljavno, in s povezavo VPN lahko lokalna domena premaga korporativno. Poizvedite s končno piko, da odstranite ugibanje, getent ahosts service.internal.example., in če to deluje, medtem ko kratko ime spodleti, je popravek iskalna domena na tunelu, ne naslov strežnika.

Upravljani odjemalci dodajo tretjo plast nad sistemskim resolverjem. Profil VPN za Windows lahko nosi lastno politiko razreševanja imen, pravila za posamezne aplikacije in tabelo NRPT, ki velja tudi, ko je tunel izklopljen. Aplikacije z lastnim predpomnilnikom DNS, pogoste v okoljih .NET in Java, obdržijo zastarelo napako dolgo po tem, ko je veriga popravljena. Odjemalci Apple konfigurirajo split DNS prek ujemajočih se domen v nastavitvah DNS namesto prek resolv.conf, Chromium ali Firefox v načinu varnega DNS pa lahko obideta sistemski resolver za javna imena. Microsoftov referenčni dokument o razreševanju imen VPN opisuje okno sistema Windows te plasti politike.

Odločite, katero plast popraviti

Delajte od simptoma do plasti, namesto da poskušate popravke po vrsti:

Dve vrstici nosita večino teže. Časovna omejitev je težava dosegljivosti: zasebni resolver ne odgovarja skozi tunel, zato preverite pot do njegovega naslova in ali je strežnik DNS na povezavi tisti, ki ga mislite. NXDOMAIN je težava avtoritete: nekaj je odgovorilo in ne pozna imena, kar kaže na cono, regijo ali resolver, ki ne bi smel nikoli prejeti poizvedbe.

Zadnja vrstica je tista, ki jo ljudje spregledajo, ker sta obe polovici videti kot uspeh. Kratko ime, ki se razreši drugače kot FQDN, je neujemanje pripone, in ponovna povezava tunela ne bo spremenila, katero pripono pošlje odjemalec.

Zajemite stanje, preden uredite konfiguracijsko datoteko, da boste lahko povedali, ali je urejanje kaj spremenilo:

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

Zaženite preverjanja v tem vrstnem redu in ustavite pri prvem, ki spodleti. getent in resolvectl query se morata ujemati; če getent spodleti, medtem ko dig odgovarja, ostanite v iskalni verigi in se ne dotikajte usmerjanja. resolvectl status mora pokazati strežnik DNS in usmerjevalno domeno na vmesniku tun. nsswitch se ne sme prezgodaj vrniti z NOTFOUND za pripono, ki jo preizkušate. Ime mora biti avtoritativno v omrežju, na katerega je pripeta vaša končna točka, preizkušeno s končno piko. Aplikacija ne sme hraniti lastnega predpomnilnika ali preglasitve varnega DNS.

Popravite samo prvo plast, ki spodleti, nato znova zaženite iste ukaze. Dve spremembi hkrati vam onemogočita reči, katera je štela, in naslednja okvara začne preiskavo od nič.