kubectl ne može razriješiti API privatnog klastera preko OpenVPN-a

kubectl pada pri traženju imena dok je tunel aktivan, a privatna adresa API-ja još odgovara na ping. Ruta je u redu; klijent pita razrješivač koji nikad nije čuo za privatnu zonu klastera. Najčešće se koriste dva rješenja: poslati razrješivač virtualne mreže svakom VPN klijentu ili pričvrstiti ime lokalno unosom u hosts ili uvjetnim prosljeđivačem. Ona rješavaju isti simptom s različitim vlasništvom, a njihovo miješanje dovodi do toga da timovi uređuju hosts datoteke svaki put kad se endpoint ponovno izgradi.

Razrješavanje i dostupnost padaju na različitim slojevima

Pokrenite traženje sami prije nego što bilo što promijenite. getent hosts na Linuxu ili nslookup na Windowsu kaže dobiva li klijent uopće odgovor; istek vremena ili NXDOMAIN upućuju na razrješivač, dok odgovor s pogrešnom adresom upućuje na zastarjeli zapis ili javni propust.

Zatim potvrdite na koji se poslužitelj kubectl zapravo spaja. kubeconfig kontekst čuva URL, a VPN ruta ga ne prepisuje: ako kontekst navodi javni endpoint, DNS može biti savršen, a naredba ipak pada.

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

Treći signal je oblik kvara nakon traženja. Ime koje se razrješava na privatnu adresu, a zatim slijedi TCP istek vremena, problem je vatrozida ili autorizirane mreže. Ime koje se razrješava na javnu adresu znači da je upit izašao iz privatne zone. Držite ta tri ishoda odvojeno; svaki vas vodi drugom vlasniku.

Opcija A: pošaljite razrješivač virtualne mreže u tunel

Kad VPN poslužitelj radi unutar virtualne mreže, klijenti mogu koristiti isti razrješivač kao poslužiteljev host. U OpenVPN Community poslužitelj šalje DNS opciju; Access Server izlaže istu postavku u administracijskom sučelju, a klijenti moraju ponovno preuzeti profil jer DNS direktiva putuje unutar njega.

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

Linija rute važna je na split-tunnel profilima. Slanje adrese razrješivača nije isto što i činjenje te adrese dostupnom: ako kroz tunel prolazi samo podmreža klastera, upit na 10.0.0.4 izlazi preko lokalnog LAN-a i umire. Pošaljite host rutu za razrješivač ili uključite njegovu podmrežu u tunel.

Strana koja prima također ima pravila. Razrješivač dostupan iz raspona adresa klijenta ipak može odbiti upite s njega, a privatna zona povezana s virtualnom mrežom odgovara samo klijentima koji dolaze kroz DNS put te mreže. Ako traženje istekne nakon slanja, provjerite vlastite zapise razrješivača prije nego što ponovno dirate klijenta.

Na klijentu provjerite što je primijenjeno: resolvectl status na systemd-resolved Linuxu, scutil --dns na macOS-u, ipconfig /all na Windowsu. Poslani DNS poslužitelj koji se nikad ne pojavi znači da profil nije ponovno učitan.

Opcija B: unosi u hosts i uvjetno prosljeđivanje

Unos u hosts najmanja je moguća popravka i najkrhkija. Preslikava jedno ime na jednu adresu na jednom računalu, pa radi za demonstraciju, a pada kad se privatni endpoint ili njegov IP ponovno izgrade. Također skriva stvarnu prazninu od ostatka tima.

Uvjetni prosljeđivač bolje se skalira bez slanja DNS-a svakom klijentu. dnsmasq može poslati jednu zonu VNet razrješivaču, a sve ostalo ostaviti na miru: server=/cluster.internal/10.0.0.4. Windows DNS ima uvjetne prosljeđivače, a Windows klijenti mogu koristiti NRPT pravilo za istu podjelu. Prosljeđivaču i dalje treba ruta do VNet razrješivača.

Prosljeđivanje zadržava uobičajeno pregledavanje lokalno, što je važno na split tunelu. Ono vam daje i jedno mjesto za bilježenje upita za privatnu zonu te jedno mjesto koje pada kad se host prosljeđivača premjesti.

Birajte prema vlasništvu, ne prema udobnosti

Pošaljite razrješivač kad kontrolirate VPN profil i želite da svako privatno ime radi, ne samo API. Odaberite prosljeđivač kad klijenti moraju zadržati lokalni DNS za sve ostalo ili kad VPN vodi drugi tim od klastera.

Unosi u hosts su dijagnostika, a ne implementacija. Upotrijebite ga da dokažete da je API dostupan, zatim ga uklonite i popravite put razrješivača; ako ga ostavite, pitanje usmjeravanja kasnije se pretvara u potragu za blagom. Koju god opciju odabrali, zapišite zonu, adresu razrješivača i rutu koja nosi upit.

Testirajte API endpoint, a ne samo ime

Kad traženje uspije, dohvatite endpoint verzije API-ja s CA klastera. curl --cacert ca.crt https://api.internal.example:6443/version razdvaja TLS i autorizacijske kvarove od DNS-a. 403 znači da ime i veza rade, a identitet ne.

Provjerite i dopuštaju li raspon adresa klijenta autorizirane mreže ili vatrozid klastera. Privatni klasteri često prihvaćaju API promet samo iz VNet ili peered raspona, pa tunel koji dodjeljuje adrese iz drugog skupa uspostavlja vezu na mrežnom sloju i biva odbačen na API-ju.

Zabilježite četiri činjenice kad eskalirate: razrješivač koji je klijent koristio, adresu koju je vratio, URL poslužitelja u odabranom kubeconfig kontekstu i prvu radnju koja je pala. Taj zapis govori sljedećem inženjeru treba li mijenjati DNS, usmjeravanje ili pravila vatrozida, i zaustavlja sljedeće uređivanje hosts datoteke.

Počnite s traženjem, odaberite put razrješivača koji odgovara vlasniku zone, zatim provjerite endpoint. Ako sva tri prođu, preostali je problem autorizacija, a ne razrješavanje imena.