kubectl не можа вырашыць API прыватнага кластара праз OpenVPN

kubectl церпіць няўдачу пры пошуку імені, хоць тунэль працуе і прыватны адрас API усё яшчэ адказвае на ping. Маршрут у парадку; кліент пытае развязальнік, які ніколі не чуў пра прыватную зону кластара. Часцей за ўсё ўжываюць два выпраўленні: адправіць развязальнік віртуальнай сеткі кожнаму кліенту VPN або замацаваць імя лакальна запісам hosts ці ўмоўным перанакіравальнікам. Яны вырашаюць той жа сімптом з рознай адказнасцю, і іх блытаніна прыводзіць да таго, што каманды рэдагуюць файлы hosts кожны раз, калі канчатковы пункт перабудоўваецца.

Развязанне і дасягальнасць церпяць няўдачу на розных узроўнях

Выканайце пошук самі, перш чым нешта змяняць. getent hosts у Linux або nslookup у Windows пакажа, ці атрымлівае кліент наогул адказ; тайм-аўт або NXDOMAIN паказваюць на развязальнік, а адказ з няправільным адрасам — на састарэлы запіс або публічны праход.

Затым пацвердзіце, да якога сервера kubectl насамрэч падключаецца. Кантэкст kubeconfig захоўвае URL, а маршрут VPN яго не перапісвае: калі кантэкст называе публічны канчатковы пункт, DNS можа быць бездакорным, а каманда ўсё роўна не выканаецца.

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

Трэці сігнал — форма збою пасля пошуку. Імя, якое развязваецца ў прыватны адрас, а затым атрымлівае тайм-аўт TCP, — гэта праблема фэйрвола або аўтарызаванай сеткі. Імя, якое развязваецца ў публічны адрас, азначае, што запыт выйшаў з прыватнай зоны. Трымайце гэтыя тры вынікі асобна; кожны вядзе вас да іншага адказнага.

Варыянт A: адправіць развязальнік віртуальнай сеткі ў тунэль

Калі сервер VPN працуе ўнутры віртуальнай сеткі, кліенты могуць выкарыстоўваць той жа развязальнік, што і хост сервера. У OpenVPN Community сервер адпраўляе опцыю DNS; Access Server паказвае тую ж наладу ў адміністрацыйным інтэрфейсе, і кліенты павінны зноў спампаваць профіль, бо дырэктыва DNS падарожнічае ўнутры яго.

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

Радок маршруту мае значэнне ў профілях split tunnel. Адправіць адрас развязальніка — не тое ж самае, што зрабіць яго дасягальным: калі праз тунэль ідзе толькі падсетка кластара, запыт да 10.0.0.4 выходзіць праз лакальны LAN і гіне. Адпраўце маршрут хоста для развязальніка або ўключыце яго падсетку ў тунэль.

Бок, які прымае, таксама мае палітыку. Развязальнік, дасягальны з дыяпазону адрасоў кліента, можа ўсё ж адхіляць запыты з яго, а прыватная зона, звязаная з віртуальнай сеткай, адказвае толькі кліентам, якія прыходзяць праз шлях DNS гэтай сеткі. Калі пошук сканчаецца тайм-аўтам пасля адпраўкі, праглядзіце ўласныя журналы развязальніка, перш чым зноў кранаць кліента.

На кліенце праверце, што было ўжыта: resolvectl status у Linux з systemd-resolved, scutil --dns у macOS, ipconfig /all у Windows. Адпраўлены сервер DNS, які ніколі не з’яўляецца, азначае, што профіль не быў перазагружаны.

Варыянт B: запісы hosts і ўмоўная перадача

Запіс hosts — найменшае магчымае выпраўленне і найбольш крохкае. Ён супастаўляе адно імя з адным адрасам на адной машыне, таму працуе для дэманстрацыі і ламаецца, калі прыватны канчатковы пункт або яго IP перабудоўваюцца. Ён таксама хавае рэальную прагаліну ад астатняй каманды.

Умоўны перанакіравальнік масштабуецца лепш, не адпраўляючы DNS кожнаму кліенту. dnsmasq можа адправіць адну зону развязальніку VNet і пакінуць усё астатняе ў спакоі: server=/cluster.internal/10.0.0.4. DNS Windows мае ўмоўныя перанакіравальнікі, і кліенты Windows могуць выкарыстоўваць правіла NRPT для таго ж падзелу. Перанакіравальніку ўсё яшчэ патрэбен маршрут да развязальніка VNet.

Перадача захоўвае звычайны прагляд лакальным, што важна ў split tunnel. Яна таксама дае вам адно месца для журнала запытаў прыватнай зоны і адно месца, якое ламаецца, калі хост перанакіравальніка пераязджае.

Выбірайце па адказнасці, а не па зручнасці

Адпраўце развязальнік, калі вы кантралюеце профіль VPN і хочаце, каб працавала кожнае прыватнае імя, а не толькі API. Выберыце перанакіравальнік, калі кліенты павінны захаваць лакальны DNS для ўсяго астатняга, або калі VPN кіруе іншая каманда, чым кластар.

Запісы hosts — гэта дыягностыка, а не разгортванне. Выкарыстайце адзін, каб даказаць, што API дасягальны, затым выдаліце яго і выпраўце шлях развязальніка; калі пакінуць яго на месцы, пытанне маршрутызацыі пазней ператвараецца ў пошук скарбаў. Які б варыянт вы ні выбралі, запішыце зону, адрас развязальніка і маршрут, які нясе запыт.

Праверце канчатковы пункт API, а не толькі імя

Калі пошук паспяховы, атрымайце канчатковы пункт версіі API з CA кластара. curl --cacert ca.crt https://api.internal.example:6443/version аддзяляе збоі TLS і аўтарызацыі ад DNS. 403 азначае, што імя і злучэнне працуюць, а ідэнтычнасць не.

Праверце таксама, ці дазваляюць дыяпазон адрасоў кліента аўтарызаваныя сеткі або фэйрвол кластара. Прыватныя кластары часта прымаюць трафік API толькі з VNet або peered-дыяпазонаў, таму тунэль, які выдае адрасы з іншага пула, падключаецца на сеткавым узроўні і адкідваецца на API.

Запішыце чатыры факты, калі эскалюеце: развязальнік, які выкарыстаў кліент, адрас, які ён вярнуў, URL сервера ў выбраным кантэксце kubeconfig і першую аперацыю, якая не ўдалася. Гэты запіс скажа наступнаму інжынеру, ці мяняць DNS, маршрутызацыю або палітыку фэйрвола, і ён спыніць наступнае рэдагаванне файла hosts.

Пачніце з пошуку, выберыце шлях развязальніка, які адпавядае ўладальніку зоны, затым праверце канчатковы пункт. Калі ўсе тры пройдуць, астатняя праблема — аўтарызацыя, а не развязанне імёнаў.