Kāpēc resolv.conf rāda jūsu VPN DNS, bet vaicājumi to ignorē

Žurnālos nekas neizskatās nepareizi: saskarne ir aktīva, atrisinātājs ziņo VPN DNS serveri, un failā uz diska tas ir uzskaitīts. Tomēr iekšējs resursdatora nosaukums joprojām tiek atrisināts caur vietējo maršrutētāju. Šie trīs apgalvojumi nav pretrunīgi, jo fails, katra savienojuma stāvoklis un vaicājuma ceļš ir dažādi objekti, kuriem nejauši ir kopīgs nosaukums. Turpmāk aprakstīts ceļš, ko vaicājums patiešām veic resursdatorā ar systemd-resolved.

Trīs objekti ar nosaukumu resolv.conf

Resursdatorā ar resolved /etc/resolv.conf parasti ir simboliskā saite uz /run/systemd/resolve/stub-resolv.conf. Šajā mērķī ir vietējā stub klausītāja adrese, 127.0.0.53, un resolved aprēķinātie meklēšanas domēni. Tas ir stāvokļa skats, nevis pats stāvoklis.

Stāvoklis dzīvo resolved konfigurācijā katram savienojumam, tāpēc resolvectl status var būt pretrunā ar failu un tomēr būt pareizs. Katrs savienojums nes savus serverus un savus maršrutēšanas domēnus, un stub konsultējas ar šiem datiem, kad pienāk vaicājums. systemd-resolved rokasgrāmata apraksta ģenerētos failus un katra savienojuma modeli; skata un stāvokļa atdalīšana ir tā daļa, ko ir vērts atcerēties. Simboliskās saites mērķa maiņa maina to, ko lasa tradicionālie klienti, nevis to, ko zina atrisinātājs.

Trešais objekts, /run/systemd/resolve/resolv.conf, sapludina katru savienojumu vienā serveru sarakstā. Programma, kas norāda uz šo failu, sūta vaicājumus tieši uz uzskaitītajiem serveriem un izlaiž stub, tāpēc katra savienojuma politika tai vairs nav spēkā. Tāpēc divas programmas vienā mašīnā var atbildēt uz vienu nosaukumu atšķirīgi, un neviena no tām nav bojāta.

Izsekojiet vienu meklēšanu caur NSS

glibc lasa /etc/nsswitch.conf, lai izlemtu, kas atbild uz nosaukumu. hosts rinda ar resolve novirza jautājumu uz nss-resolve, kas jautā resolved pa D-Bus un saņem katra savienojuma atbildi. Rinda tikai ar files dns sūta vaicājumu uz adresi, kas ir /etc/resolv.conf.

Šī vienīgā rinda izskaidro lielāko daļu nesaskaņu starp pārlūku un dig. dig lasa resolv.conf tieši un nekad neaiztiek NSS, tāpēc pārbauda stub vai augšupēju serveri, nevis ceļu, ko izmanto lietojumprogramma. getent hosts internal.example iet caur NSS, un tā atbildes salīdzināšana ar dig atbildi ir pirmais lietderīgais mērījums.

Lietojumprogrammas, kas sevī ietver atrisinātāju vai runā DNS pār HTTPS ar fiksētu galapunktu, apiet abus ceļus. Nekas resolv.conf vai resolved stāvoklī tās neierobežo.

Pārbaudiet, kuram pieder fails un uz ko tas norāda

Izlasiet saišu ķēdi, pirms kaut ko maināt, jo īpašumtiesības nosaka, kurš fails ir autoritatīvs. Katra zemāk esošā komanda tikai lasa stāvokli.

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

Pirmā rinda izdrukā saiti un tās mērķi kopā, un parasts fails, kas pieder VPN skriptam, nozīmē, ka atrisinātājs nekad neuzskata šo ierakstu par ievadi. Stāvokļa izvade uzskaita katra savienojuma serverus un maršrutēšanas domēnus, kas nosaka, kur katrs vaicājums dodas. nsswitch rinda pasaka, vai stub vispār tiek jautāts, tāpēc stub adrese failā bez resolve nozīmē, ka vaicājumi sasniedz vietējo klausītāju, kamēr nekas nepārvalda sadalījumu. Arī pēdējais saraksts ir svarīgs, jo resursdators bez stub-resolv.conf neizpilda šeit aprakstīto kārtību.

Ja ķēde beidzas failā, ko pārvalda cita pakotne, VPN klients un šī pakotne ir divi īpašnieki, kas jāsaskaņo. Saites aizstāšana izmet viena īpašnieka darbu un atstāj otra darbu vietā.

Labojiet pie saites īpašnieka

VPN savienojumam vajadzētu reģistrēt savus serverus un domēnus savā savienojumā un pēc tam tos atsaukt atvienošanās laikā. NetworkManager resolved integrācija un klienta paša palīgs darbojas tieši tā; skripts, kas tikai pārraksta resolv.conf, to nedara.

Jau esošā savienojumā mehānismu parāda izpildlaika iestatījumi. resolvectl dns tun0 10.40.0.53 pievieno serveri, un resolvectl domain tun0 '~corp.example' pievieno maršrutēšanas domēnu. Tilde ir slodzi nesošā rakstzīme: tā ierobežo šī sufiksa vaicājumus ar šo savienojumu un atstāj visu pārējo mierā, kamēr tā pati vērtība bez tās kļūst par meklēšanas domēnu un sadalījums iztvaiko. Šīs adreses ir laboratorijas piemēri, nevis pastāvīga konfigurācija. Apstipriniet ar resolvectl query host.corp.example un izlasiet, kurš savienojums atbildēja.

Reģistrētam serverim joprojām vajag maršrutu. Kad vaicājums sasniedz pareizo savienojumu un beidzas laiks, kļūda ir sasniedzamībā caur tuneli, nevis atrisinātāja īpašumtiesībās.

Kā izskatās strādājošs stāvoklis

Veselīgs rezultāts ir konsekvents visos trīs skatos: katra savienojuma serveri atbilst tam, ko izsniedza VPN, maršrutēšanas domēni aptver tikai iekšējos sufiksus, un svarīgā lietojumprogramma atrisina iekšēju nosaukumu, kamēr publiskais nosaukums joprojām seko vietējam ceļam. Viens veiksmīgs vaicājums pierāda mazāk nekā šī saskaņa.

Pēc tam atvienojieties un atkārtojiet abus vaicājumus. Klients, kas pēc nojaukšanas atstāj savus domēnus reģistrētus, rada mašīnu, kas pēc stundām neizdodas iekšējos meklējumos, bez atvērta tuneļa un bez acīmredzama iemesla.