kubectl kan ikkje slå opp API-et til den private klyngja over OpenVPN

kubectl feilar ved namneoppslag medan tunnelen er oppe, og den private adressa til API-et svarar framleis på ping. Ruta er i orden; klienten spør ein resolver som aldri har høyrt om den private sona til klyngja. To rettingar blir mest brukte: å pushe resolveren til det virtuelle nettet til kvar VPN-klient, eller å feste namnet lokalt med ei hosts-oppføring eller ein vilkårsstyrt forwarder. Dei løyser det same symptomet med ulikt eigarskap, og å blande dei er korleis team endar med å redigere hosts-filer kvar gong eit endepunkt blir bygd på nytt.

Oppslag og tilgjenge feilar i ulike lag

Køyr oppslaget sjølv før du endrar noko. getent hosts på Linux eller nslookup på Windows fortel deg om klienten i det heile får eit svar; ein timeout eller NXDOMAIN peikar på resolveren, medan eit svar med feil adresse peikar på ei utdatert oppføring eller ein offentleg gjennomgang.

Stadfest deretter kva server kubectl faktisk kontaktar. Ein kubeconfig-kontekst lagrar ein URL, og ei VPN-rute skriv han ikkje om: viss konteksten nemner eit offentleg endepunkt, kan DNS vere perfekt og kommandoen feile likevel.

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

Det tredje signalet er forma på feilen etter oppslaget. Eit namn som blir løyst til den private adressa og deretter følgd av ein TCP-timeout, er eit brannmur- eller autorisert-nettproblem. Eit namn som blir løyst til ei offentleg adresse, tyder på at spørjinga slapp ut av den private sona. Hald dei tre utfalla frå kvarandre; kvart av dei sender deg til ein annan eigar.

Alternativ A: push resolveren til det virtuelle nettet inn i tunnelen

Når VPN-tenaren køyrer inne i det virtuelle nettet, kan klientar bruke same resolver som tenarverten. I OpenVPN Community pushar tenaren eit DNS-alternativ; Access Server viser same innstillinga i administrasjonsgrensesnittet, og klientar må laste ned profilen på nytt fordi DNS-direktivet reiser inne i han.

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

Rutelina er viktig på split-tunnel-profilar. Å pushe ei resolver-adresse er ikkje det same som å gjere ho tilgjengeleg: viss berre subnettet til klyngja går gjennom tunnelen, forlèt spørjinga til 10.0.0.4 det lokale LAN-et og døyr. Push ei vertsrute for resolveren, eller ta med subnettet hans i tunnelen.

Mottakarsida har òg ein policy. Ein resolver som er tilgjengeleg frå adresseområdet til klienten, kan framleis avvise spørjingar derfrå, og ei privat sone knytt til det virtuelle nettet svarar berre klientar som kjem gjennom DNS-vegen til dette nettet. Viss oppslaget går ut på tid etter pushen, sjekk loggane til resolveren sjølv før du rører klienten igjen.

På klienten, kontroller kva som vart brukt: resolvectl status på systemd-resolved Linux, scutil --dns på macOS, ipconfig /all på Windows. Ein pusha DNS-tenar som aldri dukkar opp, tyder på at profilen ikkje vart lasta inn på nytt.

Alternativ B: hosts-oppføringar og vilkårsstyrt vidaresending

Ei hosts-oppføring er den minste moglege rettinga og den mest skjøre. Ho knyter eitt namn til éi adresse på éin maskin, så ho verkar til ein demo og blir broten når det private endepunktet eller IP-en hans blir bygd på nytt. Ho skjuler òg den verkelege mangelen for resten av teamet.

Ein vilkårsstyrt forwarder skalerer betre utan å pushe DNS til kvar klient. dnsmasq kan sende éi sone til VNet-resolveren og la alt anna vere: server=/cluster.internal/10.0.0.4. Windows DNS har vilkårsstyrte forwardarar, og Windows-klientar kan bruke ein NRPT-regel for same oppdelinga. Forwarderen treng framleis ei rute til VNet-resolveren.

Vidaresending held vanleg surfing lokalt, noko som tel på split tunnel. Det gir deg òg ein stad å logge spørjingar for den private sona, og ein stad som blir broten når forwarder-verten flyttar.

Vel etter eigarskap, ikkje etter bekvemmelegheit

Push resolveren når du kontrollerer VPN-profilen og vil at kvart privat namn skal verke, ikkje berre API-et. Vel ein forwarder når klientane må halde på den lokale DNS-en for alt anna, eller når VPN-et blir styrt av eit anna team enn klyngja.

hosts-oppføringar er diagnostikk, ikkje utrulling. Bruk éi til å prove at API-et er tilgjengeleg, fjern ho deretter og reparer resolver-stien; blir ho liggande, blir eit rutingspørsmål til ein skattejakt seinare. Uansett kva alternativ du vel, skriv ned sona, resolver-adressa og ruta som ber spørjinga.

Test API-endepunktet, ikkje berre namnet

Når oppslaget lukkast, hent versjonsendepunktet til API-et med CA-en til klyngja. curl --cacert ca.crt https://api.internal.example:6443/version skil TLS- og autorisasjonsfeil frå DNS. Ein 403 tyder på at namnet og tilkoplinga verkar og identiteten ikkje.

Kontroller òg om adresseområdet til klienten er tillate av dei autoriserte netta eller brannmuren til klyngja. Private klyngjer godtar ofte berre API-trafikk frå VNet eller peered område, så ein tunnel som tildeler adresser frå ein annan pool, koplar til på nettverkslaget og blir droppa i API-et.

Noter fire fakta når du eskalerer: resolveren klienten brukte, adressa han returnerte, server-URL-en i den valde kubeconfig-konteksten og den første operasjonen som feila. Den registreringa fortel den neste ingeniøren om det skal endrast DNS, ruting eller brannmurpolicy, og ho stoppar den neste hosts-filredigeringa.

Start med oppslaget, vel resolver-stien som passar til kven som eig sona, og stadfest deretter endepunktet. Viss alle tre går gjennom, er det gjenverande problemet autorisasjon, ikkje namneoppslag.