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.

Започнете с търсенето, изберете пътя на резолвера, който отговаря на собственика на зоната, след което проверете крайната точка. Ако и трите минат, останалият проблем е оторизация, не разрешаване на имена.