Pam mae resolv.conf yn dangos DNS eich VPN ond mae chwiliadau'n ei anwybyddu

Nid oes dim yn y cofnodion yn edrych yn anghywir: mae'r rhyngwyneb i fyny, mae'r datryswr yn adrodd gweinydd DNS y VPN, ac mae'r ffeil ar y disg yn ei restru. Eto i gyd mae enw gwesteiwr mewnol yn dal i gael ei ddatrys trwy'r llwybrydd lleol. Nid yw'r tri datganiad yn gwrthddweud ei gilydd, oherwydd mae'r ffeil, cyflwr pob cysylltiad a llwybr y chwiliad yn wahanol wrthrychau sy'n digwydd rhannu enw. Dyma'r llwybr y mae ymholiad yn ei gymryd mewn gwirionedd ar westeiwr systemd-resolved.

Tri gwrthrych o'r enw resolv.conf

Ar westeiwr gyda resolved, cyswllt symbolaidd i /run/systemd/resolve/stub-resolv.conf yw /etc/resolv.conf fel arfer. Mae'r targed hwnnw'n dal cyfeiriad gwrandawr stub lleol, 127.0.0.53, ynghyd â'r parthau chwilio a gyfrifodd resolved. Golygfa o'r cyflwr yw hi, nid y cyflwr ei hun.

Mae'r cyflwr yn byw yng nghyfluniad resolved fesul cysylltiad, a dyna pam y gall resolvectl status anghytuno â'r ffeil a bod yn gywir o hyd. Mae pob cysylltiad yn cario ei weinyddwyr ei hun a'i barthau llwybro ei hun, ac mae'r stub yn ymgynghori â'r data hwnnw pan ddaw ymholiad i mewn. Mae llawlyfr systemd-resolved yn disgrifio'r ffeiliau a gynhyrchir a'r model fesul cysylltiad; y rhaniad rhwng golygfa a chyflwr yw'r rhan sy'n werth ei chadw. Mae newid targed y cyswllt symbolaidd yn newid yr hyn y mae cleientiaid traddodiadol yn ei ddarllen, nid yr hyn y mae'r datryswr yn ei wybod.

Mae trydydd gwrthrych, /run/systemd/resolve/resolv.conf, yn gwastatáu pob cysylltiad yn un rhestr o weinyddwyr. Mae rhaglen sy'n pwyntio at y ffeil honno'n anfon ymholiadau'n syth at y gweinyddwyr a restriwyd ac yn sgipio'r stub, felly nid yw polisi fesul cysylltiad yn berthnasol iddi mwyach. Gall dwy raglen ar yr un peiriant ateb yr un enw'n wahanol felly, ac nid oes yr un ohonynt wedi torri.

Olrheiniwch un chwiliad drwy NSS

Mae glibc yn darllen /etc/nsswitch.conf i benderfynu pwy sy'n ateb enw. Mae llinell hosts sy'n cynnwys resolve yn cyfeirio'r cwestiwn at nss-resolve, sy'n gofyn i resolved dros D-Bus ac yn cael yr ateb fesul cysylltiad. Mae llinell sydd â files dns yn unig yn anfon yr ymholiad at ba bynnag gyfeiriad y mae /etc/resolv.conf yn ei ddal.

Mae'r un llinell honno'n esbonio'r rhan fwyaf o'r anghytundebau rhwng porwr a dig. Mae dig yn darllen resolv.conf yn uniongyrchol ac yn byth yn cyffwrdd NSS, felly mae'n profi'r stub neu weinydd uwchraddol yn hytrach na'r llwybr y mae'r rhaglen yn ei ddefnyddio. Mae getent hosts internal.example yn mynd drwy NSS, a chymharu ei ateb ag ateb dig yw'r mesuriad defnyddiol cyntaf.

Mae rhaglenni sy'n ymgorffori datryswr, neu'n siarad DNS dros HTTPS ag ateb penodol, yn osgoi'r ddau lwybr. Nid oes dim yn resolv.conf nac yng nghyflwr resolved yn eu cyfyngu.

Gwiriwch pwy sy'n berchen ar y ffeil ac i ble mae'n pwyntio

Darllenwch y gadwyn gysylltau cyn newid unrhyw beth, oherwydd perchnogaeth sy'n penderfynu pa ffeil sy'n awdurdodol. Dim ond darllen cyflwr y mae pob gorchymyn isod yn ei wneud.

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

Mae'r llinell gyntaf yn argraffu'r cyswllt a'i darged gyda'i gilydd, ac mae ffeil gyffredin sy'n eiddo i sgript VPN yn golygu nad yw'r datryswr byth yn trin yr ysgrifiad hwnnw fel mewnbwn. Mae allbwn statws yn rhestru gweinyddwyr fesul cysylltiad ynghyd â'r parthau llwybro sy'n penderfynu i ble mae pob ymholiad yn mynd. Mae'r llinell nsswitch yn dweud a yw'r stub yn cael ei ymgynghori o gwbl, felly mae cyfeiriad stub yn y ffeil heb resolve yno yn golygu bod ymholiadau'n cyrraedd y gwrandawr lleol tra nad oes dim yn rheoli'r rhaniad. Mae'r rhestr olaf honno'n bwysig hefyd, oherwydd nid yw gwesteiwr heb stub-resolv.conf yn rhedeg y trefniant a ddisgrifir yma.

Os yw'r gadwyn yn gorffen mewn ffeil y mae pecyn arall yn ei rheoli, y cleient VPN a'r pecyn hwnnw yw'r ddau berchennog sydd i'w cysoni. Mae disodli'r cyswllt yn taflu gwaith un perchennog ac yn gadael gwaith y llall yn ei le.

Trwsio gyda pherchennog y cyswllt

Dylai cysylltiad VPN gofrestru ei weinyddwyr a'i barthau ar ei gyswllt ei hun, yna eu tynnu'n ôl wrth ddatgysylltu. Mae integreiddiad resolved NetworkManager a chynorthwyydd y cleient ei hun yn gweithio felly; nid yw sgript sy'n ailysgrifennu resolv.conf yn unig yn gwneud hynny.

Ar gyswllt sy'n bodoli eisoes, mae gosodiadau amser rhedeg yn dangos y mecanwaith. Mae resolvectl dns tun0 10.40.0.53 yn atodi gweinydd, ac mae resolvectl domain tun0 '~corp.example' yn atodi parth llwybro. Y tilde yw'r nod sy'n cario'r baich: mae'n cyfyngu ymholiadau ar gyfer yr olddodiad hwnnw i'r cyswllt hwn ac yn gadael popeth arall yn llonydd, tra bod yr un gwerth hebddi'n dod yn barth chwilio ac mae'r rhaniad yn anweddu. Enghreifftiau labordy yw'r cyfeiriadau hynny, nid cyfluniad parhaus. Cadarnhewch gyda resolvectl query host.corp.example a darllenwch pa gyswllt a atebodd.

Mae gweinydd cofrestredig yn dal i fod angen llwybr. Pan fydd yr ymholiad yn cyrraedd y cyswllt cywir ac yn goramseru, y diffyg yw cyrhaeddedd drwy'r twnnel yn hytrach na pherchnogaeth y datryswr.

Sut mae cyflwr gweithio yn edrych

Mae canlyniad iach yn gyson ar draws y tair golygfa: mae gweinyddwyr fesul cysylltiad yn cyfateb i'r hyn a roddodd y VPN, dim ond olddodiadau mewnol y mae'r parthau llwybro yn eu gorchuddio, ac mae'r rhaglen sy'n bwysig yn datrys enw mewnol tra bod enw cyhoeddus yn dal i ddilyn y llwybr lleol. Mae un ymholiad llwyddiannus yn profi llai na'r cytundeb hwnnw.

Yna datgysylltwch ac ailadroddwch y ddau ymholiad. Mae cleient sy'n gadael ei barthau wedi'u cofrestru ar ôl dadadeiladu yn cynhyrchu peiriant sy'n methu chwiliadau mewnol oriau'n ddiweddarach, heb dwnnel agored a heb achos amlwg.