La tunelo funkcias, sed kial la privata nomo ankoraŭ malsukcesas?

Ĉio pri la konekto aspektas ĝuste: la tunelo funkcias kaj la konzolo montras la privatan finpunkton, tamen ĉiu peto malsukcesas ĉe nomrezolucio. La natura movo estas kulpi la tunelon, kiu kutime montriĝas senkulpa. La demando estas sendata al servilo, kiu scias nenion pri la privata zono. Neniu enkursiga ŝanĝo ŝanĝos tiun respondon, ĉar la problemo estas, kiun oni demandis.

Kiun solvilon atingis la demando?

Trovu la solvilon ligitan al ĉiu ligilo antaŭ ol eĉ rigardi la tunelon. Linux montras servilojn po ligilo per la komando pri solvila stato, kaj macOS montras solvilojn kun amplekso en sia DNS-agorda eligo. Se la respondo ankoraŭ venas de la hejma enkursigilo, la tunela ligilo neniam estis konsultita.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Ĉi tie miksiĝas du etapoj: servilo puŝanta solvilan adreson, kaj kliento instalanta ĝin sur la aktiva ligilo. Profilo povas enhavi la opcion, kaj protokolo povas montri ĝin alvenanta, dum la operaciumo daŭre uzas la malnovan servilon. Komparu la protokolon kun tio, kion la ligilo raportas, kaj fidu la ligilon.

Uzu adreson, al kiu la nuba reto vere respondas

Nubaj retoj kutime respondas al privataj nomoj per rezervita adreso du poziciojn for de la bazo de la gamo, do reto komenciĝanta ĉe 10.0.0.0 respondas ĉe 10.0.0.2. Iuj provizantoj ankaŭ publikigas link-local solvilon, kiu funkcias sen koni la gamon, kio helpas kiam la reton konstruis iu alia. Demandu la kandidatan adreson rekte antaŭ ol puŝi ĝin al iu ajn. Adreso, kiu ne estas solvilo, aspektas ĝuste kiel fajroŝirmila forĵeto, ĉar la demando simple neniam ricevas respondon.

Se la rekta demando respondas de interne de la reto sed ne trans la tunelo, la solvilo estas bona kaj la vojo inter la du punktoj ne. Tiu rezulto movas la esploron al enkursigoj, plusendo kaj aliraj reguloj anstataŭ al la klienta profilo.

Tunelo ne portas la nomspacon

Paketoj transiras; nomoj ne. Oni devas diri al ĉiu flanko, kiu nomspaco apartenas al la alia, kaj tio estas aparta objekto posedata de tiu, kiu tenas la zonon. La kutima formo estas plusendo por unu nomspaco, direktita al solvilo atingebla trans la tunelo.

En praktiko ĉiu direkto bezonas sian propran regulon, ĉar la flanko, kiu posedas la zonon, devas plusendi la demandon. Ambaŭ direktoj bezonas, ke la fonto de la demando estu enkursigita kaj permesita, kaj la responda flanko devas redoni respondojn tra la tunelo anstataŭ al la interreto. Tenu la plusendon mallarĝa, tiel ke nur la privata nomspaco dependas de la ligilo. Sendi ĉiun demandon tra ĝi ŝanĝas malgrandan dependecon en totalan ĉesigon en la momento, kiam la tunelo falas.

Trairu la limojn laŭ ordo

Testu la solvilon instalitan sur la aktiva ligilo, poste rektan demandon al tiu solvilo, poste la saman demandon de la malproksima flanko, kaj finfine la aplikaĵon uzantan la saman nomon. Ĉiu paŝo izolas unu limon, do malsukceso diras al vi, kie rigardi, anstataŭ rekomenci la esploron. Respondo, kiu funkcias dum la aplikaĵo malsukcesas, indikas atestilan fidon aŭ API-politikon anstataŭ DNS. Tiuj difektoj estas realaj, kaj neniu solvila ŝanĝo riparos ilin.

Notu, kiu paŝo malsukcesis. Tiu unu linio estas tio, kion la sekva persono bezonas, kaj registri ĝin daŭras dek sekundojn.

Tenu la ĉenon tie, kie la sekva persono povas trovi ĝin

Registru la puŝitan solvilon, la plusendan regulon, la permesitan demandofonton kaj la respondan finpunkton en unu loko. Kiam la privata nomo denove malsukcesos, la registro montros, ĉu la tunelo moviĝis, la solvila adreso ŝanĝiĝis, aŭ regulo mallarĝiĝis. Sen ĝi, ĉiu incidento komenciĝas de nulo kaj finiĝas per la samaj tri konjektoj.

Tenu la registron sufiĉe mallongan por resti preciza: kvar linioj, dato, kaj la nomo de tiu, kiu posedas ĉiun parton. Malnova registro estas pli malbona ol neniu, ĉar ĝi aspektas aŭtoritata dum ĝi malĝustas.