VPN-DNS-rapport: kva som må vera med for at det skal kunne gjentakast

«DNS er øydelagt» er ein konklusjon, og det er ikkje ein konklusjon ein hjelpar kan handle ut frå. Den brukbare delen av ein rapport er forma på feilen: kva namn, gjennom kva resolver, med kva svar. Tre detaljar gjer ei klage reproduserbar, og alle tre er trygge å dele når dei private delane er døypte om. Det følgjande er minimumet ein VPN-DNS-rapport treng før nokon kan hjelpe.

Ein kategori av namn, ikkje ein dom

Byrja med sjølve namnet og klassifiser det: offentleg, internt, kort, fullt kvalifisert eller tent av eitt bestemt suffiks. Eit internt namn som feilar medan offentlege namn blir løyste, peikar på val av resolver og ikkje på tilgjenge. Viss alle namn feilar, peikar det på stien til resolveren, og det er ei anna undersøking med andre bevis. Kategorien ber diagnosen, og den eksakte strengen kan skjulast.

Sei om feilen krev at tunnelen er oppe, eller om han skjer etter at han blir kopla frå. Eit namn som berre bryt medan VPN er aktivt, impliserer konfigurasjonen per lenke, medan eit som bryt etter fråkopling, impliserer attverande tilstand. Rapportar utelèt ofte dette og lurer deretter på kvifor det første forslaget ikkje hjelper.

Noter resolverstien

Ei førespurnad send til ein eksplisitt vald tenar og eit programs vanlege oppslag er ulike eksperiment. Sei kva for ein som gav feilen, fordi ei manuell førespurnad til ein fungerande tenar berre beviser at tenaren fungerer. Kommandoane nedanfor skil systemstien frå eit direkte spørsmål.

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

Statusutdata nemner tenarane per lenke og rutedomena, altså der split DNS blir avgjort. getent-kallet følgjer same stien som programmet, inkludert nsswitch-rekkjefølgja. Den direkte førespurnaden omgår begge og testar éin tenar isolert. Rapporter kven av dei tre som feila og kven som lukkast, og lesaren slepp å gjette på stien.

Oppgi den kontrollerte samanlikninga

Endre éin variabel og sei kva som endra seg. At offentlege namn blir løyste medan interne feilar, er eit valproblem; at kvart namn går i timeout, er eit stiproblem; og eit privat namn som blir løyst til ei offentleg adresse, er ein lekkasje til feil resolver. To av desse tre har ingenting å gjere med om tunnelen er oppe. Ein rapport som hevdar at alle førespurnader er øydelagde, inneheld vanlegvis ei samanlikning som aldri vart køyrd.

Skil oppløysing frå levering. Når namnet blir løyst og nettstaden likevel feilar, lukkast DNS-trinnet, og rapporten bør seie det, fordi neste steg er ei rute eller ein lyttar og ikkje ein resolver. Den eine skilnaden sparer oftare ein runde med spørsmål enn noko loggutdrag.

Skjul namnerommet, hald på relasjonane

Interne namn kan erstattast så lenge erstatningane bevarar strukturen. Knyt kvar einskild tenar og kvart suffiks til ei stabil etikett, og hald den koplinga utanfor den delte kopien. Å erstatte kvar intern vert med same plasshaldar øydelegg nettopp beviset rapporten treng, fordi lesaren ikkje lenger kan sjå at eitt suffiks vart løyst og eit anna ikkje. Same regel gjeld adresser: hald på prefiksrelasjonane og endre vertsbitane viss policyen krev det.

Send posten gjennom den verifiserte kanalen og utelat det diagnosen aldri treng. Passord, private nøklar og urelaterte firmanamn er ikkje del av eit DNS-spørsmål. Det lesaren treng, er feilkategorien, resolverstien, den eksakte feilen og den eine samanlikninga du køyrde.