kubectl negali išspręsti privataus klasterio API per OpenVPN

kubectl nepavyksta atlikti vardo paieškos, nors tunelis veikia ir privatus API adresas vis dar atsako į ping. Maršrutas tvarkingas; klientas klausia resolverio, kuris niekada negirdėjo apie privatią klasterio zoną. Dažniausiai naudojami du pataisymai: siųsti virtualaus tinklo resolverį kiekvienam VPN klientui arba prisegti vardą vietoje su hosts įrašu arba sąlyginiu persiuntikliu. Jie sprendžia tą patį simptomą su skirtinga atsakomybe, o jų painiojimas lemia tai, kad komandos redaguoja hosts failus kiekvieną kartą, kai galinis taškas atstatomas.

Sprendimas ir pasiekiamumas nepavyksta skirtinguose sluoksniuose

Atlikite paiešką patys prieš ką nors keisdami. getent hosts Linux arba nslookup Windows parodo, ar klientas apskritai gauna atsakymą; laiko limitas arba NXDOMAIN nurodo resolverį, o atsakymas su neteisingu adresu nurodo pasenusį įrašą arba viešą praėjimą.

Tada patikrinkite, kurį serverį kubectl iš tiesų pasiekia. kubeconfig kontekstas saugo URL, o VPN maršrutas jo neperrašo: jei kontekstas nurodo viešą galinį tašką, DNS gali būti tobulas, o komanda vis tiek nepavyks.

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

Trečiasis signalas yra gedimo forma po paieškos. Vardas, kuris išsprendžiamas į privatų adresą ir po to gauna TCP laiko limitą, yra ugniasienės arba autorizuoto tinklo problema. Vardas, kuris išsprendžiamas į viešą adresą, reiškia, kad užklausa pabėgo iš privačios zonos. Laikykite šiuos tris rezultatus atskirai; kiekvienas nukreipia jus pas kitą savininką.

A variantas: siųsti virtualaus tinklo resolverį į tunelį

Kai VPN serveris veikia virtualaus tinklo viduje, klientai gali naudoti tą patį resolverį kaip ir serverio hostas. OpenVPN Community serveryje serveris siunčia DNS parinktį; Access Server rodo tą patį nustatymą administravimo sąsajoje, o klientai turi iš naujo atsisiųsti profilį, nes DNS direktyva keliauja jo viduje.

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

Maršruto eilutė svarbi split tunnel profiliuose. Siųsti resolverio adresą nėra tas pats, kas padaryti jį pasiekiamą: jei per tunelį eina tik klasterio potinklis, užklausa į 10.0.0.4 išeina per vietinį LAN ir žūsta. Siųskite host maršrutą resolveriui arba įtraukite jo potinklį į tunelį.

Priimančioji pusė taip pat turi politiką. Resolveris, pasiekiamas iš kliento adresų intervalo, vis tiek gali atmesti užklausas iš jo, o su virtualiu tinklu susietas privati zona atsako tik klientams, kurie ateina per to tinklo DNS kelią. Jei paieška pasibaigia laiko limitu po siuntimo, patikrinkite paties resolverio žurnalus, prieš vėl liesdami klientą.

Kliente patikrinkite, kas buvo pritaikyta: resolvectl status systemd-resolved Linux, scutil --dns macOS, ipconfig /all Windows. Siųstas DNS serveris, kuris niekada nepasirodo, reiškia, kad profilis nebuvo įkeltas iš naujo.

B variantas: hosts įrašai ir sąlyginis persiuntimas

hosts įrašas yra mažiausias įmanomas pataisymas ir pats trapiausias. Jis susieja vieną vardą su vienu adresu vienoje mašinoje, todėl tinka demonstracijai ir sugenda, kai privatus galinis taškas ar jo IP atstatomas. Jis taip pat paslepia tikrąją spragą nuo likusios komandos.

Sąlyginis persiuntiklis skalėja geriau nesiunčiant DNS kiekvienam klientui. dnsmasq gali nusiųsti vieną zoną VNet resolveriui ir palikti visa kita ramybėje: server=/cluster.internal/10.0.0.4. Windows DNS turi sąlyginius persiuntiklius, o Windows klientai gali naudoti NRPT taisyklę tam pačiam padalijimui. Persiuntikliui vis tiek reikia maršruto į VNet resolverį.

Persiuntimas išlaiko įprastą naršymą vietinį, kas svarbu split tunnel atveju. Jis taip pat suteikia vieną vietą privačios zonos užklausoms registruoti ir vieną vietą, kuri sugenda, kai persiuntiklio hostas persikelia.

Rinkitės pagal atsakomybę, ne pagal patogumą

Siųskite resolverį, kai valdote VPN profilį ir norite, kad veiktų kiekvienas privatus vardas, ne tik API. Rinkitės persiuntiklį, kai klientai turi išlaikyti vietinį DNS viskam kitam, arba kai VPN valdo kita komanda nei klasterį.

hosts įrašai yra diagnostika, o ne diegimas. Naudokite vieną, kad įrodytumėte, jog API pasiekiamas, tada pašalinkite jį ir pataisykite resolverio kelią; palikus jį vietoje, maršruto klausimas vėliau virsta lobio paieška. Kad ir kurią parinktį pasirinktumėte, užrašykite zoną, resolverio adresą ir maršrutą, kuriuo keliauja užklausa.

Išbandykite API galinį tašką, o ne tik vardą

Kai paieška pavyksta, gaukite API versijos galinį tašką su klasterio CA. curl --cacert ca.crt https://api.internal.example:6443/version atskiria TLS ir autorizacijos gedimus nuo DNS. 403 reiškia, kad vardas ir ryšys veikia, o tapatybė ne.

Taip pat patikrinkite, ar kliento adresų intervalą leidžia autorizuoti klasterio tinklai arba ugniasienė. Privatūs klasteriai dažnai priima API srautą tik iš VNet arba peered intervalų, todėl tunelis, skiriantis adresus iš kito telkinio, prisijungia tinklo lygmenyje ir yra atmetamas API lygmenyje.

Eskaluodami užrašykite keturis faktus: resolverį, kurį naudojo klientas, adresą, kurį jis grąžino, serverio URL pasirinktame kubeconfig kontekste ir pirmąją nepavykusią operaciją. Šis įrašas pasako kitam inžinieriui, ar keisti DNS, maršrutus ar ugniasienės politiką, ir sustabdo kitą hosts failo redagavimą.

Pradėkite nuo paieškos, pasirinkite resolverio kelią, atitinkantį zonos savininką, tada patikrinkite galinį tašką. Jei visi trys praeina, likusi problema yra autorizacija, o ne vardų sprendimas.