Ni all kubectl ddatrys API clwstwr preifat dros OpenVPN

Mae kubectl yn methu wrth chwilio enw tra bod y twnnel i fyny ac mae cyfeiriad preifat yr API yn dal i ateb ping. Mae’r llwybr yn iawn; mae’r cleient yn gofyn i ddatryswr nad yw erioed wedi clywed am barth preifat y clwstwr. Defnyddir dau atgyweiriad amlaf: gwthio datryswr y rhwydwaith rhithwir i bob cleient VPN, neu binio’r enw’n lleol gyda chofnod hosts neu anfonwr amodol. Maent yn datrys yr un symptom gyda pherchnogaeth wahanol, a chymysgu’r ddau yw sut mae timau’n gorffen golygu ffeiliau hosts bob tro y caiff golygfa ei hailadeiladu.

Mae datrysiad a chyrhaeddiad yn methu ar haenau gwahanol

Rhedwch yr edrychiad eich hun cyn newid unrhyw beth. getent hosts ar Linux neu nslookup ar Windows yn dweud wrthych a yw’r cleient yn cael ateb o gwbl; mae goramser neu NXDOMAIN yn pwyntio at y datryswr, tra bod ateb gyda’r cyfeiriad anghywir yn pwyntio at gofnod hen neu gwymp cyhoeddus.

Yna cadarnhewch ba weinydd y mae kubectl yn ei ddeialu mewn gwirionedd. Mae cyd-destun kubeconfig yn storio URL, ac nid yw llwybr VPN yn ei ailysgrifennu: os yw’r cyd-destun yn enwi golygfa gyhoeddus, gall DNS fod yn berffaith a’r gorchymyn yn dal i fethu.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

Y trydydd signal yw siâp y methiant ar ôl yr edrychiad. Enw sy’n datrys i’r cyfeiriad preifat ac yna’n cael goramser TCP yw problem wal dân neu rwydwaith awdurdodedig. Mae enw sy’n datrys i gyfeiriad cyhoeddus yn golygu bod y cwestiwn wedi dianc o’r parth preifat. Cadwch y tri chanlyniad ar wahân; mae pob un yn eich anfon at berchnogion gwahanol.

Opsiwn A: gwthio datryswr y rhwydwaith rhithwir i’r twnnel

Pan fo gweinydd VPN yn rhedeg y tu mewn i’r rhwydwaith rhithwir, gall cleientiaid ddefnyddio’r un datryswr â gwesteiwr y gweinydd. Yn OpenVPN Community mae’r gweinydd yn gwthio opsiwn DNS; mae Access Server yn dangos yr un gosodiad yn y rhyngwyneb gweinyddol, a rhaid i gleientiaid lawrlwytho’r proffil eto oherwydd bod y cyfarwyddyd DNS yn teithio ynddo.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

Mae’r llinell llwybr yn bwysig ar broffiliau twnnel hollt. Nid yw gwthio cyfeiriad datryswr yr un peth â’i wneud yn gyrhaeddadwy: os mai dim ond is-rwyd y clwstwr sy’n mynd drwy’r twnnel, mae’r cwestiwn i 10.0.0.4 yn gadael drwy’r LAN lleol ac yn marw. Gwthiwch lwybr gwesteiwr ar gyfer y datryswr, neu cynhwyswch ei is-rwyd yn y twnnel.

Mae gan yr ochr dderbyn bolisi hefyd. Gall datryswr sy’n gyrhaeddadwy o ystod cyfeiriadau’r cleient wrthod cwestiynau ohoni o hyd, ac mae parth preifat sy’n gysylltiedig â’r rhwydwaith rhithwir yn ateb dim ond cleientiaid sy’n cyrraedd drwy lwybr DNS y rhwydwaith hwnnw. Os yw’r edrychiad yn rhewi ar ôl y gwthiad, edrychwch ar logiau’r datryswr ei hun cyn cyffwrdd â’r cleient eto.

Ar y cleient, gwiriwch beth a gafodd ei gymhwyso: resolvectl status ar Linux systemd-resolved, scutil --dns ar macOS, ipconfig /all ar Windows. Mae gweinydd DNS a wthiwyd nad yw byth yn ymddangos yn golygu na chafodd y proffil ei ail-lwytho.

Opsiwn B: cofnodion hosts ac anfon amodol

Cofnod hosts yw’r atgyweiriad lleiaf posibl a’r mwyaf brau. Mae’n mapio un enw i un cyfeiriad ar un peiriant, felly mae’n gweithio ar gyfer demo ac yn torri pan gaiff y golygfa breifat neu ei IP ei hailadeiladu. Mae hefyd yn cuddio’r bwlch go iawn oddi wrth weddill y tîm.

Mae anfonwr amodol yn graddio’n well heb wthio DNS i bob cleient. Gall dnsmasq anfon un parth at ddatryswr y VNet a gadael popeth arall yn llonydd: server=/cluster.internal/10.0.0.4. Mae gan Windows DNS anfonwyr amodol, a gall cleientiaid Windows ddefnyddio rheol NRPT ar gyfer yr un hollt. Mae’r anfonwr yn dal i fod angen llwybr at ddatryswr y VNet.

Mae anfon yn cadw pori arferol yn lleol, sy’n bwysig ar dwnnel hollt. Mae hefyd yn rhoi un lle i chi gofnodi cwestiynau ar gyfer y parth preifat, ac un lle i dorri pan fo gwesteiwr yr anfonwr yn symud.

Dewiswch yn ôl perchnogaeth, nid cyfleustra

Gwthiwch y datryswr pan fyddwch yn rheoli’r proffil VPN ac am i bob enw preifat weithio, nid yr API yn unig. Dewiswch anfonwr pan fo’n rhaid i gleientiaid gadw eu DNS lleol ar gyfer popeth arall, neu pan fo’r VPN yn cael ei reoli gan dîm gwahanol i’r clwstwr.

Mae cofnodion hosts yn ddiagnostig, nid yn ddefnydd cynhyrchu. Defnyddiwch un i brofi bod yr API yn gyrhaeddadwy, yna ei dynnu a thrwsio llwybr y datryswr; mae ei adael yn ei le yn troi cwestiwn llwybro yn helfa drysor yn ddiweddarach. Pa opsiwn bynnag a ddewiswch, nodwch y parth, cyfeiriad y datryswr a’r llwybr sy’n cario’r cwestiwn.

Profwch olygfa’r API, nid yr enw yn unig

Unwaith y bydd yr edrychiad yn llwyddo, estynnwch olygfa fersiwn yr API gyda CA’r clwstwr. curl --cacert ca.crt https://api.internal.example:6443/version yn gwahanu methiannau TLS ac awdurdodi oddi wrth DNS. Mae 403 yn golygu bod yr enw a’r cysylltiad yn gweithio a’r hunaniaeth ddim.

Gwiriwch hefyd a yw ystod cyfeiriadau’r cleient yn cael ei chaniatáu gan rwydweithiau awdurdodedig neu wal dân y clwstwr. Mae clwstwr preifat yn aml yn derbyn traffig API dim ond o’r VNet neu ystodau cymheiriaid, felly mae twnnel sy’n dyrannu cyfeiriadau o gronfa wahanol yn cysylltu ar yr haen rwydwaith ac yn cael ei ollwng yn yr API.

Cofnodwch bedwar ffaith pan fyddwch yn uwchgyfeirio: y datryswr a ddefnyddiodd y cleient, y cyfeiriad a ddychwelodd, URL y gweinydd yng nghyd-destun kubeconfig a ddewiswyd, a’r gweithrediad cyntaf a fethodd. Mae’r cofnod hwnnw’n dweud wrth y peiriannydd nesaf p’un a newid DNS, llwybro neu bolisi wal dân, ac mae’n atal y golygiad nesaf o’r ffeil hosts.

Dechreuwch gyda’r edrychiad, dewiswch lwybr y datryswr sy’n cyfateb i bwy sy’n berchen ar y parth, yna gwiriwch y golygfa. Os yw’r tri yn pasio, yr anhawster sy’n weddill yw awdurdodi, nid datrys enwau.