Pse emrat e host-eve të brendshëm zgjidhen në dig por dështojnë në curl në një VPN

Laptopi juaj është në VPN, dig service.internal.example përgjigjet me një adresë 10.x, dhe curl përsëri del me Could not resolve host. Tuneli nuk është problemi: ai e transportoi pyetjen e dig pa u ankuar. Ajo që ndryshon është kush e bën pyetjen. dig dërgon një pyetje te një server që ju e emërtoni, ndërsa curl kalon nëpër zinxhirin e kërkimit të sistemit operativ, dhe ai zinxhir ka rregullat e veta se cili server pyetet.

Dy kërkime për të njëjtin emër

dig është stub resolver i vetë. Lexon /etc/resolv.conf, zgjedh një server emrash, dërgon një pyetje të vetme A ose AAAA dhe printon përgjigjen. E anashkalon plotësisht nsswitch dhe nuk di asgjë për gjendjen për lidhje që systemd-resolved ose NetworkManager mbajnë jashtë atij skedari, dhe për këtë arsye një përgjigje e dig mund të jetë e saktë dhe përsëri të mos ju thotë asgjë për atë që do të shohë aplikacioni juaj.

Aplikacionet thërrasin getaddrinfo, dhe getaddrinfo ndjek një zinxhir më të gjatë: renditja e moduleve të nsswitch, pastaj moduli që merret me emrin, dhe më pas resolveri i ndërtuar nga konfigurimi aktual i lidhjes. Në një makinë systemd pyetja shkon te 127.0.0.53 dhe systemd-resolved zgjedh një server të sipërm për çdo lidhje bazuar në domenin e rrugëtimit të lidhur me ndërfaqen tun.

Dy komanda i ndajnë ato shtresa pa hamendësuar:

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

getent përdor të njëjtën rrugë si curl, kështu që një dështim i getent pranë një dig funksional e lokalizon defektin te politika e kërkimit dhe jo te rrugëtimi i paketave. resolvectl query printon gjithashtu ndërfaqen dhe serverin e sipërm që dha përgjigjen, gjë që tregon nëse fitoi vendimi lidhja e tunelit apo lidhja fizike.

Lexoni resolverin që aplikacioni përdor në të vërtetë

/etc/resolv.conf gjenerohet në shumicën e desktopëve, dhe një klient VPN ka tre mënyra për të ndërvepruar me të: të vendosë një server emrash përpara, të mbishkruajë skedarin, ose t’ia japë serverat e tij NetworkManager dhe ta lërë daemonin ta rishkruajë. Vetëm modeli i tretë ruan DNS për çdo lidhje, sepse serverat mbeten të lidhur me një ndërfaqe në vend që të rrafshohen në një listë globale.

Në sistemet NetworkManager rezultati varet nga backend-i në /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Me dns=default serverat e klientit shkrihen në resolv.conf në rendin që fiton, dhe një kërkim privat përsëri mund të dërgohet te resolveri publik. Me një backend që i kupton lidhjet, systemd-resolved ose dnsmasq, serverat e tunelit mbeten të kufizuar në tunel dhe shkojnë atje vetëm emrat që përputhen me domenin e tij të rrugëtimit. Ky kufizim është ajo që do të thotë split DNS në praktikë, dhe është pjesa që mungon më shpesh kur një klient pretendon se e mbështet.

Lexoni gjendjen përpara se të ndryshoni çdo gjë:

resolvectl status
resolvectl dns tun0

Ju doni të shihni ndërfaqen tun të listuar me një server DNS dhe një domen rrugëtimi për sufiksin privat, të shfaqur si ~internal.example. Asnjë server në lidhje do të thotë që klienti nuk dërgoi asgjë. Një server pa domen do të thotë që kërkimet ose të gjitha shkojnë atje ose asnjë, në varësi të klientit, dhe asnjëra nuk është split DNS.

Ku nsswitch e përfundon kërkimin herët

Një rresht standard desktopi duket kështu:

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

mdns4_minimal merret me DNS multicast dhe pretendon çdo emër që mbaron me .local. Një shërbim Kubernetes si api.infra.svc.cluster.local mbaron gjithashtu me .local. Kur moduli mDNS raporton NOTFOUND, veprimi [NOTFOUND=return] e përfundon të gjithë kërkimin në vend që të vazhdojë te moduli dns, kështu që emri nuk dërgohet kurrë te resolveri i VPN. dig e anashkalon skedarin plotësisht, dhe pikërisht për këtë dy mjetet nuk bien dakord.

Ky është kontrasti më i mprehtë në këtë problem, dhe zbret në një fjalë të vetme në një skedar konfigurimi më të vjetër se VPN-i juaj. Ndryshimi i veprimit në [NOTFOUND=continue] ruan mDNS për printera dhe pajisje lokale ndërsa lejon DNS ta shohë emrin. Zëvendësimi i rreshtit me hosts: files dns funksionon gjithashtu dhe është më i trashë: heq zgjidhjen .local për printerin që përdorni në të vërtetë.

Emra që jetojnë në saktësisht një rrjet

Zonat private janë autoritative në saktësisht një vend. Një emër AWS si ip-10-0-4-31.eu-west-1.compute.internal përgjigjet përmes resolverit të VPC-së së asaj rajoni, dhe vetëm për sa kohë pika juaj fundore e VPN është në të njëjtin rajon me burimin. Lidhuni me një pikë fundore në Frankfurt, kërkoni një emër compute.internal nga Irlanda, dhe asnjë cilësim lokal nuk do të ndihmojë: zona që mban regjistrimin nuk është e arritshme nga atje.

Domenet e kërkimit prodhojnë pasqyrën. Një service i thjeshtë plotësohet me sufiksin që resolveri mendon se zbatohet, dhe me një lidhje VPN domeni lokal mund të fitojë mbi atë korporativ. Kërkoni me një pikë në fund për të hequr hamendësimin, getent ahosts service.internal.example., dhe nëse kjo funksionon ndërsa emri i shkurtër dështon, korrigjimi është domeni i kërkimit në tunel, jo adresa e serverit.

Klientët e menaxhuar shtojnë një shtresë të tretë mbi resolverin e sistemit. Një profil VPN i Windows mund të mbajë politikën e vet të zgjidhjes së emrave, rregulla për çdo aplikacion dhe një tabelë NRPT që zbatohet edhe kur tuneli është i fikur. Aplikacionet me cache DNS të vetin, të zakonshme në runtime .NET dhe Java, mbajnë një dështim të vjetruar shumë kohë pasi zinxhiri është rregulluar. Klientët Apple konfigurojnë split DNS përmes domeneve të përputhjes në cilësimet e DNS në vend të resolv.conf, dhe Chromium ose Firefox në modalitetin DNS të sigurt mund të anashkalojnë resolverin e sistemit për emra publikë. Referenca e Microsoft për zgjidhjen e emrave të VPN përshkruan anën Windows të asaj shtrese politike.

Vendosni cilën shtresë të rregulloni

Punoni nga simptoma te shtresa në vend që të provoni rregullime me radhë:

Dy rreshta mbajnë pjesën më të madhe të peshës. Një timeout është problem arritshmërie: resolveri privat nuk përgjigjet përmes tunelit, prandaj kontrolloni rrugën drejt adresës së tij dhe nëse serveri DNS në lidhje është ai që mendoni. NXDOMAIN është problem autoriteti: diçka u përgjigj dhe nuk e njeh emrin, gjë që tregon zonën, rajonin ose një resolver që nuk duhej ta kishte marrë kurrë pyetjen.

Rreshti i fundit është ai që njerëzit e humbasin sepse të dyja gjysmat duken si sukses. Një emër i shkurtër që zgjidhet ndryshe nga FQDN është një mospërputhje sufiksi, dhe rilidhja e tunelit nuk do të ndryshojë cilin sufiks dërgon klienti.

Regjistroni gjendjen përpara se të redaktoni një skedar konfigurimi, që të mund të thoni nëse redaktimi bëri diçka:

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

Ekzekutoni kontrollet në këtë rend dhe ndaloni te e para që dështon. getent dhe resolvectl query duhet të përputhen; nëse getent dështon ndërsa dig përgjigjet, qëndroni në zinxhirin e kërkimit dhe mos prekni rrugëtimin. resolvectl status duhet të tregojë një server DNS dhe një domen rrugëtimi në ndërfaqen tun. nsswitch nuk duhet të kthehet herët me NOTFOUND për sufiksin që po testoni. Emri duhet të jetë autoritativ në rrjetin ku është lidhur pika juaj fundore, i testuar me një pikë në fund. Aplikacioni nuk duhet të mbajë cache të vetin ose një anashkalim të DNS të sigurt.

Rregulloni vetëm shtresën e parë që dështon dhe pastaj ekzekutoni përsëri të njëjtat komanda. Dy ndryshime njëherësh ju lënë të paaftë të thoni cili kishte rëndësi, dhe avaria tjetër e nis hetimin nga zero.