VPN DNS darbojas, bet .local vārdi joprojām neizdodas: kas tos atrisina?

Divi datori tajā pašā VPN, tas pats resursdatora nosaukums, un tikai viens no tiem to atrisina: atšķirība parasti nav tunelī, bet gan tajā, kurš atrisinātājs atbildēja. Linux darbvirsmā šis nosaukums var iet caur nosaukumu pakalpojumu pārslēgu, caur systemd-resolved stubu vai caur atrisinātāju, ko lietojumprogramma atnesa līdzi, un katrs no tiem piemēro savu noteikumu tam pašam sufiksam. Tieši pie sufaksa noteikumi atšķiras, jo .local nav neitrāla etiķete. Noskaidrojiet, kuru ceļu neizdevusies programma patiešām iet, pirms maināt secību, kādā kaut kas darbojas.

Divi atrisinātāji, divas dažādas atbildes

Tradicionālā glibc meklēšana iet pa nsswitch.conf hosts: rindu un pēc kārtas jautā katram modulim, līdz kāds atbild. Klients, kas runā ar systemd-resolved caur stub klausītāju, tā vietā jautā vienam procesam, un šis process piemēro politiku katram savienojumam plus savus īpašos gadījumus. Lietojumprogramma, kas atnes savu atrisinātāju vai saista bibliotēku, kas to dara, var apiet abus. Tādējādi vienam resursdatora nosaukumam vienā datorā var būt trīs īpašnieki, un tikai viens no tiem zina, ko VPN bija domājis.

Pirms kaut ko mainīt, nosakiet īpašnieku, jo labojums katram no trim ir atšķirīgs. Pārlūks un komandrindas rīks tajā pašā darbvirsmā var likumīgi nebūt vienisprātis, un šī nesaskaņa ir pavediens, nevis kļūda. Ja pārlūks atrisina nosaukumu, bet rīks ne, jūs atkļūdojat atrisinātāja ceļu, nevis VPN maršrutu. Pārbaudiet maršrutu atsevišķi, lai maršrutēšanas kļūda netiktu sajaukta ar nosaukumu pakalpojuma kļūdu. Kad abi piekrīt, kļūda ir augstāk par resursdatoru, un šeit esošā atrisinātāja konfigurācija nav vērta vēl vienu labojumu.

Kura komanda patiešām jautāja jūsu atrisinātājam

Divas tikai lasīšanas komandas atbild uz saistītiem jautājumiem, un to salīdzināšana lokalizē problēmu ātrāk nekā konfigurācijas lasīšana. Izmantojiet reālu iekšējo nosaukumu un turiet izvadi privātu, jo iekšējie ieraksti paliek iekšēji. Palaidiet abas tajā pašā sesijā, kurā darbojas neizdevusies programma:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Pirmā jautā caur konfigurētajiem moduļiem, ko piedzīvo tipiska programma. Otrā jautā tieši systemd-resolved un ziņo par savienojumu, protokolu un serveri, kas atbildēja. Serverim jautāt pēc adreses pierāda tikai to, ka serverim ir ieraksts, jo tas neko nepasaka par to, vai lietojumprogramma to kādreiz jautāja. Izlasiet savienojumu, kas pārvadā VPN, un domēnus, ko tas apgalvo, pēc tam salīdziniet šo sarakstu ar sufiksu neizdevušajā nosaukumā.

Kāpēc .local izlaiž jūsu unicast zonu

systemd-resolved atsauce norāda, ka vārdi ar vairākām etiķetēm, kas beidzas ar .local, kad mDNS ir iespējots, parasti dodas uz multicast DNS, nevis parasto unicast DNS. RFC 6762 atvēl šo nosaukumu telpu link-local multicast, tāpēc uzņēmuma zona var saturēt pareizu ierakstu, par kuru šim sufiksam nekad netiek jautāts. Tunelis var nevainojami maršrutēt atrisinātāju un tomēr zaudēt sacīkstēs. Veiksmīgs ping no kešatmiņas neko nepasaka par tikko notikušo meklēšanu.

Ir dokumentēts izņēmums, un tas atrisina lielāko daļu šo gadījumu: kad savienojums deklarē šo sufiksu kā meklēšanas domēnu vai maršrutēšanas domēnu, dēmons to patur unicast ceļā un izlaiž īpašo multicast gadījumu. Tā ir politika katram savienojumam, nevis globāla izvēle. Divi datori ar vienu un to pašu VPN serveri var uzvesties atšķirīgi, ja viens tīkla profils deklarē domēnu, bet otrs ne, tāpēc lasiet aktīvo profilu, nevis to, kuru atceraties rediģējis.

Šaurais izņēmums pārspēj globālu pārkārtošanu

Esošai zonai, kuru nevarat pārdēvēt, lieciet atrisinātāja un VPN īpašniekiem deklarēt domēnu savienojumā, kas to pārvadā. Maršrutēšanas domēna ieraksts šim vienam sufiksam plus paredzētā servera adrese ir maza izmaiņa ar nosauktu īpašnieku, un tā dzīvo kopā ar savienojumu, nevis manuāli rediģētā failā.

Tā iztur arī atslēgšanos, jo savienojuma politika tiek piemērota no jauna, kad savienojums atgriežas. Koplietotā nsswitch.conf rediģēšana ir vilinošā un dārgākā alternatīva, jo tā maina meklēšanas uzvedību katram datora nosaukumam, tostarp vietējo atklāšanu. Multicast dēmona atspējošana arī nav līdzvērtīga: tā noņem vietējo uzvedību, neiemācot nevienam atrisinātājam uzņēmuma zonu. Ja pakalpojums ir jauns, nevis mantots, ievietojiet to apakšdomēnā, ko kontrolē jūsu organizācija, un pilnībā izlaidiet konkurenci. Izvēlieties šauro izņēmumu, ja nosaukums ir fiksēts aparātprogrammatūrā vai uzdrukāts uz etiķetes, un izvēlieties jaunu apakšdomēnu, ja jūs joprojām kontrolējat klientu.

Kas jāpierāda pēc izmaiņām

Pierādiet labojumu ar pašas lietojumprogrammas meklēšanu, nevis ar rīku, ko instalējāt testēšanai, un notīriet jebkuru kešatmiņu, kas varētu atbildēt tās vietā. Pēc tam apstipriniet atrisinātāja ceļu un savienojumu, kas sniedza atbildi. Visbeidzot pārbaudiet, vai vietējā atklāšana uzvedas kā pirms izmaiņām, jo printeris, kas pārstāj parādīties, ir tā daļa, ko cilvēki pamana visvēlāk. Šīs trīs komandas pārbauda nosaukumu, ceļu un TLS identitāti šādā secībā:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Pareiza adrese ar nepareizu sertifikātu joprojām liek stingram klientam neizdoties, tāpēc pārbaudiet nosaukumu, ko lietojumprogramma gaida, kad atrisināšana darbojas. Apstipriniet, ka pakalpojums pieņem savienojumus no VPN adreses, nevis tikai no biroja diapazona. Ierakstiet domēna tvērumu, serveri un īpašnieku savienojuma dokumentācijā. Pretējā gadījumā nākamais cilvēks, kas saskarsies ar šo kļūdu, ķersies pie tā paša globālā labojuma, no kura tikko izvairījāties.