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

kubectl pada na traženju imena dok je tunel aktivan, a privatna adresa API-ja i dalje odgovara na ping. Ruta je u redu; klijent pita razrješivač koji nikada nije čuo za privatnu zonu klastera. Najčešće se koriste dva rješenja: poslati razrješivač virtualne mreže svakom VPN klijentu ili prikvačiti ime lokalno unosom u hosts ili uslovnim 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 kada se endpoint ponovo izgradi.

Razrješavanje i dostupnost padaju na različitim slojevima

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

Zatim potvrdite na koji server kubectl zapravo ide. 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 tajmaut, problem je firewall-a ili autorizovane 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

Kada VPN server radi unutar virtualne mreže, klijenti mogu koristiti isti razrješivač kao serverski host. U OpenVPN Community server šalje DNS opciju; Access Server izlaže istu postavku u admin UI-ju, a klijenti moraju ponovo 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 je važna na split-tunnel profilima. Slanje adrese razrješivača nije isto što i činjenje te adrese dostupnom: ako kroz tunel ide 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đe ima politiku. 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 logove razrješivača prije nego što ponovo dirate klijenta.

Na klijentu provjerite šta je primijenjeno: resolvectl status na systemd-resolved Linuxu, scutil --dns na macOS-u, ipconfig /all na Windowsu. Poslani DNS server koji se nikada ne pojavi znači da profil nije ponovo učitan.

Opcija B: unosi u hosts i uslovno prosljeđivanje

Unos u hosts je najmanja moguća popravka i najkrhkija. On mapira jedno ime na jednu adresu na jednom računaru, pa radi za demo, a pada kada se privatni endpoint ili njegov IP ponovo izgrade. Takođe skriva stvarnu prazninu od ostatka tima.

Uslovni prosljeđivač se bolje 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 uslovne 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 normalno pregledanje lokalno, što je važno na split tunnelu. Ono vam takođe daje jedno mjesto za logovanje upita za privatnu zonu i jedno mjesto koje pada kada se host prosljeđivača premjesti.

Birajte po vlasništvu, ne po udobnosti

Pošaljite razrješivač kada kontrolišete VPN profil i želite da svako privatno ime radi, ne samo API. Odaberite prosljeđivač kada klijenti moraju zadržati lokalni DNS za sve ostalo ili kada 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 rute kasnije se pretvara u potragu za blagom. Koju god opciju odaberete, zapišite zonu, adresu razrješivača i rutu koja nosi upit.

Testirajte API endpoint, a ne samo ime

Kada 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.

Takođe provjerite da li raspon adresa klijenta dozvoljavaju autorizovane mreže ili firewall klastera. Privatni klasteri često prihvataju API saobraćaj samo iz VNet ili peered raspona, pa tunel koji dodjeljuje adrese iz drugog pula uspostavlja vezu na mrežnom sloju i biva odbačen na API-ju.

Zabilježite četiri činjenice kada eskalirate: razrješivač koji je klijent koristio, adresu koju je vratio, URL servera u odabranom kubeconfig kontekstu i prvu operaciju koja je pala. Taj zapis govori sljedećem inženjeru da li mijenjati DNS, rutiranje ili firewall politiku 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 problem je autorizacija, a ne razrješavanje imena.