Pam mae enwau gwesteiwyr mewnol yn datrys gyda dig ond yn methu gyda curl ar VPN

Mae eich gliniadur ar y VPN, mae dig service.internal.example yn ateb gyda chyfeiriad 10.x, ac mae curl yn dal i orffen gyda Could not resolve host. Nid y twmnel yw’r broblem: cludodd y cwestiwn dig heb gwyno. Y gwahaniaeth yw pwy sy’n gofyn y cwestiwn. Mae dig yn anfon un cwestiwn at un gweinydd a enwyd gennych, tra bo curl yn mynd trwy gadwyn chwilio’r system weithredu, ac mae gan y gadwyn honno ei rheolau ei hun ynglŷn â pha weinydd y gofynnir iddo.

Dwy chwiliad am yr un enw

Mae dig yn stub resolver ei hun. Mae’n darllen /etc/resolv.conf, yn dewis enweirydd, yn anfon un cwestiwn A neu AAAA ac yn argraffu’r ateb. Mae’n hepgor nsswitch yn gyfan gwbl ac nid yw’n gwybod dim am y cyflwr fesul cysylltiad y mae systemd-resolved neu NetworkManager yn ei gadw y tu allan i’r ffeil honno, a dyna pam y gall ateb dig fod yn gywir ac eto heb ddweud dim wrthych am yr hyn y bydd eich cymhwysiad yn ei weld.

Mae cymwysiadau’n galw getaddrinfo, ac mae getaddrinfo yn cerdded cadwyn hirach: trefn modiwlau nsswitch, yna’r modiwl sy’n trin yr enw, ac yna’r resolver a adeiledir o’r ffurfweddiad cysylltiad cyfredol. Ar beiriant systemd mae’r cwestiwn yn mynd i 127.0.0.53 ac mae systemd-resolved yn dewis gweinydd uwchrif fesul cysylltiad yn seiliedig ar y parth llwybro sydd ynghlwm wrth y rhyngwyneb tun.

Mae dau orchymyn yn gwahanu’r haenau hynny heb ddyfalu:

getent ahosts service.internal.example
resolvectl query service.internal.example

Mae getent yn defnyddio’r un llwybr â curl, felly mae methiant getent wrth ymyl dig sy’n gweithio yn lleoli’r diffyg yn y polisi chwilio yn hytrach nag yn llwybro pecynnau. Mae resolvectl query hefyd yn argraffu’r rhyngwyneb a’r uwchrif a roddodd yr ateb, sy’n dangos a enillodd cysylltiad y twmnel neu’r cysylltiad ffisegol y penderfyniad.

Darllenwch y resolver y mae’r cymhwysiad yn ei ddefnyddio mewn gwirionedd

Mae /etc/resolv.conf yn cael ei gynhyrchu ar y rhan fwyaf o loriau gwaith, ac mae gan gleient VPN dri ffordd o ryngweithio ag ef: rhoi enweirydd ar y blaen, trosysgrifo’r ffeil, neu drosglwyddo ei weinyddion i NetworkManager a gadael i’r daemon ei hailysgrifennu. Dim ond y trydydd patrwm sy’n cadw DNS fesul cysylltiad, oherwydd bod y gweinyddion yn aros ynghlwm wrth ryngwyneb yn lle cael eu gwastatáu’n un rhestr fyd-eang.

Ar systemau NetworkManager mae’r canlyniad yn dibynnu ar y backend yn /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Gyda dns=default mae gweinyddion y cleient yn cael eu huno yn resolv.conf yn y drefn sy’n ennill, ac mae chwiliad preifat yn dal i allu cael ei anfon at y resolver cyhoeddus. Gyda backend sy’n deall cysylltiadau, systemd-resolved neu dnsmasq, mae gweinyddion y twmnel yn aros wedi’u cyfyngu i’r twmnel a dim ond enwau sy’n cyfateb i’w barth llwybro sy’n mynd yno. Y cyfyngiad hwnnw yw ystyr split DNS yn ymarferol, a dyma’r darn sydd fwyaf aml yn eisiau pan fydd cleient yn honni ei fod yn ei gefnogi.

Darllenwch y cyflwr cyn newid unrhyw beth:

resolvectl status
resolvectl dns tun0

Rydych am weld y rhyngwyneb tun wedi’i restru gyda gweinydd DNS a pharth llwybro ar gyfer yr ôl-ddodiad preifat, wedi’i ddangos fel ~internal.example. Nid oes gweinydd ar y cysylltiad yn golygu na wthiodd y cleient ddim. Mae gweinydd heb barth yn golygu bod chwiliadau i gyd yn mynd yno neu ddim un, yn dibynnu ar y cleient, ac nid yw’r naill na’r llall yn split DNS.

Lle mae nsswitch yn gorffen y chwiliad yn gynnar

Mae llinell gliniadur safonol yn edrych fel hyn:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

Mae mdns4_minimal yn trin DNS multicast ac yn hawlio unrhyw enw sy’n gorffen gyda .local. Mae gwasanaeth Kubernetes fel api.infra.svc.cluster.local yn gorffen gyda .local hefyd. Pan fydd y modiwl mDNS yn adrodd NOTFOUND, mae gweithred [NOTFOUND=return] yn gorffen y chwiliad cyfan yn lle parhau i’r modiwl dns, felly ni chaiff yr enw byth ei anfon at resolver y VPN. Mae dig yn osgoi’r ffeil yn gyfan gwbl, a dyna’n union pam nad yw’r ddau offeryn yn cytuno.

Dyna’r cyferbyniad mwyaf miniog yn y broblem hon, ac mae’n dod i lawr i un gair mewn ffeil ffurfweddu sy’n hŷn na’ch VPN. Mae newid y weithred i [NOTFOUND=continue] yn cadw mDNS ar gyfer argraffwyr a dyfeisiau lleol tra’n gadael i DNS weld yr enw. Mae disodli’r llinell gyda hosts: files dns yn gweithio hefyd ac mae’n fwy bras: mae’n gollwng y datrysiad .local ar gyfer yr argraffydd rydych chi’n ei ddefnyddio mewn gwirionedd.

Enwau sy’n byw mewn un rhwydwaith yn union

Mae parthau preifat yn awdurdodol mewn un man yn union. Mae enw AWS fel ip-10-0-4-31.eu-west-1.compute.internal yn cael ei ateb trwy resolver VPC y rhanbarth hwnnw, a dim ond tra bo eich pwynt diwedd VPN yn yr un rhanbarth â’r adnodd. Cysylltwch â phwynt diwedd yn Frankfurt, chwiliwch enw compute.internal o Iwerddon, ac ni fydd unrhyw osodiad lleol yn helpu: nid yw’r parth sy’n dal y cofnod yn gyrraeddadwy oddi yno.

Mae parthau chwilio yn cynhyrchu’r ddelwedd gyferbyn. Mae service noeth yn cael ei gwblhau gyda’r ôl-ddodiad y mae’r resolver yn meddwl sy’n berthnasol, a chyda chysylltiad VPN gall y parth lleol ennill dros yr un corfforaethol. Chwiliwch gyda dot terfynol i gael gwared ar y dyfalu, getent ahosts service.internal.example., ac os yw hynny’n gweithio tra bo’r enw byr yn methu, y cywiriad yw y parth chwilio ar y twmnel, nid cyfeiriad y gweinydd.

Mae cleientiaid a reolir yn ychwanegu trydedd haen uwchben resolver y system. Gall proffil VPN Windows gario ei bolisi datrys enwau ei hun, rheolau fesul ap a thabl NRPT sy’n berthnasol hyd yn oed pan fo’r twmnel i lawr. Mae cymwysiadau â’u storfa DNS eu hunain, yn gyffredin mewn runtimes .NET a Java, yn cadw methiant hen ffasiwn ymhell ar ôl i’r gadwyn gael ei thrwsio. Mae cleientiaid Apple yn ffurfweddu split DNS trwy barthau cyfateb yn y gosodiadau DNS yn hytrach nag trwy resolv.conf, a gall Chromium neu Firefox mewn modd DNS diogel osgoi resolver y system ar gyfer enwau cyhoeddus. Mae cyfeirlyfr Microsoft ar ddatrys enwau VPN yn disgrifio ochr Windows y haen bolisi honno.

Penderfynwch pa haen i’w thrwsio

Gweithiwch o’r symptom i’r haen yn lle ceisio cywiriadau yn eu trefn:

Mae dwy res yn cario’r rhan fwyaf o’r pwysau. Mae terfyn amser yn broblem cyraeddadwyedd: nid yw’r resolver preifat yn ateb trwy’r twmnel, felly gwiriwch y llwybr i’w gyfeiriad a ph’un a yw gweinydd DNS y cysylltiad yr un rydych chi’n ei feddwl. Mae NXDOMAIN yn broblem awdurdod: atebodd rhywbeth ac nid yw’n adnabod yr enw, sy’n pwyntio at y parth, y rhanbarth neu resolver na ddylai fod wedi derbyn y cwestiwn byth.

Y rhes olaf yw’r un mae pobl yn ei cholli oherwydd bod y ddwy hanner yn edrych fel llwyddiant. Mae enw byr sy’n datrys yn wahanol i’r FQDN yn gamgymhariad ôl-ddodiad, ac ni fydd ailgysylltu’r twmnel yn newid pa ôl-ddodiad y mae’r cleient yn ei wthio.

Cofnodwch y cyflwr cyn i chi olygu ffeil ffurfweddu, fel y gallwch ddweud a wnaeth y golygiad unrhyw beth:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Rhedwch y gwiriadau yn y drefn hon a stopiwch ar yr un cyntaf sy’n methu. Rhaid i getent a resolvectl query gytuno; os yw getent yn methu tra bo dig yn ateb, arhoswch yn y gadwyn chwilio a pheidiwch â chyffwrdd â llwybro. Rhaid i resolvectl status ddangos gweinydd DNS a pharth llwybro ar y rhyngwyneb tun. Ni chaiff nsswitch ddychwelyd yn gynnar ar NOTFOUND ar gyfer yr ôl-ddodiad rydych chi’n ei brofi. Rhaid i’r enw fod yn awdurdodol yn y rhwydwaith y mae eich pwynt diwedd ynghlwm wrthi, wedi’i brofi gyda dot terfynol. Ni chaiff y cymhwysiad gadw ei storfa ei hun na throsysgrifiad DNS diogel.

Trwsiwch y haen gyntaf sy’n methu yn unig, yna rhedwch yr un gorchmynion eto. Mae dau newid ar unwaith yn eich gadael heb allu dweud pa un a gyfrifodd, ac mae’r diffyg nesaf yn dechrau’r ymchwiliad o’r dechrau.