OpenVPN sendi DNS-þjón, en Linux hunsar hann

Sendi DNS-þjónninn er í annálnum, göngin eru uppi og innri nöfn mistakast enn. Ekkert er bilað í sendingunni sjálfri; stillingin kom og stöðvaðist þar. Send DNS-valkostur er skilaboð til biðlarans, ekki fyrirmæli til resolver kerfisins, og afhendingin þar á milli er þar sem flest þessara tilvika enda. Fimm athuganir, í röð, finna afhendinguna sem átti sér ekki stað.

Athugun eitt: hvernig tengingin hefst

Eigandi tengingarinnar ákvarðar hver getur beitt stillingum resolversins. Bein openvpn-skipun úr skel á ekki annað en sitt eigið ferli, en systemd-eining, NetworkManager eða biðlari frá seljanda hefur hvert sína leið til að birta DNS. Lestu ferlalistann og nafn einingarinnar áður en þú gerir ráð fyrir einhverju þeirra.

Ferli skipanalínunnar er ekki sjálfkrafa NetworkManager-tenging, og NetworkManager-tenging er ekki sjálfkrafa það sem skrifaði resolv.conf. Þessar tvær forsendur skýra stærstan hluta þeirra klukkustunda sem eyðilagðar voru í þessari rannsókn. Spurðu hvaða hluti myndi birta DNS fyrir viðmótið sem þú sérð í raun.

Skrifaðu eigandann niður áður en þú heldur áfram. Hver síðari athugun er háð honum.

Athugun tvö: hvað resolver-hlekkurinn heldur í raun

Á systemd-resolved hýsli listar resolvectl status hvern hlekk með DNS-þjónum og léndum hans. Finndu hlekk ganganna og lestu færslurnar, og gerðu ekki ráð fyrir að viðmótið heiti tun0, því númeraröð fylgir röð sköpunar. Ef senda vistfangið vantar í hlekkinn þá brást afhendingin, ekki fyrirspurnin.

Ef vistfangið er til staðar er næsta spurning hvaða lénd hlekkurinn gerir tilkall til. Hlekkur án léndalistans svarar aðeins nöfnum sem spurt er beint um, og það er sjaldan það sem split-DNS uppsetning vill. Vistfangið eitt er nauðsynlegt en ekki nægilegt.

Berðu saman nafn hlekksins í úttaki resolversins við nafn viðmótsins í VPN-annálnum áður en þú dregur nokkra ályktun. Misræmi þar þýðir venjulega að annálslínan kom frá öðru ferli.

Athugun þrjú: hvort nafnrýmið velur þann hlekk

Resolver getur haldið rétta þjóninum og samt ekki verið spurður. Léndið á hvern hlekk ákvarðar hverjar fyrirspurnir fara á hvaða hlekk, og án beiningaléndar fellur einkanafnrýmið aftur á það sem sjálfgefni hlekkurinn segir. Þess vegna getur resolvectl query fyrir innra nafnið heppnast á meðan forrit mistekst enn. Forritið gæti verið að nota allt aðra resolver-slóð.

Athugaðu léndauppskiptinguna, ekki bara vistfang þjónsins. Lénd skrifað sem ~corp.example er beiningalénd, og tildan breytir því hvernig nafnið er parað.

Ef forritið hefur sinn eigin resolver, prófaðu með sama fyrirkomulagi og það notar frekar en kerfisverkfærinu. Fyrirspurnarverkfæri sem fer fram hjá resolver kerfisins mun heppnast óháð ástandi hlekksins.

Athugun fjögur: einn eigandi, ekki tveir

Ef NetworkManager stýrir þegar VPN-inu og ástandi resolversins, þá skapar það keppinauta ef ótengdum krókaskrift er bætt við. Krókurinn sem pakkinn býður fyrir systemd-resolved er studd samþætting og býst við ákveðnum lífsferli: script-security 2, slóð up, up-restart, slóð down og down-pre. Þessir valkostir láta skráningu og fjarlægingu eiga sér stað á réttum augnablikum en ekki aðeins við fyrstu tengingu.

Notaðu uppsettu slóðina úr pakkanum frekar en skýringarmynd úr leiðarvísi. Heimildir skipta líka máli, því krókurinn keyrir eftir að heimildir lækka.

Að breyta resolver-skrift dreifingarinnar til að færa úttakssviðið skráir hjáleið fyrir eitt hýsil. Það er ekki almenn viðgerð.

Athugun fimm: sama niðurstaða eftir endurtengingu

Tengdu aftur og lestu hlekkinn aftur. Skráning sem birtist einu sinni og hverfur við næstu umskipti er bilunin sem allur þessi gátlisti er til fyrir. Prófaðu eftir svefn, eftir þvingaða endurtengingu og eftir endurræsingu resolver-þjónustunnar. Hver umskipti prófa aðra forsendu um röð.

Aðeins þegar allar fimm athuganir standast við endurtengingu geturðu sagt að sendu stillingarnar séu í notkun. Allt fyrr er skyndimynd af heppilegu augnabliki.