kubectl kan ikke slå API'et for det private cluster op via OpenVPN

kubectl fejler ved navneopslag, mens tunnelen er oppe, og API'ets private adresse stadig svarer på ping. Ruten er fin; klienten spørger en resolver, der aldrig har hørt om clusterets private zone. To rettelser bruges mest: at skubbe det virtuelle netværks resolver ud til hver VPN-klient eller at fastlåse navnet lokalt med en hosts-post eller en betinget forwarder. De løser det samme symptom med forskelligt ejerskab, og når man blander dem sammen, ender teams med at redigere hosts-filer, hver gang et endpoint genopbygges.

Opslag og tilgængelighed fejler i forskellige lag

Kør selv opslaget, før du ændrer noget. getent hosts på Linux eller nslookup på Windows fortæller dig, om klienten overhovedet får et svar; en timeout eller NXDOMAIN peger på resolveren, mens et svar med den forkerte adresse peger på en forældet post eller et offentligt gennemløb.

Bekræft derefter hvilken server kubectl faktisk kontakter. En kubeconfig-kontekst gemmer en URL, og en VPN-rute skriver den ikke om: hvis konteksten angiver et offentligt endpoint, kan DNS være perfekt, og kommandoen fejler stadig.

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 signal er fejlens form efter opslaget. Et navn, der opløses til den private adresse og derefter følges af en TCP-timeout, er et firewall- eller autoriseret-netværk-problem. Et navn, der opløses til en offentlig adresse, betyder, at forespørgslen slap ud af den private zone. Hold de tre udfald adskilt; hvert af dem sender dig til en anden ejer.

Mulighed A: skub det virtuelle netværks resolver ind i tunnelen

Når VPN-serveren kører inde i det virtuelle netværk, kan klienter bruge den samme resolver som serverværten. I OpenVPN Community skubber serveren en DNS-indstilling ud; Access Server viser den samme indstilling i admin-UI'et, og klienter skal hente profilen igen, fordi DNS-direktivet rejser inde i den.

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

Rute-linjen betyder noget på split-tunnel-profiler. At skubbe en resolver-adresse er ikke det samme som at gøre den tilgængelig: hvis kun clusterets undernet går gennem tunnelen, forlader forespørgslen til 10.0.0.4 via det lokale LAN og dør. Skub en værtsrute til resolveren, eller inkluder dens undernet i tunnelen.

Modtagersiden har også en politik. En resolver, der er tilgængelig fra klientens adresseområde, kan stadig afvise forespørgsler fra det, og en privat zone, der er knyttet til det virtuelle netværk, svarer kun klienter, der ankommer gennem dette netværks DNS-vej. Hvis opslaget timer ud efter skubbet, skal du tjekke resolverens egne logfiler, før du rører klienten igen.

På klienten skal du kontrollere, hvad der blev anvendt: resolvectl status på systemd-resolved Linux, scutil --dns på macOS, ipconfig /all på Windows. En skubbet DNS-server, der aldrig dukker op, betyder, at profilen ikke blev genindlæst.

Mulighed B: hosts-poster og betinget videresendelse

En hosts-post er den mindst mulige rettelse og den mest skrøbelige. Den mapper ét navn til én adresse på én maskine, så den virker til en demo og går i stykker, når det private endpoint eller dets IP genopbygges. Den skjuler også det reelle gab for resten af teamet.

En betinget forwarder skalerer bedre uden at skubbe DNS til hver klient. dnsmasq kan sende én zone til VNet-resolveren og lade alt andet være: server=/cluster.internal/10.0.0.4. Windows DNS har betingede forwardere, og Windows-klienter kan bruge en NRPT-regel til samme opdeling. Forwarderen har stadig brug for en rute til VNet-resolveren.

Videresendelse holder normal browsing lokal, hvilket betyder noget på split tunnel. Det giver dig også ét sted at logge forespørgsler for den private zone og ét sted, der går i stykker, når forwarder-værten flytter.

Vælg efter ejerskab, ikke efter bekvemmelighed

Skub resolveren, når du styrer VPN-profilen og vil have, at hvert privat navn virker, ikke kun API'et. Vælg en forwarder, når klienterne skal beholde deres lokale DNS til alt andet, eller når VPN'et styres af et andet team end clusteret.

hosts-poster er diagnostik, ikke udrulning. Brug en til at bevise, at API'et er tilgængeligt, og fjern den derefter og ret resolver-stien; hvis den bliver liggende, bliver et routing-spørgsmål til en skattejagt senere. Uanset hvilken mulighed du vælger, så skriv zonen, resolver-adressen og ruten, der bærer forespørgslen, ned.

Test API-endpointet, ikke kun navnet

Når opslaget lykkes, hent API'ets versions-endpoint med clusterets CA. curl --cacert ca.crt https://api.internal.example:6443/version adskiller TLS- og autorisationsfejl fra DNS. En 403 betyder, at navnet og forbindelsen virker, og at identiteten ikke gør.

Kontroller også, om klientens adresseområde er tilladt af clusterets autoriserede netværk eller firewall. Private clusters accepterer ofte kun API-trafik fra VNet eller peered områder, så en tunnel, der tildeler adresser fra en anden pulje, forbinder på netværkslaget og bliver droppet i API'et.

Notér fire fakta, når du eskalerer: den resolver, klienten brugte, den adresse, den returnerede, server-URL'en i den valgte kubeconfig-kontekst og den første handling, der fejlede. Den registrering fortæller den næste ingeniør, om der skal ændres DNS, routing eller firewall-politik, og den stopper den næste hosts-fil-redigering.

Start med opslaget, vælg den resolver-vej, der passer til, hvem der ejer zonen, og bekræft derefter endpointet. Hvis alle tre passerer, er det resterende problem autorisation, ikke navneopslag.