VPN-DNS-raporto: kion enhavi por ke ĝi estu reproduktebla

„DNS estas rompita“ estas konkludo, kaj ĝi ne estas tia, pri kiu helpanto povas agi. La utila parto de raporto estas la formo de la fiasko: kiu nomo, per kiu resolvilo, kun kiu respondo. Tri detaloj igas plendon reproduktebla, kaj ĉiuj tri estas sekuraj por dividi post kiam la privataj partoj estas renomitaj. La sekvaĵo estas la minimumo, kiun VPN-DNS-raporto bezonas antaŭ ol iu povas helpi.

Kategorio de nomo, ne verdikto

Komencu per la nomo mem kaj klasifiku ĝin: publika, interna, mallonga, plene kvalifikita aŭ servata de unu specifa sufikso. Interna nomo, kiu fiaskas dum publikaj nomoj solviĝas, montras al elekto de resolvilo anstataŭ al atingeblo. Se ĉiuj nomoj fiaskas, tio montras al la vojo al la resolvilo, kio estas alia esploro kun aliaj pruvoj. La kategorio portas la diagnozon, kaj la preciza signoĉeno povas esti kaŝita.

Diru, ĉu la fiasko bezonas la tunelon malfermita aŭ okazas post ĝia malkonekto. Nomo, kiu rompiĝas nur dum la VPN estas aktiva, implicas la agordon por ĉiu ligilo, dum tiu, kiu rompiĝas post malkonekto, implicas restantan staton. Raportoj kutime forlasas tion kaj poste demandas, kial la unua sugesto ne helpas.

Registru la resolvan vojon

Demando sendita al eksplicite elektita servilo kaj la ordinara serĉo de aplikaĵo estas malsamaj eksperimentoj. Diru, kiu el ili produktis la fiaskon, ĉar permana demando al funkcianta servilo pruvas nur, ke la servilo funkcias. La subaj komandoj apartigas la sistemvojon de rekta demando.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

La statusa eligo nomas la servilojn por ĉiu ligilo kaj la enkursigajn domajnojn, kio estas kie oni decidas pri split DNS. La alvoko getent sekvas la saman vojon kiel la aplikaĵo, inkluzive de la ordo nsswitch. La rekta demando preterpasas ambaŭ kaj testas unu servilon izolite. Raportu, kiu el la tri fiaskis kaj kiu sukcesis, kaj la leganto ne plu devas diveni la vojon.

Indiku la kontrolitan komparon

Ŝanĝu unu variablon kaj diru, kio ŝanĝiĝis. Ke publikaj nomoj solviĝas dum internaj fiaskas estas elekta problemo; ke ĉiu nomo finiĝas per tempolimo estas voja problemo; kaj privata nomo, kiu solviĝas al publika adreso, estas liko en la malĝustan resolvilon. Du el tiuj tri havas nenion komunan kun tio, ĉu la tunelo estas malfermita. Raporto, kiu asertas, ke ĉiuj demandoj estas rompitaj, kutime enhavas komparon, kiu neniam estis farita.

Apartigu solvadon de liverado. Kiam la nomo solviĝas kaj la retejo ankoraŭ fiaskas, la DNS-etapo sukcesis kaj la raporto devus tion diri, ĉar la sekva paŝo estas vojo aŭ aŭskultanto, ne resolvilo. Tiu unu distingo ŝparas pli ofte tutan demandrondon ol iu ajn protokolero.

Kaŝu la nomspacon, konservu la rilatojn

Internaj nomoj povas esti anstataŭigitaj, kondiĉe ke la anstataŭoj konservas la strukturon. Mapu ĉiun apartan servilon kaj sufikson al stabila etikedo, kaj tenu tiun mapon ekster la dividita kopio. Anstataŭigi ĉiun internan gastiganton per la sama lokokupilo detruas ĝuste la pruvon, kiun la raporto bezonas, ĉar la leganto ne plu povas vidi, ke unu sufikso solviĝis kaj alia ne. La sama regulo validas por adresoj: konservu la rilatojn de prefiksoj kaj ŝanĝu la bitojn de la gastiganto, se politiko tion postulas.

Sendu la rikordon per la kontrolita kanalo kaj lasu ekstere tion, kion la diagnozo neniam bezonas. Pasvortoj, privataj ŝlosiloj kaj nerilataj kompaniaj nomoj ne estas parto de DNS-demando. Kion la leganto bezonas, estas la fiaskokategorio, la resolva vojo, la preciza eraro kaj la unu komparo, kiun vi faris.