Zergatik ebazten diren barneko ostalari-izenak dig-ekin baina huts egiten duten curl-ekin VPN batean

Zure ordenagailu eramangarria VPNean dago, dig service.internal.example 10.x helbide batekin erantzuten du, eta curl oraindik Could not resolve host-rekin irteten da. Tunela ez da arazoa: dig kontsulta arazorik gabe garraiatu zuen. Aldatzen dena da nork egiten duen galdera. dig-ek zuk izendatutako zerbitzari bakarrari kontsulta bakarra bidaltzen dio, eta curl berriz sistema eragilearen bilaketa-katetik igarotzen da, eta kate horrek bere arauak ditu zein zerbitzariri galdetzen zaion.

Bi bilaketa izen bererako

dig bere stub resolver propioa da. /etc/resolv.conf irakurtzen du, nameserver bat aukeratzen du, A edo AAAA kontsulta bakarra bidaltzen du eta erantzuna inprimatzen du. nsswitch guztiz saltatzen du eta ez daki ezer systemd-resolvedek edo NetworkManagerrek fitxategi horretatik kanpo gordetzen duten esteka bakoitzeko egoeraz, eta horregatik dig-en erantzun bat zuzena izan daiteke eta, hala ere, ez dizu ezer esaten zure aplikazioak ikusiko duenari buruz.

Aplikazioek getaddrinfo deitzen dute, eta getaddrinfo-k kate luzeagoa egiten du: nsswitch moduluen ordena, gero izena lantzen duen modulua eta azkenik uneko esteka-konfiguraziotik eraikitako resolverra. systemd makin batean kontsulta 127.0.0.53ra joaten da eta systemd-resolvedek esteka bakoitzeko upstream zerbitzari bat aukeratzen du tun interfazeari lotutako routing domeinuaren arabera.

Bi komandok geruza horiek bereizten dituzte asmatu gabe:

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

getent-ek curl-en bide bera erabiltzen du, beraz dig funtzionatzen duen bitartean getent-ek huts egiteak arazoa bilaketa-politikan kokatzen du, ez pakete-bideratzean. resolvectl query-k erantzuna eman zuen interfazea eta upstreama ere inprimatzen ditu, eta horrek erakusten du tunelaren esteka edo esteka fisikoa izan zen erabakia irabazi zuena.

Irakurri aplikazioak benetan erabiltzen duen resolverra

/etc/resolv.conf mahaigain gehienetan sortzen da, eta VPN bezeroak hiru modu ditu harekin elkarreragiteko: nameserver bat aurretik jartzea, fitxategia gainidaztea, edo bere zerbitzariak NetworkManagerri ematea eta daemonak berridaztea uztea. Hirugarren ereduak bakarrik gordetzen du esteka bakoitzeko DNSa, zerbitzariak interfaze bati lotuta jarraitzen dutelako, zerrenda global bakarrean zapaldu ordez.

NetworkManager sistemetan emaitza /etc/NetworkManager/NetworkManager.conf-eko backendaren araberakoa da:

[main]
dns=systemd-resolved

dns=default-rekin bezeroaren zerbitzariak resolv.conf-en fusionatzen dira irabazten duen ordenan, eta bilaketa pribatu bat oraindik resolver publikora joan daiteke. Estekak ulertzen dituen backend batekin, systemd-resolved edo dnsmasq, tunelaren zerbitzariak tunelean mugatuta geratzen dira eta bere routing domeinuarekin bat egiten duten izenak baino ez dira hara joaten. Mugatze hori da split DNS-ek praktikan esan nahi duena, eta hori da bezero batek onartzen duela dioenean gehienetan falta den pieza.

Irakurri egoera ezer aldatu aurretik:

resolvectl status
resolvectl dns tun0

tun interfazea DNS zerbitzari batekin eta sufixu pribaturako routing domeinu batekin zerrendatuta ikusi nahi duzu, ~internal.example gisa erakutsia. Estekan zerbitzaririk ez izateak bezeroak ezer bidali ez duela esan nahi du. Domeinurik gabeko zerbitzari batek bilaketak denak hara edo batere ez doazela esan nahi du, bezeroaren arabera, eta bietako bat ere ez da split DNS.

Non nsswitch-ek bilaketa goizegi amaitzen duen

Mahaigaineko lerro estandar bat horrela ikusten da:

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

mdns4_minimal-ek multicast DNSa kudeatzen du eta .local-ekin amaitzen den edozein izen aldarrikatzen du. api.infra.svc.cluster.local bezalako Kubernetes zerbitzu batek ere .local-ekin amaitzen du. mDNS moduluak NOTFOUND jakinarazten duenean, [NOTFOUND=return] ekintzak bilaketa osoa amaitzen du dns modulura jarraitu ordez, beraz izena ez da inoiz VPN resolverrera bidaltzen. dig-ek fitxategia erabat saihesten du, eta horregatik ez datoz bat bi tresnak.

Hori da arazo honetako kontraste zorrotzena, eta zure VPN baino zaharragoa den konfigurazio-fitxategi bateko hitz bakarrean datza. Ekintza [NOTFOUND=continue]-ra aldatzeak mDNS mantentzen du inprimagailu eta gailu lokaletarako, DNSak izena ikusi ahal izateko. Lerroa hosts: files dns-rekin ordezteak ere funtzionatzen du eta zakarragoa da: benetan erabiltzen duzun inprimagailuaren .local ebazpena kentzen du.

Sare bakarrean bizi diren izenak

Zona pribatuek leku bakarrean dute autoritatea. ip-10-0-4-31.eu-west-1.compute.internal bezalako AWS izen bat eskualde horretako VPC resolverren bidez erantzuten da, eta zure VPN endpointa baliabidearen eskualde berean dagoen bitartean soilik. Konektatu Frankfurteko endpoint batera, kontsultatu Irlandako compute.internal izen bat, eta inongo konfigurazio lokalek ez du lagunduko: erregistroa duen zona ez da hara iristen.

Bilaketa-domeinuek ispilu-irudia sortzen dute. service soil bat resolverrak egokitzat jotzen duen atxizkiarekin osatzen da, eta VPN esteka batekin domeinu lokalak korporatiboari irabaz diezaioke. Kontsultatu amaierako puntu batekin asmatzea kentzeko, getent ahosts service.internal.example., eta horrek funtzionatzen badu izen laburrak huts egiten duen bitartean, konponbidea tunelaren bilaketa-domeinua da, ez zerbitzariaren helbidea.

Kudeatutako bezeroek hirugarren geruza gehitzen dute sistemaren resolverraren gainean. Windows VPN profil batek bere izenen ebazpen-politika, aplikazio bakoitzeko arauak eta NRPT taula bat eraman ditzake, tunela itzalita dagoenean ere aplikatzen dena. DNS cache propioa duten aplikazioek, .NET eta Java runtimeetan ohikoak, huts egite zaharkitua mantentzen dute katea konpondu ondoren ere. Apple bezeroek split DNSa DNS ezarpenetako bat-etortze domeinuen bidez konfiguratzen dute, resolv.conf bidez ordez, eta Chromium edo Firefox DNS seguru moduan sistemaren resolverra saihes dezakete izen publikoetarako. Microsoften VPN izenen ebazpenari buruzko erreferentziak politika-geruza horren Windows aldea deskribatzen du.

Erabaki zein geruza konpondu

Sintometik geruzara joan, konponketak ordenan probatu ordez:

Bi errenkadek daramate pisu handiena. Timeout bat irisgarritasun-arazoa da: resolver pribatuak ez du tuneletik erantzuten, beraz egiaztatu haren helbiderako bidea eta estekako DNS zerbitzaria pentsatzen duzuna den. NXDOMAIN autoritate-arazoa da: zerbait erantzun zuen eta ez daki izena, eta horrek zonara, eskualdera edo kontsulta inoiz jaso behar ez zuen resolver batera eramaten du.

Azken errenkada da jendeak ahazten duena, bi erdiek arrakasta diruditelako. FQDNarekiko desberdin ebazten den izen laburra atxizki-desdoikuntza da, eta tunela berriz konektatzeak ez du aldatuko bezeroak bidaltzen duen atxizkia.

Hartu egoera konfigurazio-fitxategi bat editatu aurretik, aldaketak zerbait egin duen esan ahal izateko:

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

Exekutatu egiaztapenak ordena honetan eta gelditu huts egiten duen lehenengoan. getent-ek eta resolvectl query-k bat etorri behar dute; getent-ek huts egiten badu dig-ek erantzuten duen bitartean, geratu bilaketa-katean eta ez ukitu routinga. resolvectl status-ek DNS zerbitzari bat eta routing domeinu bat erakutsi behar ditu tun interfazean. nsswitch-ek ez du NOTFOUND-ekin goizegi itzuli behar probatzen ari zaren atxizkirako. Izenak autoritatea izan behar du zure endpointa konektatuta dagoen sarean, amaierako puntu batekin probatuta. Aplikazioak ez du bere cachea edo DNS seguruaren gainidazketa bat gorde behar.

Konpondu huts egiten duen lehen geruza soilik eta gero exekutatu komando berak berriro. Aldi berean bi aldaketa eginez gero, ezin duzu esan zeinek zenbatu zuen, eta hurrengo matxurak ikerketa hutsetik hasten du.