VPN-DNS funkcias, sed .local-nomoj ankoraŭ malsukcesas: kiu solvas ilin?

Du maŝinoj en la sama VPN, sama hostnomo, kaj nur unu el ili solvas ĝin: la diferenco kutime ne estas la tunelo sed kiu solvilo respondis. Sur Linux-labortablo tiu nomo povas vojaĝi tra la nomserva ŝaltilo, tra la stub de systemd-resolved, aŭ tra solvilo, kiun la aplikaĵo kunportis, kaj ĉiu el ili aplikas sian propran regulon al la sama sufikso. Ĝuste ĉe la sufikso la reguloj malkongruas, ĉar .local ne estas neŭtrala etikedo. Eltrovu, kiun vojon la malsukcesanta programo efektive prenas, antaŭ ol vi ŝanĝas la ordon en kiu io ajn ruliĝas.

Du solviloj, du malsamaj respondoj

Tradicia glibc-serĉo trapasas la linion hosts: en nsswitch.conf kaj demandas ĉiun modulon laŭvice ĝis unu respondas. Kliento, kiu parolas al systemd-resolved tra la stub-auskultanto, demandas anstataŭe unu solan procezon, kaj tiu procezo aplikas politikon laŭ ligo plus siajn proprajn specialajn kazojn. Aplikaĵo, kiu kunportas sian propran solvilon aŭ ligas bibliotekon kiu faras tion, povas preterpasi ambaŭ. Unu hostnomo do povas havi tri posedantojn sur unu maŝino, kaj nur unu el ili scias, kion la VPN intencis.

Identigu la posedanton antaŭ ol ŝanĝi ion ajn, ĉar la riparo malsamas por ĉiu el la tri. Retumilo kaj komandlinia ilo sur la sama labortablo povas laŭleĝe malkonsenti, kaj tiu malkonsento estas la postsigno, ne la cimo. Se la retumilo solvas la nomon kaj la ilo ne, vi sencimigas solvilan vojon kaj ne VPN-vojon. Konfirmu la vojon aparte, por ke vojiga fuŝo ne estu konfuzita kun nomserva fuŝo. Kiam ambaŭ konsentas, la fuŝo estas supre de la gastiganto, kaj la solvila agordo ĉi tie ne indas plian redakton.

Kiun komandon efektive demandis via solvilo

Du nurlegaj komandoj respondas rilatajn demandojn, kaj kompari ilin lokalizas la problemon pli rapide ol legi agordon. Uzu veran internan nomon kaj tenu la eligon privata, ĉar internaj rikordoj restas internaj. Rulu ambaŭ en la sama sesio, en kiu ruliĝas la malsukcesanta programo:

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

La unua demandas tra la agorditaj moduloj, kion travivas tipa programo. La dua demandas rekte systemd-resolved kaj raportas la ligon, la protokolon kaj la servilon, kiu respondis. Demandi la firmaan servilon laŭ adreso pruvas nur, ke la servilo tenas la rikordon, ĉar ĝi diras nenion pri tio, ĉu la aplikaĵo iam demandis ĝin. Legu la ligon, kiu portas la VPN, kaj la domajnojn, kiujn ĝi pretendas, poste komparu tiun liston kun la sufikso en la malsukcesanta nomo.

Kial .local preterpasas vian unicast-zonon

la referenco de systemd-resolved deklaras, ke pluretiĝetaj nomoj finiĝantaj per .local kutime iras al multicast-DNS kiam mDNS estas ŝaltita, anstataŭ al ordinara unicast-DNS. RFC 6762 apartigas tiun nomspacon por link-local multicast, do firmaa zono povas teni korektan rikordon, pri kiu oni neniam demandas por tiu sufikso. La tunelo povas vojigi la solvilon perfekte kaj tamen perdi la konkurson. Sukcesa ping el kaŝmemoro diras nenion pri la serĉo, kiu ĵus okazis.

Ekzistas dokumentita escepto, kaj ĝi solvas la plej multajn el tiuj kazoj: kiam ligo deklaras tiun sufikson kiel serĉdomajnon aŭ vojigan domajnon, la demono tenas ĝin sur la unicast-vojo kaj preterpasas la specialan multicast-kazon. Tio estas politiko laŭ ligo, ne tutmonda prefero. Du maŝinoj kun la sama VPN-servilo povas konduti malsame, kiam unu retprofila deklaras la domajnon kaj la alia ne, do legu la aktivan profilon anstataŭ la profilon, kiun vi memoras redakti.

La mallarĝa escepto venkas tutmondan reordigon

Por ekzistanta zono, kiun vi ne povas renomi, igru la posedantojn de la solvilo kaj de la VPN deklari la domajnon sur la konekto, kiu portas ĝin. Vojiga domajna ero por tiu unu sufikso plus la celata servila adreso estas malgranda ŝanĝo kun nomita posedanto, kaj ĝi vivas kun la ligo anstataŭ en permane redaktita dosiero.

Ĝi ankaŭ postvivas malkonekton, ĉar la liga politiko reaplikatas kiam la ligo revenas. Redakti la komunan nsswitch.conf estas la tentiga kaj la pli multekosta alternativo, ĉar ĝi ŝanĝas serĉan konduton por ĉiu nomo sur la maŝino, inkluzive de loka malkovro. Malebligi la multicast-demonon ankaŭ ne estas ekvivalenta: ĝi forigas la lokan konduton sen instrui al iu ajn solvilo la firmaan zonon. Se la servo estas nova anstataŭ heredita, metu ĝin sub subdomajnon, kiun via organizo kontrolas, kaj tute preterpasu la konkurson. Elektu la mallarĝan escepton, kiam la nomo estas fiksita en firmvaro aŭ presita sur etikedo, kaj elektu novan subdomajnon, kiam vi ankoraŭ kontrolas la klienton.

Kion pruvi post la ŝanĝo

Pruvu la riparadon per la propra serĉo de la aplikaĵo, ne per ilo, kiun vi instalas por testi, kaj malplenigu ajnan kaŝmemoron, kiu povus respondi anstataŭ ĝi. Poste konfirmu la solvilan vojon kaj la ligon, kiu donis la respondon. Fine kontrolu, ke loka malkovro ankoraŭ kondutas kiel antaŭ la ŝanĝo, ĉar la presilo, kiu ĉesas aperi, estas la parto, kiun homoj rimarkas laste. Ĉi tiuj tri komandoj kontrolas la nomon, la vojon kaj la TLS-identon en tiu ordo:

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

Ĝusta adreso kun la malĝusta atestilo ankoraŭ malsukcesigas striktan klienton, do kontrolu la nomon, kiun la aplikaĵo atendas, post kiam la solvado funkcias. Konfirmu, ke la servo akceptas konektojn de la VPN-adreso kaj ne nur el la oficeja gamo. Skribu la domajnan amplekson, la servilon kaj la posedanton en la dokumentaron de la konekto. Alie la sekva persono, kiu renkontos ĉi tiun fuŝon, atingos la saman tutmondan redakton, kiun vi ĵus evitis.