Via VPN-domajno en dnsmasq ne estas zontransigo

Vi serĉas la entreprenan zonon en la dnsmasq-agordo de la kliento, ne trovas ĝin kaj konkludas, ke la VPN ne puŝis sian domajnon. Tio, kio estis puŝita, estas vojiga indiko, ne zono. La kliento registras la domajnon kaj la solvilon, kiu devus respondi pri ĝi, kaj la administrata backend transformas tion en kondiĉan plusendadon. Serĉi en la malĝusta loko donas memfidan kaj tute falsan diagnozon.

Tio, kion la kliento akceptis, ne estas tio, kion la pordego proponis

Pordego povas proponi solvilon, domajnon kaj la itineron necesan por atingi tiun solvilon, kaj la kliento povas akcepti ĉiujn tri aŭ neniun el ili. Importita profilo, helposkripto aŭ politiko, kiu ignoras puŝitajn agordojn, povas lasi la akceptitan aron malplena dum la servila flanko aspektas ĝuste. Komencu per la registrita stato de la kliento anstataŭ per la servila agordo, ĉar tiu stato estas tio, kion la solvilo efektive ricevas. Se la akceptita domajno mankas, nenio plu gravas. Kontrolu la DNS-ecojn de la konekto antaŭ ol ekzameni ajnan kaŝmemoron.

Tiu distingo klarigas plej multajn raportojn pri domajno, kiu neniam alvenis. Ĝi estis proponita, kaj ĝi ne estis aplikita.

Du specoj de domajnaj enskriboj

Konekto povas porti ordinarajn serĉdomajnojn kaj nur-vojigajn domajnojn, kaj la dua speco komenciĝas per tildo. Serĉdomajno kaj direktas demandojn kaj ebligas vastigi mallongajn nomojn, kio estas oportuna sur labortablo kaj surpriza sur servilo. Nur-vojiga domajno diras, ke demandoj por tiu sufikso devas iri al specifaj serviloj sen ŝanĝi kiel solviĝas mallongaj nomoj. Verki la saman domajnon ambaŭmaniere ne estas redundo, ĉar la du enskriboj faras malsamajn taskojn.

Por privata nomspaco la nur-vojiga formo kutime estas tiu, kiun vi volas. Ĝi tenas la entreprenan sufikson direktita al la entreprena solvilo kaj lasas ĉion alian trankvila.

localhost en resolv.conf ne estas cimo

Kiam oni uzas lokan kaŝmemoran solvilon, la sistema dosiero montras al la loopback-adreso kaj nenio pli. Tiu enskribo identigas la lokan aŭskultanton, ne la suprajn servilojn, kiujn la administranto donis al ĝi. La entreprena adreso rajte mankos en la dosiero.

Anstataŭigi tiun enskribon per publika solvilo estas la klasika malĝusta riparo. Ĝi restarigas publikan nomosolvadon kaj forĵetas la kondiĉan politikon en la sama redakto.

Ne konfuzu la backend-ojn

Administrata dnsmasq-agordo kaj sistema solvilo estas malsamaj programoj kun malsama agordo kaj malsamaj statvidoj. Statkomando por unu diras nenion utilan pri la alia.

Determinu, kiun backend la administranto estas agordita uzi, poste legu la generitan agordon de tiu backend anstataŭ tutdistribuan dosieron, kiu hazarde ekzistas. La administranto skribas sian propran agordon de la agordo kaj subtenas proprajn opciojn por tiu agordo, do redakti nerilatan globalan dosieron ŝanĝas nenion kaj aspektas kiel ŝanĝo sen efekto. Lanĉi duan demonon en haveno 53 estas pli malbona ol senutila, ĉar nun du programoj malkonsentas pri tio, al kiu apartenas la haveno. Unue establu la posedanton, poste redaktu tie, kie tiu posedanto legas.

Testu la nomspacon, ne nur la respondon

Demandu unu permesitan privatan nomon kaj unu publikan kontrolnomon tra la normala vojo de la aplikaĵo. Rekta demando al la entreprena servilo pruvas, ke la rikordo ekzistas; ĝi ne pruvas, ke la kliento elektis tiun servilon. La dua demando estas tiu, kiu testas la politikon.

Poste ripetu post rekonekto kaj post malkonekto. La asociiĝo devus sekvi la vivciklon de la konekto, kaj la privataj nomoj devus ĉesi solviĝi, kiam la tunelo malaperas, anstataŭ ree fali sur publikan solvilon, kiu respondas por la sama sufikso. Se ili tamen ree falas, vi trovis likon, kio estas malsama difekto ol rompita serĉo. Notu, kiu backend funkciis, kiuj domajnoj estis aplikitaj kaj kion ĉiu demando resendis.