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.

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