Hindi maresolba ng kubectl ang API ng pribadong cluster sa OpenVPN

Nabibigo ang kubectl sa paghahanap ng pangalan habang buhay ang tunnel at sumasagot pa rin sa ping ang pribadong address ng API. Maayos ang ruta; ang kliyente ay nagtatanong sa isang resolver na hindi pa nakarinig tungkol sa pribadong zone ng cluster. Dalawang pagbabago ang pinakaginagamit: itulak ang resolver ng virtual network sa bawat VPN client, o i-pin ang pangalan nang lokal gamit ang entry sa hosts o conditional forwarder. Niresolba nila ang parehong sintomas na may magkaibang responsibilidad, at ang pagpapalit-palit sa kanila ang dahilan kung bakit nag-e-edit ng hosts file ang mga team tuwing itinayong muli ang isang endpoint.

Nabibigo ang resolution at reachability sa magkaibang layer

Patakbuhin mo mismo ang paghahanap bago magbago ng kahit ano. Sinasabi ng getent hosts sa Linux o nslookup sa Windows kung may natatanggap na sagot ang kliyente; ang timeout o NXDOMAIN ay tumuturo sa resolver, habang ang sagot na mali ang address ay tumuturo sa lumang record o pampublikong daanan.

Pagkatapos, kumpirmahin kung aling server ang talagang kinakausap ng kubectl. Nag-iimbak ng URL ang isang kubeconfig context, at hindi ito nire-rewrite ng ruta ng VPN: kung pinangalanan ng context ang pampublikong endpoint, maaaring perpekto ang DNS at nabibigo pa rin ang command.

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

Ang ikatlong senyales ay ang hugis ng pagpalya pagkatapos ng paghahanap. Ang pangalang nare-resolba sa pribadong address at pagkatapos ay nakatatanggap ng TCP timeout ay problema sa firewall o awtorisadong network. Ang pangalang nare-resolba sa pampublikong address ay nangangahulugang nakatakas ang query sa pribadong zone. Paghiwalayin ang tatlong resultang iyon; ang bawat isa ay magdadala sa iyo sa ibang may-ari.

Opsyon A: itulak ang resolver ng virtual network sa tunnel

Kapag tumatakbo ang VPN server sa loob ng virtual network, maaaring gamitin ng mga kliyente ang parehong resolver tulad ng host ng server. Sa OpenVPN Community, nagtutulak ang server ng DNS option; ipinapakita ng Access Server ang parehong setting sa admin interface, at kailangang i-download muli ng mga kliyente ang profile dahil naglalakbay sa loob nito ang DNS directive.

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

Mahalaga ang route line sa mga split tunnel profile. Ang pagtulak ng resolver address ay hindi katulad ng paggawa nitong maabot: kung ang subnet lang ng cluster ang dumadaan sa tunnel, lumalabas ang query sa 10.0.0.4 sa lokal na LAN at namamatay. Magtulak ng host route para sa resolver, o isama ang subnet nito sa tunnel.

May patakaran din ang tumatanggap na panig. Ang resolver na maabot mula sa address range ng kliyente ay maaari pa ring tumanggi sa mga query mula rito, at ang pribadong zone na naka-link sa virtual network ay sumasagot lamang sa mga kliyenteng dumarating sa DNS path ng network na iyon. Kung mag-timeout ang paghahanap pagkatapos ng pagtulak, tingnan ang sariling log ng resolver bago muling hawakan ang kliyente.

Sa kliyente, i-verify kung ano ang inilapat: resolvectl status sa Linux na systemd-resolved, scutil --dns sa macOS, ipconfig /all sa Windows. Ang naipush na DNS server na hindi kailanman lumilitaw ay nangangahulugang hindi na-reload ang profile.

Opsyon B: mga entry sa hosts at conditional forwarding

Ang entry sa hosts ay ang pinakamaliit na posibleng pagbabago at ang pinakamadaling masira. Inimapa nito ang isang pangalan sa isang address sa isang makina, kaya gumagana ito para sa demo at nasisira kapag itinayong muli ang pribadong endpoint o ang IP nito. Itinatago rin nito ang tunay na agwat sa iba pang miyembro ng team.

Mas mahusay na nag-scale ang conditional forwarder nang hindi nagtutulak ng DNS sa bawat kliyente. Maaaring magpadala ang dnsmasq ng isang zone sa VNet resolver at hayaang tahimik ang lahat ng iba pa: server=/cluster.internal/10.0.0.4. May conditional forwarder ang Windows DNS, at maaaring gumamit ang mga Windows client ng NRPT rule para sa parehong paghahati. Kailangan pa rin ng forwarder ng ruta patungo sa VNet resolver.

Pinapanatili ng forwarding na lokal ang normal na pag-browse, na mahalaga sa split tunnel. Binibigyan ka rin nito ng isang lugar para i-log ang mga query para sa pribadong zone, at isang lugar na masisira kapag lumipat ang host ng forwarder.

Pumili ayon sa responsibilidad, hindi sa kaginhawahan

Itulak ang resolver kapag kontrolado mo ang VPN profile at gusto mong gumana ang bawat pribadong pangalan, hindi lang ang API. Pumili ng forwarder kapag kailangang panatilihin ng mga kliyente ang kanilang lokal na DNS para sa lahat ng iba pa, o kapag ang VPN ay pinamamahalaan ng ibang team kaysa sa cluster.

Ang mga entry sa hosts ay diagnostic, hindi deployment. Gumamit ng isa para patunayang maabot ang API, pagkatapos ay alisin ito at ayusin ang resolver path; ang pag-iiwan nito ay ginagawang treasure hunt ang isang tanong sa routing sa hinaharap. Anuman ang piliin mong opsyon, isulat ang zone, ang resolver address at ang rutang nagdadala ng query.

Subukan ang endpoint ng API, hindi lang ang pangalan

Kapag nagtagumpay ang paghahanap, kunin ang version endpoint ng API gamit ang CA ng cluster. Hinihiwalay ng curl --cacert ca.crt https://api.internal.example:6443/version ang mga pagpalya sa TLS at authorization mula sa DNS. Ang 403 ay nangangahulugang gumagana ang pangalan at koneksyon at hindi ang pagkakakilanlan.

Tingnan din kung pinapayagan ng awtorisadong network o firewall ng cluster ang address range ng kliyente. Kadalasan, tinatanggap lang ng mga pribadong cluster ang trapik ng API mula sa VNet o peered range, kaya ang tunnel na nagbibigay ng address mula sa ibang pool ay kumokonekta sa network layer at tinatanggihan sa API.

Isulat ang apat na katotohanan kapag nag-escalate: ang resolver na ginamit ng kliyente, ang address na ibinalik nito, ang server URL sa napiling kubeconfig context, at ang unang operasyong nabigo. Sinasabi ng rekord na iyon sa susunod na engineer kung babaguhin ang DNS, routing o patakaran ng firewall, at pinipigilan nito ang susunod na pag-edit ng hosts file.

Magsimula sa paghahanap, piliin ang resolver path na tumutugma sa may-ari ng zone, pagkatapos ay i-verify ang endpoint. Kung papasa ang tatlo, ang natitirang problema ay authorization, hindi resolution ng pangalan.