Kāpēc jūsu /etc/hosts ieraksts nesasniedz VPN DNS

Jūs pievienojāt nosaukumu /etc/hosts failam, pievienojāties VPN un gaidījāt, ka ieraksts būs redzams visiem. Tas nenotiek, un pārsteigums parasti nāk ar otru simptomu: nosaukums atrisinās jūsu mašīnā un neizdodas kolēģa mašīnā, kas izskatās pēc salauztas VPN DNS pakalpojuma un patiesībā hosts fails dara tieši to, kam tas bija paredzēts. Hosts fails ir lokāla nosaukumu izšķiršanas konfigurācija, nevis zonas atjauninājums, un nekas parastā VPN savienojumā to neaugšupielādē.

Hosts ir lokāla pārrakstīšana, nevis zonas atjauninājums

Fails ir kartējumu saraksts, ar ko nosaukumu pakalpojuma bibliotēkas konsultējas pirms DNS servera jautāšanas vai tā vietā. Rinda, piemēram, 10.40.0.20 build.corp.example, maina to, ko secina lietojumprogrammas tajā vienā mašīnā. Tā neveido ierakstu, tā neceļo pa tuneli, un DNS serverim, uz kuru norāda tunelis, nav ne jausmas, ka tā pastāv.

Tāpēc kļūme ir asimetriska. Jūsu klients saņem atbildi no faila. Cits klients jautā VPN DNS serverim, kas neko neatgriež, un lietojumprogramma ziņo, ka nosaukums neeksistē. Abas mašīnas uzvedas pareizi; tikai vienai ir pārrakstīšana, ko otra nekad nav redzējusi.

Divas komandas, divas dažādas sastāvdaļas

Ātrākais veids, kā izbeigt strīdu, ir padarīt atšķirību redzamu divās komandās, abas izpildītas tajā klientā, kuram ir hosts ieraksts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Pirmā jautā pašas sistēmas meklēšanas ceļu, kas tipiskā glibc sistēmā lasa lokālos failus pirms DNS. Otrā sūta DNS vaicājumu tieši serverim šajā adresē un vispār nekonsultējas ar lokālajiem failiem. Kad pirmā atgriež jūsu ierakstu un otrā atgriež NXDOMAIN, jūs esat pierādījis, ka ieraksts DNS neeksistē un ka jūsu mašīna atbild no lokālas pārrakstīšanas.

Secība ir konfigurējama, un to ir vērts pārbaudīt pirms jebkādu secinājumu izdarīšanas par konkrētu distribūciju. Apskatiet hosts: rindu /etc/nsswitch.conf failā; hosts: files dns vispirms konsultējas ar failiem. Nekopējiet šo piemēru uz strādājošu konfigurāciju tikai tāpēc, lai mainītu secību, jo reālās sistēmas bieži uzskaita papildu avotus un nosacītus pakalpojumu ierakstus, kuru piemērā nav.

systemd-resolved padara testu neskaidru

Sistēmā, kas izmanto systemd-resolved, lokālais stub arī apkalpo nosaukumus no hosts datubāzes. Tāpēc vaicājums uz 127.0.0.53 nav neatkarīgs attālā servera tests, lai gan tas izskatās kā DNS vaicājums un uzvedas tāpat. Ko zina risinātājs un kuri serveri tas jautātu, varat apstiprināt ar:

resolvectl query build.corp.example
resolvectl status

Status izvade nosauc DNS serverus katram savienojumam, un tā jūs uzzināt, vai VPN savienojums vispār saņēma risinātāju. Šis jautājums ir atsevišķs no hosts ieraksta, un tas ir tas, ko ir vērts jautāt, kad privāts nosaukums neizdodas visiem lietotājiem, nevis vienam.

Lietojumprogrammas var pievienot vēl vienu slāni. Pārlūks ar savu DNS-over-HTTPS iestatījumu, konteiners ar savu risinātāja konfigurāciju vai izpildlaiks, kas kešo meklējumus visā procesa dzīves laikā, katrs var atbildēt citādi nekā sistēma. Pārbaudiet lietojumprogrammu, kas jums ir svarīga, nevis pieņemiet, ka viena komanda apraksta katru programmu mašīnā.

Kas patiesībā dala nosaukumu pāri VPN

Ja privātam nosaukumam jādarbojas visiem, tam vajadzīgs īpašnieks, kuru var sasniegt visu risinātājs. Tīrā atbilde ir publicēt ierakstu pārvaldītā zonā un padarīt šo zonu atrisināmu paredzētajā VPN DNS ceļā. Tad ierakstam ir viens patiesības avots, audita pēdas un dzīves cikls, un nevienam nav jāatceras, kurš portatīvais dators nes lokālu pārrakstīšanu.

Hosts failu izplatīšana ir leģitīma alternatīva, un tā ir galapunktu pārvaldība, nevis nosaukumu pakalpojums. Ja jūs to izvēlaties, fails ir jāizvieto, jāversijas un jānoņem tam, kas pārvalda floti, un tā tas jāapraksta dizainā. „VPN ar to tiek galā“ nav šī procesa apraksts.

Dinamiskā DNS reģistrācija ir trešais mehānisms ar savām atļaujām, atjauninājumu autentifikāciju un ieraksta dzīves ilgumu. Tas neizriet no hosts ieraksta, un tas neizriet arī no klienta vienkāršas pievienošanās, ja vien serveris un klients abi nav tam konfigurēti. Ieraksts, kas parādās pats no sevis, ir signāls, ka kāds ir iespējojis drošus atjauninājumus un klients reģistrē sevi, un šī konfigurācija pieder dizaina ierakstam, nevis problēmu novēršanas pavedienam. Ja neviens nevar nosaukt šī iestatījuma īpašnieku, uzskatiet automātisko ierakstu par nepārbaudītu un saglabājiet pārvaldīto zonu kā patiesības avotu.

Atrisināts nosaukums nav maršruts

Nosaukumu izšķiršana un sasniedzamība ir atsevišķas lietas, un novecojis lokālais kartējums ir klasiskais veids, kā tās sajaukt. Hosts ieraksts, kas norāda uz adresi, kura ir pārvietota, turpinās izvēlēties novecojušo resursdatoru vēl ilgi pēc DNS labošanas, un simptoms izskatās kā maršrutēšanas kļūda nosaukumam, kas labi atrisinās.

Tāpēc, kad ziņojums ir „nosaukums atrisinās, bet pakalpojums nav sasniedzams“, salīdziniet sistēmas meklēšanu ar skaidru vaicājumu VPN DNS serverim, pēc tam pārbaudiet iegūto adresi pret to, ko pakalpojums faktiski izmanto. systemd-resolved atsauce dokumentē lokālos avotus, ar kuriem tas konsultējas, un tas ir kartē, kas jums nepieciešama šim salīdzinājumam.

Pēc tam izlabojiet pārrakstīšanu caur tās īpašnieku. Vienas rindas noņemšana no jūsu paša hosts faila neko nedara divpadsmit portatīvajiem datoriem, kuri saņēma to pašu rindu no izvietošanas skripta, un tā ir šīs problēmas versija, kas cilvēkiem patiešām ir.