kubectl nedokáže přeložit API privátního clusteru přes OpenVPN

Funkční tunel ještě neznamená, že je privátní zóna přeložitelná. Porovnejte posílání resolveru VNet s položkami hosts nebo forwarderu a potom otestujte koncový bod API.

kubectl selhává při překladu jména, i když je tunel aktivní a privátní adresa API stále odpovídá na ping. Trasa je v pořádku; klient se ptá resolveru, který o privátní zóně clusteru nikdy neslyšel. Nejčastěji se používají dvě opravy: poslat resolver virtuální sítě každému klientovi VPN, nebo jméno připnout lokálně pomocí položky hosts či podmíněného forwarderu. Řeší stejný příznak s různým vlastnictvím, a jejich záměna vede k tomu, že týmy při každém znovuvytvoření koncového bodu upravují soubory hosts.

Překlad a dostupnost selhávají v různých vrstvách

Než cokoli změníte, spusťte překlad sami. getent hosts na Linuxu nebo nslookup na Windows vám řekne, zda klient vůbec dostane odpověď; timeout nebo NXDOMAIN ukazuje na resolver, kdežto odpověď se špatnou adresou ukazuje na zastaralý záznam nebo veřejný průchod.

Potom ověřte, na který server kubectl skutečně míří. Kontext kubeconfig ukládá URL a trasa VPN ji nepřepisuje: pokud kontext uvádí veřejný koncový bod, DNS může být dokonalé a příkaz přesto selže.

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

Třetím signálem je podoba selhání po překladu. Jméno, které se přeloží na privátní adresu a následuje timeout TCP, je problém firewallu nebo autorizované sítě. Jméno, které se přeloží na veřejnou adresu, znamená, že dotaz unikl z privátní zóny. Tyto tři výsledky držte oddělené; každý vás posílá k jinému vlastníkovi.

Možnost A: pošlete resolver virtuální sítě do tunelu

Když server VPN běží uvnitř virtuální sítě, klienti mohou používat stejný resolver jako hostitel serveru. V OpenVPN Community server posílá volbu DNS; Access Server vystavuje stejné nastavení v administračním rozhraní a klienti musí profil stáhnout znovu, protože direktiva DNS cestuje uvnitř něj.

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

Řádek trasy je důležitý u profilů split tunnel. Poslat adresu resolveru není totéž jako ji zpřístupnit: pokud tunelem prochází jen podsíť clusteru, dotaz na 10.0.0.4 odejde přes místní LAN a zemře. Pošlete hostitelskou trasu pro resolver nebo zahrňte jeho podsíť do tunelu.

Přijímající strana má také politiku. Resolver dostupný z rozsahu adres klienta může jeho dotazy přesto odmítat a privátní zóna propojená s virtuální sítí odpovídá jen klientům, kteří přicházejí cestou DNS této sítě. Pokud překlad po odeslání vyprší, podívejte se nejprve do vlastních logů resolveru, než znovu sáhnete na klienta.

Na klientovi ověřte, co se použilo: resolvectl status na Linuxu se systemd-resolved, scutil --dns na macOS, ipconfig /all na Windows. Poslaný server DNS, který se nikdy neobjeví, znamená, že profil nebyl znovu načten.

Možnost B: položky hosts a podmíněné předávání

Položka hosts je nejmenší možná oprava a ta nejkřehčí. Mapuje jedno jméno na jednu adresu na jednom stroji, takže funguje pro demo a rozbije se, když se privátní koncový bod nebo jeho IP znovu vytvoří. Také skrývá skutečnou mezeru před zbytkem týmu.

Podmíněný forwarder škáluje lépe, aniž by posílal DNS každému klientovi. dnsmasq umí poslat jednu zónu resolveru VNet a všechno ostatní nechat na pokoji: server=/cluster.internal/10.0.0.4. Windows DNS má podmíněné forwardery a klienti Windows mohou pro stejné rozdělení použít pravidlo NRPT. Forwarder stále potřebuje trasu k resolveru VNet.

Předávání udržuje běžné prohlížení lokálně, což u split tunnelu záleží. Dává vám také jedno místo pro logování dotazů na privátní zónu a jedno místo, které se rozbije, když se hostitel forwarderu přesune.

Vybírejte podle vlastnictví, ne podle pohodlí

Resolver posílejte, když ovládáte profil VPN a chcete, aby fungovala všechna privátní jména, ne jen API. Forwarder zvolte, když si klienti musí ponechat místní DNS pro všechno ostatní, nebo když VPN spravuje jiný tým než cluster.

Položky hosts jsou diagnostika, ne nasazení. Použijte ji k důkazu, že API je dostupné, pak ji odstraňte a opravte cestu resolveru; ponechání na místě promění otázku trasování v pozdější honbu za pokladem. Ať zvolíte kteroukoli možnost, zapište zónu, adresu resolveru a trasu, která dotaz nese.

Testujte koncový bod API, ne jen jméno

Když překlad uspěje, načtěte koncový bod verze API s CA clusteru. curl --cacert ca.crt https://api.internal.example:6443/version odděluje selhání TLS a autorizace od DNS. 403 znamená, že jméno a spojení fungují, ale identita ne.

Zkontrolujte také, zda rozsah adres klienta povolují autorizované sítě nebo firewall clusteru. Privátní clustery často přijímají provoz API jen z VNet nebo peered rozsahů, takže tunel, který přiděluje adresy z jiného poolu, se připojí na síťové vrstvě a je na API zahozen.

Při eskalaci zaznamenejte čtyři fakta: resolver, který klient použil, adresu, kterou vrátil, URL serveru ve vybraném kontextu kubeconfig a první operaci, která selhala. Tento záznam řekne dalšímu inženýrovi, zda měnit DNS, směrování nebo politiku firewallu, a zastaví další úpravu souboru hosts.

Začněte překladem, zvolte cestu resolveru odpovídající vlastníkovi zóny a potom ověřte koncový bod. Pokud projdou všechny tři, zbývající problém je autorizace, ne překlad jmen.

Související články