Miks sisemised hostinimed lahenevad dig-is, aga nurjuvad curl-is VPN-is
dig vastab, kuid curl teatab, et ei suuda hosti lahendada. Võrrelge kahte otsinguahelat ja parandage seejärel nsswitch, lingipõhine DNS või vale otsingusufiks.
Sinu sülearvuti on VPN-is, dig service.internal.example vastab 10.x aadressiga ja curl väljub ikkagi Could not resolve host-ga. Tunnel ei ole probleem: see transportis digi päringu ilma kaevamata. Erinev on see, kes küsimuse esitab. dig saadab ühe päringu ühele serverile, mille sina nimetad, samal ajal kui curl läbib operatsioonisüsteemi otsinguahela ja sellel ahelal on omad reeglid selle kohta, milliselt serverilt küsitakse.
Kaks otsingut sama nime jaoks
dig on omaette stub-resolver. See loeb /etc/resolv.confi, valib nimeserveri, saadab ühe A- või AAAA-päringu ja trükib vastuse. See jätab nsswitchi täielikult vahele ega tea midagi lingipõhisest olekust, mida systemd-resolved või NetworkManager väljaspool seda faili hoiavad, ja seetõttu võib digi vastus olla õige ning ikkagi mitte öelda sulle midagi selle kohta, mida sinu rakendus näeb.
Rakendused kutsuvad getaddrinfo’t ja getaddrinfo läbib pikema ahela: nsswitchi moodulite järjekord, seejärel nime käsitlev moodul ja lõpuks praegusest lingikonfiguratsioonist ehitatud resolver. systemd-masinas läheb päring aadressile 127.0.0.53 ja systemd-resolved valib lingipõhise ülemvooluserveri tun-liidesega seotud marsruutimisdomeeni järgi.
Kaks käsku eraldavad need kihid ilma oletamata:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent kasutab sama teed kui curl, seega getenti tõrge töötava digi kõrval paigutab vea otsingupoliitikasse, mitte paketimarsruutimisse. resolvectl query trükib ka liidese ja ülemvoolu, mis vastuse andis, mis näitab, kas otsuse võitis tunneli link või füüsiline link.
Loe resolverit, mida rakendus tegelikult kasutab
/etc/resolv.conf genereeritakse enamikul töölaudadel ja VPN-kliendil on kolm viisi sellega suhelda: lisada nimeserver ette, fail üle kirjutada või anda oma serverid NetworkManagerile ja lasta deemonil see ümber kirjutada. Ainult kolmas muster säilitab lingipõhise DNS-i, sest serverid jäävad liidese külge kinnitatuks, selle asemel et lamedalt ühte globaalsesse nimekirja paisata.
NetworkManageri süsteemides sõltub tulemus backendist failis /etc/NetworkManager/NetworkManager.conf:
[main]
dns=systemd-resolvedValikuga dns=default sulandatakse kliendi serverid resolv.confi võitvas järjekorras ja privaatne otsing võib ikkagi minna avalikku resolverisse. Linke mõistva backendiga, systemd-resolved või dnsmasq, jäävad tunneli serverid tunneliga piiratuks ja sinna lähevad ainult selle marsruutimisdomeeniga sobivad nimed. See piiramine on see, mida split DNS praktikas tähendab, ja see on tükk, mis kõige sagedamini puudub, kui klient väidab, et toetab seda.
Loe olekut enne, kui midagi muudad:
resolvectl status
resolvectl dns tun0Sa tahad näha tun-liidest loetletuna DNS-serveri ja privaatse sufiksi marsruutimisdomeeniga, kuvatuna kujul ~internal.example. Serveri puudumine lingil tähendab, et klient ei saatnud midagi. Domeenita server tähendab, et otsingud lähevad kas kõik sinna või mitte ükski, olenevalt kliendist, ja kumbki neist ei ole split DNS.
Kus nsswitch lõpetab otsingu liiga vara
Tavaline töölaua rida näeb välja selline:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal tegeleb multicast-DNS-iga ja nõuab iga .local-lõpulist nime. Kubernetes-teenus nagu api.infra.svc.cluster.local lõpeb samuti .local-iga. Kui mDNS-moodul teatab NOTFOUND, lõpetab tegevus [NOTFOUND=return] kogu otsingu, selle asemel et jätkata dns-moodulini, nii et nime ei saadeta kunagi VPN-i resolverisse. dig möödub failist täielikult ja täpselt seetõttu ei ole need kaks tööriista ühel meelel.
See on selle probleemi teravaim kontrast ja taandub ühele sõnale konfiguratsioonifailis, mis on sinu VPN-ist vanem. Tegevuse muutmine valikuks [NOTFOUND=continue] säilitab mDNS-i printerite ja kohalike seadmete jaoks, lastes DNS-il nime näha. Rea asendamine valikuga hosts: files dns toimib samuti ja on jämedam: see jätab välja .local-i lahendamise printeri jaoks, mida sa tegelikult kasutad.
Nimed, mis elavad täpselt ühes võrgus
Privaatsed tsoonid on autoriteetsed täpselt ühes kohas. AWS-i nimi nagu ip-10-0-4-31.eu-west-1.compute.internal vastatakse selle piirkonna VPC-resolveri kaudu ja ainult seni, kuni sinu VPN-i lõpp-punkt on ressursiga samas piirkonnas. Ühendu Frankfurdi lõpp-punktiga, päri Iirimaa compute.internal nime ja ükski kohalik seade ei aita: kirjet hoidvale tsoonile ei pääse sealt ligi.
Otsingudomeenid tekitavad peegelpildi. Paljas service täiendatakse sufiksiga, mida resolver peab kohaldatavaks, ja VPN-lingiga võib kohalik domeen võita ettevõtte oma. Päri lõpp-punktiga, et oletus eemaldada, getent ahosts service.internal.example., ja kui see toimib, samal ajal kui lühike nimi nurjub, on parandus tunneli otsingudomeen, mitte serveri aadress.
Hallatud kliendid lisavad süsteemi resolveri kohale kolmanda kihi. Windowsi VPN-profiil võib kanda oma nimelahenduspoliitikat, rakendusepõhiseid reegleid ja NRPT-tabelit, mis kehtib ka siis, kui tunnel on maas. Oma DNS-vahemäluga rakendused, mis on tavalised .NET- ja Java-runtime’ides, hoiavad aegunud tõrget kaua pärast ahela parandamist. Apple’i kliendid seadistavad split DNS-i DNS-seadete sobivusdomeenide kaudu, mitte resolv.confi kaudu, ja Chromium või Firefox turvalise DNS-i režiimis võivad avalike nimede puhul süsteemi resolverist mööda minna. Microsofti VPN-i nimelahenduse viide kirjeldab selle poliitikakihi Windowsi poolt.
Otsusta, millist kihti parandada
Tööta sümptomist kihi poole, selle asemel et parandusi järjekorras proovida:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
Kaks rida kannavad suurima osa raskusest. Aegumine on kättesaadavuse probleem: privaatne resolver ei vasta tunneli kaudu, seega kontrolli marsruuti selle aadressini ja kas lingi DNS-server on see, mida arvad. NXDOMAIN on autoriteedi probleem: midagi vastas ja ei tea nime, mis viitab tsoonile, piirkonnale või resolverile, mis ei oleks tohtinud päringut kunagi saada.
Viimane rida on see, mille inimesed vahele jätavad, sest mõlemad pooled näevad välja nagu edu. FQDN-ist erinevalt lahenev lühike nimi on sufiksi mittevastavus ja tunneli uuesti ühendamine ei muuda seda, millist sufiksit klient saadab.
Jäädvusta olek enne konfiguratsioonifaili muutmist, et saaksid öelda, kas muudatus midagi tegi:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtKäivita kontrollid selles järjekorras ja peatu esimesel, mis nurjub. getent ja resolvectl query peavad ühtima; kui getent nurjub, samal ajal kui dig vastab, jää otsinguahelasse ja ära marsruutimist puuduta. resolvectl status peab näitama DNS-serverit ja marsruutimisdomeeni tun-liidesel. nsswitch ei tohi NOTFOUND-i korral testitava sufiksi jaoks liiga vara tagasi pöörduda. Nimi peab olema autoriteetne võrgus, millega sinu lõpp-punkt on ühendatud, testitud lõpp-punktiga. Rakendus ei tohi hoida oma vahemälu ega turvalise DNS-i alistust.
Paranda ainult esimest nurjuvat kihti ja käivita seejärel samad käsud uuesti. Kaks muudatust korraga ei lase sul öelda, milline neist loeb, ja järgmine katkestus alustab uurimist nullist.