Kāpēc iekšējie resursdatoru nosaukumi tiek atrisināti ar dig, bet neizdodas ar curl VPN savienojumā
dig atbild, bet curl ziņo, ka nevar atrisināt resursdatoru. Salīdziniet abas meklēšanas ķēdes un pēc tam izlabojiet nsswitch, DNS katram savienojumam vai nepareizu meklēšanas sufiksu.
Jūsu klēpjdators ir VPN savienojumā, dig service.internal.example atbild ar 10.x adresi, un curl joprojām beidzas ar Could not resolve host. Tunelis nav problēma: tas pārnesa dig vaicājumu bez iebildumiem. Atšķiras tas, kas uzdod jautājumu. dig nosūta vienu vaicājumu vienam jūsu norādītam serverim, bet curl iet caur operētājsistēmas meklēšanas ķēdi, un šai ķēdei ir savi noteikumi par to, kuram serverim jautā.
Divi vaicājumi vienam nosaukumam
dig ir savs stub resolver. Tas nolasa /etc/resolv.conf, izvēlas nosaukumu serveri, nosūta vienu A vai AAAA vaicājumu un izdrukā atbildi. Tas pilnībā izlaiž nsswitch un nezina neko par saites līmeņa stāvokli, ko systemd-resolved vai NetworkManager glabā ārpus šī faila, tāpēc dig atbilde var būt pareiza un tomēr neko nepateikt par to, ko redzēs jūsu lietojumprogramma.
Lietojumprogrammas izsauc getaddrinfo, un getaddrinfo iet garāku ķēdi: nsswitch moduļu secība, pēc tam modulis, kas apstrādā nosaukumu, un visbeidzot resolver, kas veidots no pašreizējās saites konfigurācijas. systemd mašīnā vaicājums dodas uz 127.0.0.53, un systemd-resolved izvēlas augšupēju serveri katrai saitei, balstoties uz maršrutēšanas domēnu, kas piesaistīts tun saskarnei.
Divas komandas atdala šos slāņus bez minēšanas:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent izmanto to pašu ceļu kā curl, tāpēc getent kļūda blakus strādājošam dig lokalizē defektu meklēšanas politikā, nevis pakešu maršrutēšanā. resolvectl query izdrukā arī saskarni un augšupēju, kas sniedza atbildi, kas parāda, vai lēmumu ieguva tuneļa saite vai fiziskā saite.
Izlasiet resolver, ko lietojumprogramma faktiski izmanto
/etc/resolv.conf tiek ģenerēts lielākajā daļā darbvirsmu, un VPN klientam ir trīs veidi, kā ar to mijiedarboties: pievienot nosaukumu serveri priekšā, pārrakstīt failu vai nodot savus serverus NetworkManager un ļaut dēmonam to pārrakstīt. Tikai trešais modelis saglabā saites līmeņa DNS, jo serveri paliek piesaistīti saskarnei, nevis tiek saplacināti vienā globālā sarakstā.
NetworkManager sistēmās rezultāts ir atkarīgs no backend failā /etc/NetworkManager/NetworkManager.conf:
[main]
dns=systemd-resolvedAr dns=default klienta serveri tiek sapludināti resolv.conf tādā secībā, kāda uzvar, un privāts vaicājums joprojām var tikt nosūtīts publiskajam resolver. Ar backend, kas saprot saites, systemd-resolved vai dnsmasq, tuneļa serveri paliek ierobežoti ar tuneli, un tur dodas tikai tā maršrutēšanas domēnam atbilstošie nosaukumi. Šis ierobežojums ir tas, ko split DNS nozīmē praksē, un tas ir elements, kas visbiežāk trūkst, kad klients apgalvo, ka to atbalsta.
Izlasiet stāvokli pirms kaut ko maināt:
resolvectl status
resolvectl dns tun0Jūs vēlaties redzēt tun saskarni ar DNS serveri un privātā sufiksa maršrutēšanas domēnu, parādītu kā ~internal.example. Nav servera saitē nozīmē, ka klients neko nav nosūtījis. Serveris bez domēna nozīmē, ka vaicājumi vai nu visi dodas turp, vai neviens, atkarībā no klienta, un neviens no variantiem nav split DNS.
Kur nsswitch pārtrauc meklēšanu pārāk agri
Standarta darbvirsmas rinda izskatās šādi:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal apstrādā multicast DNS un pretendē uz katru nosaukumu, kas beidzas ar .local. Kubernetes pakalpojums, piemēram, api.infra.svc.cluster.local, arī beidzas ar .local. Kad mDNS modulis ziņo NOTFOUND, darbība [NOTFOUND=return] pārtrauc visu meklēšanu, nevis turpina uz dns moduli, tāpēc nosaukums nekad netiek nosūtīts VPN resolver. dig apiet failu pilnībā, un tieši tāpēc abi rīki nepiekrīt viens otram.
Tas ir asākais kontrasts šajā problēmā, un tas reducējas uz vienu vārdu konfigurācijas failā, kas ir vecāks par jūsu VPN. Nomainot darbību uz [NOTFOUND=continue], mDNS tiek saglabāts printeriem un vietējām ierīcēm, vienlaikus ļaujot DNS redzēt nosaukumu. Rindas aizstāšana ar hosts: files dns arī darbojas un ir rupjāka: tā atmet .local atrisināšanu printerim, kuru jūs faktiski lietojat.
Nosaukumi, kas dzīvo tieši vienā tīklā
Privātās zonas ir autoritatīvas tieši vienā vietā. AWS nosaukums, piemēram, ip-10-0-4-31.eu-west-1.compute.internal, tiek atbildēts caur tā reģiona VPC resolver, un tikai tik ilgi, kamēr jūsu VPN galapunkts atrodas tajā pašā reģionā kā resurss. Pieslēdzieties Frankfurtes galapunktam, vaicājiet Īrijas compute.internal nosaukumu, un neviens vietējais iestatījums nepalīdzēs: zona, kurā glabājas ieraksts, no turienes nav sasniedzama.
Meklēšanas domēni rada spoguļattēlu. Tukšs service tiek papildināts ar sufiksu, ko resolver uzskata par piemērotu, un ar VPN saiti vietējais domēns var uzvarēt uzņēmuma domēnu. Vaicājiet ar beigu punktu, lai noņemtu minējumus, getent ahosts service.internal.example., un, ja tas darbojas, kamēr īsais nosaukums neizdodas, labojums ir meklēšanas domēns tunelī, nevis servera adrese.
Pārvaldītie klienti pievieno trešo slāni virs sistēmas resolver. Windows VPN profils var saturēt savu nosaukumu atrisināšanas politiku, noteikumus katrai lietojumprogrammai un NRPT tabulu, kas ir spēkā arī tad, kad tunelis ir izslēgts. Lietojumprogrammas ar savu DNS kešatmiņu, kas ierastas .NET un Java izpildvidēs, saglabā novecojušu kļūdu ilgi pēc ķēdes salabošanas. Apple klienti konfigurē split DNS ar atbilstības domēniem DNS iestatījumos, nevis ar resolv.conf, un Chromium vai Firefox drošā DNS režīmā var apiet sistēmas resolver publiskiem nosaukumiem. Microsoft VPN nosaukumu atrisināšanas uzziņa apraksta šī politikas slāņa Windows pusi.
Izlemiet, kuru slāni labot
Strādājiet no simptoma uz slāni, nevis mēģiniet labojumus pēc kārtas:
| 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 |
Divas rindas nes lielāko daļu svara. Taimauts ir sasniedzamības problēma: privātais resolver neatbild caur tuneli, tāpēc pārbaudiet maršrutu uz tā adresi un to, vai saites DNS serveris ir tas, ko domājat. NXDOMAIN ir autoritātes problēma: kaut kas atbildēja un nezina nosaukumu, kas norāda uz zonu, reģionu vai resolver, kuram nekad nevajadzēja saņemt vaicājumu.
Pēdējā rinda ir tā, ko cilvēki izlaiž, jo abas puses izskatās pēc panākumiem. Īss nosaukums, kas tiek atrisināts citādi nekā FQDN, ir sufiksa neatbilstība, un tuneļa atkārtota pievienošana nemainīs to, kādu sufiksu klients nosūta.
Fiksējiet stāvokli pirms konfigurācijas faila rediģēšanas, lai varētu pateikt, vai rediģējums kaut ko mainīja:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtIzpildiet pārbaudes šajā secībā un apstājieties pie pirmās, kas neizdodas. getent un resolvectl query jāsakrīt; ja getent neizdodas, kamēr dig atbild, palieciet meklēšanas ķēdē un neaiztieciet maršrutēšanu. resolvectl status jāparāda DNS serveris un maršrutēšanas domēns tun saskarnē. nsswitch nedrīkst atgriezties agri ar NOTFOUND testējamajam sufiksam. Nosaukumam jābūt autoritatīvam tīklā, kuram pievienots jūsu galapunkts, pārbaudīts ar beigu punktu. Lietojumprogramma nedrīkst glabāt savu kešatmiņu vai drošā DNS ignorēšanu.
Labojiet tikai pirmo neizdevušos slāni un pēc tam vēlreiz izpildiet tās pašas komandas. Divas izmaiņas uzreiz neļauj pateikt, kura bija svarīga, un nākamā avārija sāk izmeklēšanu no nulles.