Kial internaj gastigantnomoj solviĝas per dig sed malsukcesas per curl en VPN

Via tekkomputilo estas en la VPN, dig service.internal.example respondas per 10.x-adreso, kaj curl ankoraŭ eliras per Could not resolve host. La tunelo ne estas la problemo: ĝi transportis la dig-demandon sen plendi. Kio diferencas estas, kiu faras la demandon. dig sendas unu demandon al unu servilo, kiun vi nomas, dum curl iras tra la serĉĉeno de la operaciumo, kaj tiu ĉeno havas proprajn regulojn pri tio, kiun servilon oni demandas.

Du serĉoj por la sama nomo

dig estas propra stub-resolver. Ĝi legas /etc/resolv.conf, elektas nomservilon, sendas unu solan A- aŭ AAAA-demandon kaj presas la respondon. Ĝi tute preterlasas nsswitch kaj scias nenion pri la laŭligila stato, kiun systemd-resolved aŭ NetworkManager tenas ekster tiu dosiero, kaj tial dig-respondo povas esti ĝusta kaj tamen diri al vi nenion pri tio, kion via aplikaĵo vidos.

Aplikaĵoj alvokas getaddrinfo, kaj getaddrinfo trapasas pli longan ĉenon: la modulordo de nsswitch, poste la modulo, kiu traktas la nomon, kaj fine la resolver konstruita el la aktuala ligila agordo. Sur systemd-maŝino la demando iras al 127.0.0.53 kaj systemd-resolved elektas supran servilon po ligilo surbaze de la enkursiga domajno ligita al la tun-interfaco.

Du komandoj apartigas tiujn tavolojn sen diveni:

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

getent uzas la saman vojon kiel curl, do getent-fiasko apud funkcianta dig lokigas la difekton en la serĉpolitiko, ne en la paketa enkursigado. resolvectl query ankaŭ presas la interfacon kaj la supran servilon, kiu donis la respondon, kio montras, ĉu la tunela ligilo aŭ la fizika ligilo gajnis la decidon.

Legu la resolver, kiun la aplikaĵo efektive uzas

/etc/resolv.conf estas generata sur plej multaj labortabloj, kaj VPN-kliento havas tri manierojn interagi kun ĝi: antaŭmeti nomservilon, anstataŭigi la dosieron aŭ transdoni siajn servilojn al NetworkManager kaj lasi la demonon reskribi ĝin. Nur la tria ŝablono konservas laŭligilan DNS, ĉar la serviloj restas ligitaj al interfaco anstataŭ esti platigitaj en unu tutmondan liston.

Sur NetworkManager-sistemoj la rezulto dependas de la backend en /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Kun dns=default la serviloj de la kliento kunfandiĝas en resolv.conf laŭ la venkanta ordo, kaj privata serĉo ankoraŭ povas esti sendita al la publika resolver. Kun backend, kiu komprenas ligilojn, systemd-resolved aŭ dnsmasq, la serviloj de la tunelo restas limigitaj al la tunelo kaj nur nomoj kongruantaj kun ĝia enkursiga domajno iras tien. Tiu limigo estas tio, kion split DNS signifas en praktiko, kaj ĝi estas la peco plej ofte mankanta, kiam kliento asertas subteni ĝin.

Legu la staton antaŭ ol ŝanĝi ion:

resolvectl status
resolvectl dns tun0

Vi volas vidi la tun-interfacon listigita kun DNS-servilo kaj enkursiga domajno por la privata sufikso, montrita kiel ~internal.example. Neniom da servilo sur la ligilo signifas, ke la kliento sendis nenion. Servilo sen domajno signifas, ke serĉoj ĉiuj iras tien aŭ neniuj, laŭ la kliento, kaj nek unu nek la alia estas split DNS.

Kie nsswitch finas la serĉon tro frue

Norma labortabla linio aspektas tiel:

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

mdns4_minimal traktas multicast-DNS kaj postulas ĉiun nomon finiĝantan per .local. Kubernetes-servo kiel api.infra.svc.cluster.local ankaŭ finiĝas per .local. Kiam la mDNS-modulo raportas NOTFOUND, la ago [NOTFOUND=return] finas la tutan serĉon anstataŭ daŭrigi al la dns-modulo, do la nomo neniam estas sendita al la VPN-resolver. dig preteriras la dosieron tute, kaj ĝuste tial la du iloj malkongruas.

Tio estas la plej akra kontrasto en ĉi tiu problemo, kaj ĝi reduktiĝas al unu vorto en agordodosiero pli malnova ol via VPN. Ŝanĝi la agon al [NOTFOUND=continue] konservas mDNS por printiloj kaj lokaj aparatoj dum DNS povas vidi la nomon. Anstataŭigi la linion per hosts: files dns ankaŭ funkcias kaj estas pli kruda: ĝi forigas la .local-solvon por la printilo, kiun vi efektive uzas.

Nomoj, kiuj vivas en ekzakte unu reto

Privataj zonoj estas aŭtoritataj en ekzakte unu loko. AWS-nomo kiel ip-10-0-4-31.eu-west-1.compute.internal estas respondata per la VPC-resolver de tiu regiono, kaj nur dum via VPN-finpunkto estas en la sama regiono kiel la rimedo. Konektiĝu al finpunkto en Frankfurto, demandu compute.internal-nomon el Irlando, kaj neniu loka agordo helpos: la zono tenanta la rikordon ne estas atingebla de tie.

Serĉdomajnoj produktas la spegulan bildon. Nuda service estas kompletigata per la sufikso, kiun la resolver opinias aplikebla, kaj kun VPN-ligilo la loka domajno povas venki la firmaan. Demandu per fina punkto por forigi la divenadon, getent ahosts service.internal.example., kaj se tio funkcias dum la mallonga nomo malsukcesas, la korekto estas la serĉdomajno sur la tunelo, ne la servila adreso.

Administrataj klientoj aldonas trian tavolon super la sistema resolver. Windows-VPN-profilo povas porti propran nomresolvan politikon, regulojn po aplikaĵo kaj NRPT-tabelon, kiu aplikiĝas eĉ kiam la tunelo estas malŝaltita. Aplikaĵoj kun propra DNS-kaŝmemoro, oftaj en .NET- kaj Java-runtime, konservas malnoviĝintan fiaskon longe post kiam la ĉeno estas riparita. Apple-klientoj agordas split DNS per kongruaj domajnoj en la DNS-agordoj anstataŭ per resolv.conf, kaj Chromium aŭ Firefox en sekura-DNS-reĝimo povas preterpasi la sisteman resolver por publikaj nomoj. La referenco de Microsoft pri VPN-nomresolvo priskribas la Windows-flankon de tiu politika tavolo.

Decidu, kiun tavolon ripari

Laboru de la simptomo al la tavolo anstataŭ provi korektojn laŭorde:

Du vicoj portas la plej grandan pezon. Tempolimo estas atingebla problemo: la privata resolver ne respondas tra la tunelo, do kontrolu la itineron al ĝia adreso kaj ĉu la DNS-servilo sur la ligilo estas tiu, kiun vi pensas. NXDOMAIN estas aŭtoritata problemo: io respondis kaj ne konas la nomon, kio montras al la zono, la regiono aŭ resolver, kiu neniam devintus ricevi la demandon.

La lasta vico estas tiu, kiun homoj maltrafas, ĉar ambaŭ duonoj aspektas kiel sukceso. Mallonga nomo solviĝanta malsame ol la FQDN estas sufiksa miskongruo, kaj rekonekti la tunelon ne ŝanĝos, kiun sufikson la kliento sendas.

Kaptu la staton antaŭ ol redakti agordodosieron, por ke vi povu diri, ĉu la redakto ion faris:

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

Rulu la kontrolojn en ĉi tiu ordo kaj haltu ĉe la unua, kiu malsukcesas. getent kaj resolvectl query devas kongrui; se getent malsukcesas dum dig respondas, restu en la serĉĉeno kaj lasu enkursigadon trankvila. resolvectl status devas montri DNS-servilon kaj enkursigan domajnon sur la tun-interfaco. nsswitch ne rajtas frue reveni je NOTFOUND por la sufikso, kiun vi testas. La nomo devas esti aŭtoritata en la reto, al kiu via finpunkto estas ligita, testite per fina punkto. La aplikaĵo ne rajtas teni propran kaŝmemoron aŭ sekura-DNS-anstataŭigon.

Riparu nur la unuan malsukcesantan tavolon, poste rerulu la samajn komandojn. Du ŝanĝoj samtempe lasas vin ne povi diri, kiu gravis, kaj la sekva paneo komencas la esploron de nulo.