Pse resolv.conf shfaq DNS-në e VPN-së tuaj por kërkimet e injorojnë

Në regjistra asgjë nuk duket gabim: ndërfaqja është aktive, zgjidhësi raporton serverin DNS të VPN-së dhe skedari në disk e liston atë. Megjithatë, një emër hosti i brendshëm ende zgjidhet përmes ruterit lokal. Këto tre pohime nuk kundërshtojnë njëri-tjetrin, sepse skedari, gjendja e çdo lidhjeje dhe rruga e kërkimit janë objekte të ndryshme që ndajnë rastësisht të njëjtin emër. Në vijim përshkruhet rruga që një kërkesë ndjek vërtet në një host me systemd-resolved.

Tre objekte të quajtura resolv.conf

Në një host me resolved, /etc/resolv.conf është zakonisht një lidhje simbolike drejt /run/systemd/resolve/stub-resolv.conf. Ai objektiv mban adresën e një dëgjuesi stub lokal, 127.0.0.53, plus domenet e kërkimit që ka llogaritur resolved. Është një pamje e gjendjes, jo gjendja vetë.

Gjendja jeton në konfigurimin e resolved për çdo lidhje, dhe prandaj resolvectl status mund të mos pajtohet me skedarin dhe gjithsesi të ketë të drejtë. Çdo lidhje mbart serverët e vet dhe domenet e veta të rrugëzimit, dhe stub-i konsulton ato të dhëna kur mbërrin një kërkesë. Manuali i systemd-resolved përshkruan skedarët e gjeneruar dhe modelin për çdo lidhje; ndarja midis pamjes dhe gjendjes është pjesa që ia vlen të mbahet mend. Ndryshimi i objektivit të lidhjes simbolike ndryshon atë që lexojnë klientët tradicionalë, jo atë që di zgjidhësi.

Një objekt i tretë, /run/systemd/resolve/resolv.conf, e rrafshon çdo lidhje në një listë të vetme serverësh. Një program i drejtuar drejt atij skedari i dërgon kërkesat drejtpërdrejt serverëve të listuar dhe e anashkalon stub-in, kështu që politika për çdo lidhje nuk vlen më për të. Prandaj dy programe në të njëjtën makinë mund t'i përgjigjen ndryshe të njëjtit emër, dhe asnjëri nuk është i prishur.

Ndiqni një kërkim përmes NSS

glibc lexon /etc/nsswitch.conf për të vendosur kush përgjigjet për një emër. Rreshti hosts që përmban resolve e drejton pyetjen te nss-resolve, i cili e pyet resolved përmes D-Bus dhe merr përgjigjen për lidhjen. Rreshti vetëm me files dns e dërgon kërkesën te adresa që mban /etc/resolv.conf.

Ky rresht i vetëm shpjegon shumicën e mospajtimeve midis një shfletuesi dhe dig. dig lexon resolv.conf drejtpërdrejt dhe nuk e prek kurrë NSS, prandaj teston stub-in ose një server mbi të, jo rrugën që përdor aplikacioni. getent hosts internal.example kalon përmes NSS, dhe krahasimi i përgjigjes së tij me atë të dig është matja e parë e dobishme.

Aplikacionet që sjellin zgjidhësin e tyre, ose flasin DNS përmes HTTPS me një pikë fundore fikse, i anashkalojnë të dyja rrugët. Asgjë në resolv.conf ose në gjendjen e resolved nuk i kufizon.

Kontrolloni kujt i përket skedari dhe ku tregon

Lexoni zinxhirin e lidhjeve përpara se të ndryshoni diçka, sepse pronësia vendos se cili skedar është autoritar. Çdo komandë më poshtë lexon vetëm gjendjen.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Rreshti i parë printon lidhjen dhe objektivin e saj së bashku, dhe një skedar i zakonshëm në pronësi të një skripti VPN do të thotë që zgjidhësi nuk e trajton kurrë atë shkrim si hyrje. Dalja e gjendjes liston serverët për çdo lidhje plus domenet e rrugëzimit që vendosin se ku shkon çdo kërkesë. Rreshti nsswitch thotë nëse stub-i konsultohet fare, prandaj një adresë stub në skedar pa resolve atje do të thotë që kërkesat arrijnë te dëgjuesi lokal ndërsa asgjë nuk e menaxhon ndarjen. Edhe ajo listë e fundit ka rëndësi, sepse një host pa stub-resolv.conf nuk e ekzekuton rregullimin e përshkruar këtu.

Nëse zinxhiri përfundon në një skedar të menaxhuar nga një paketë tjetër, klienti VPN dhe ajo paketë janë dy pronarët që duhen pajtuar. Zëvendësimi i lidhjes hedh punën e një pronari dhe e lë atë të tjetrit në vend.

Riparoni te pronari i lidhjes

Një lidhje VPN duhet të regjistrojë serverët dhe domenet e saj në lidhjen e vet, pastaj t'i tërheqë ato kur shkëputet. Integrimi resolved i NetworkManager dhe ndihmësi i vetë klientit funksionojnë të dy kështu; një skript që vetëm rishkruan resolv.conf nuk e bën.

Në një lidhje që ekziston tashmë, mekanizmin e tregojnë cilësimet në kohë ekzekutimi. resolvectl dns tun0 10.40.0.53 lidh një server, dhe resolvectl domain tun0 '~corp.example' lidh një domen rrugëzimi. Tilda është karakteri mbajtës: i kufizon kërkesat për atë prapashtesë në këtë lidhje dhe lë gjithçka tjetër në qetësi, ndërsa e njëjta vlerë pa të bëhet domen kërkimi dhe ndarja avullohet. Ato adresa janë shembuj laboratori, jo konfigurim i përhershëm. Konfirmoni me resolvectl query host.corp.example dhe lexoni cila lidhje u përgjigj.

Një server i regjistruar ka gjithsesi nevojë për një rrugë. Kur kërkesa arrin lidhjen e duhur dhe skadon, defekti është në arritshmërinë përmes tunelit, jo në pronësinë e zgjidhësit.

Si duket një gjendje që funksionon

Një rezultat i shëndoshë është i qëndrueshëm në të tre pamjet: serverët për çdo lidhje përputhen me atë që shpërndau VPN, domenet e rrugëzimit mbulojnë vetëm prapashtesa të brendshme, dhe aplikacioni që ka rëndësi zgjidh një emër të brendshëm ndërsa një emër publik vazhdon të ndjekë rrugën lokale. Një kërkesë e suksesshme provon më pak se ai përputhje.

Pastaj shkëputuni dhe përsërisni të dyja kërkesat. Një klient që i lë domenet e veta të regjistruara pas çmontimit prodhon një makinë që dështon në kërkimet e brendshme orë më vonë, pa tunel të hapur dhe pa shkak të dukshëm.