kubectl nedokáže preložiť API privátneho clusteru cez OpenVPN

kubectl zlyháva pri preklade názvu, hoci tunel beží a privátna adresa API stále odpovedá na ping. Trasa je v poriadku; klient sa pýta resolvera, ktorý o privátnej zóne clusteru nikdy nepočul. Najčastejšie sa používajú dve opravy: poslať resolver virtuálnej siete každému klientovi VPN alebo pripnúť názov lokálne položkou hosts či podmieneným forwarderom. Riešia ten istý príznak s rôznym vlastníctvom, a ich zámena vedie k tomu, že tímy pri každom znovuvytvorení koncového bodu upravujú súbory hosts.

Preklad a dostupnosť zlyhávajú v rôznych vrstvách

Spustite preklad sami, skôr než čokoľvek zmeníte. getent hosts na Linuxe alebo nslookup na Windows vám povie, či klient vôbec dostane odpoveď; timeout alebo NXDOMAIN ukazuje na resolver, kým odpoveď s nesprávnou adresou ukazuje na zastaraný záznam alebo verejný priechod.

Potom overte, na ktorý server kubectl skutočne mieri. Kontext kubeconfig ukladá URL a trasa VPN ju neprepisuje: ak kontext uvádza verejný koncový bod, DNS môže byť dokonalé a príkaz napriek tomu zlyhá.

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

Tretím signálom je podoba zlyhania po preklade. Názov, ktorý sa preloží na privátnu adresu a potom nasleduje timeout TCP, je problém firewallu alebo autorizovanej siete. Názov, ktorý sa preloží na verejnú adresu, znamená, že dopyt unikol z privátnej zóny. Tieto tri výsledky držte oddelene; každý vás posiela k inému vlastníkovi.

Možnosť A: pošlite resolver virtuálnej siete do tunela

Keď server VPN beží vo vnútri virtuálnej siete, klienti môžu používať rovnaký resolver ako hostiteľ servera. V OpenVPN Community server posiela voľbu DNS; Access Server zobrazuje rovnaké nastavenie v administračnom rozhraní a klienti musia profil stiahnuť znova, pretože direktíva DNS cestuje v ňom.

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

Riadok trasy je dôležitý pri profiloch split tunnel. Poslať adresu resolvera nie je to isté ako sprístupniť ju: ak tunelom prechádza len podsiete clusteru, dopyt na 10.0.0.4 odíde cez miestnu LAN a zomrie. Pošlite hostiteľskú trasu pre resolver alebo zahrňte jeho podsiete do tunela.

Prijímajúca strana má tiež politiku. Resolver dostupný z rozsahu adries klienta môže jeho dopyty napriek tomu odmietať a privátna zóna prepojená s virtuálnou sieťou odpovedá len klientom, ktorí prichádzajú cestou DNS tejto siete. Ak preklad po odoslaní vyprší, pozrite sa najprv do vlastných logov resolvera, než znova siahnete na klienta.

Na klientovi overte, čo sa použilo: resolvectl status na Linuxe so systemd-resolved, scutil --dns na macOS, ipconfig /all na Windows. Poslaný server DNS, ktorý sa nikdy neobjaví, znamená, že profil nebol znovu načítaný.

Možnosť B: položky hosts a podmienené preposielanie

Položka hosts je najmenšia možná oprava a tá najkrehkejšia. Mapuje jeden názov na jednu adresu na jednom stroji, takže funguje na ukážku a pokazí sa, keď sa privátny koncový bod alebo jeho IP znova vytvorí. Tiež skrýva skutočnú medzeru pred zvyškom tímu.

Podmienený forwarder škáluje lepšie bez posielania DNS každému klientovi. dnsmasq dokáže poslať jednu zónu resolveru VNet a všetko ostatné nechať na pokoji: server=/cluster.internal/10.0.0.4. Windows DNS má podmienené forwardery a klienti Windows môžu pre rovnaké rozdelenie použiť pravidlo NRPT. Forwarder stále potrebuje trasu k resolveru VNet.

Preposielanie udržiava bežné prehliadanie lokálne, čo pri split tuneli záleží. Dáva vám aj jedno miesto na logovanie dopytov pre privátnu zónu a jedno miesto, ktoré sa pokazí, keď sa hostiteľ forwardera presunie.

Vyberajte podľa vlastníctva, nie podľa pohodlia

Resolver posielajte, keď ovládate profil VPN a chcete, aby fungoval každý privátny názov, nielen API. Forwarder zvoľte, keď si klienti musia ponechať lokálny DNS pre všetko ostatné, alebo keď VPN spravuje iný tím ako cluster.

Položky hosts sú diagnostika, nie nasadenie. Použite jednu na dôkaz, že API je dostupné, potom ju odstráňte a opravte cestu resolvera; ponechanie na mieste premení otázku smerovania na neskoršiu honbu za pokladom. Nech zvolíte ktorúkoľvek možnosť, zapíšte zónu, adresu resolvera a trasu, ktorá dopyt nesie.

Testujte koncový bod API, nielen názov

Keď preklad uspeje, načítajte koncový bod verzie API s CA clusteru. curl --cacert ca.crt https://api.internal.example:6443/version oddeľuje zlyhania TLS a autorizácie od DNS. 403 znamená, že názov a spojenie fungujú a identita nie.

Skontrolujte aj, či rozsah adries klienta povoľujú autorizované siete alebo firewall clusteru. Privátne clustery často prijímajú prevádzku API len z VNet alebo peered rozsahov, takže tunel prideľujúci adresy z iného fondu sa pripojí na sieťovej vrstve a je na API zahodený.

Pri eskalácii zaznamenajte štyri fakty: resolver, ktorý klient použil, adresu, ktorú vrátil, URL servera vo vybranom kontexte kubeconfig a prvú operáciu, ktorá zlyhala. Tento záznam povie ďalšiemu inžinierovi, či meniť DNS, smerovanie alebo politiku firewallu, a zastaví ďalšiu úpravu súboru hosts.

Začnite prekladom, zvoľte cestu resolvera zodpovedajúcu vlastníkovi zóny a potom overte koncový bod. Ak prejdú všetky tri, zostávajúcim problémom je autorizácia, nie preklad názvov.