kubectl kan ikke slå opp API-et for det private clusteret over OpenVPN

kubectl feiler ved navneoppslag mens tunnelen er oppe, og API-ets private adresse svarer fortsatt på ping. Ruten er i orden; klienten spør en resolver som aldri har hørt om den private sonen til clusteret. To rettelser brukes mest: å pushe den virtuelle nettverkets resolver til hver VPN-klient, eller å feste navnet lokalt med en hosts-oppføring eller en betinget forwarder. De løser det samme symptomet med forskjellig eierskap, og å blande dem er hvordan team ender med å redigere hosts-filer hver gang et endepunkt bygges på nytt.

Oppslag og tilgjengelighet feiler i forskjellige lag

Kjør oppslaget selv før du endrer noe. getent hosts på Linux eller nslookup på Windows forteller deg om klienten i det hele tatt får et svar; en timeout eller NXDOMAIN peker på resolveren, mens et svar med feil adresse peker på en utdatert oppføring eller en offentlig gjennomgang.

Bekreft deretter hvilken server kubectl faktisk kontakter. En kubeconfig-kontekst lagrer en URL, og en VPN-rute skriver den ikke om: hvis konteksten angir et offentlig endepunkt, kan DNS være 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 feilens form etter oppslaget. Et navn som løses til den private adressen og deretter følges av en TCP-timeout, er et brannmur- eller autorisert-nettverksproblem. Et navn som løses til en offentlig adresse betyr at spørringen slapp ut av den private sonen. Hold de tre utfallene atskilt; hvert av dem sender deg til en annen eier.

Alternativ A: push den virtuelle nettverkets resolver inn i tunnelen

Når VPN-serveren kjører inne i det virtuelle nettverket, kan klienter bruke samme resolver som serververten. I OpenVPN Community pusher serveren et DNS-alternativ; Access Server viser samme innstilling i administrasjonsgrensesnittet, og klienter må laste ned profilen på nytt fordi DNS-direktivet reiser inne i den.

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

Rutelinjen er viktig på split-tunnel-profiler. Å pushe en resolver-adresse er ikke det samme som å gjøre den tilgjengelig: hvis bare clusterets subnett går gjennom tunnelen, forlater spørringen til 10.0.0.4 det lokale LAN-et og dør. Push en vertsrute for resolveren, eller ta med subnettet dens i tunnelen.

Mottakersiden har også en policy. En resolver som er tilgjengelig fra klientens adresseområde kan fortsatt avvise spørringer derfra, og en privat sone knyttet til det virtuelle nettverket svarer bare klienter som kommer gjennom dette nettverkets DNS-vei. Hvis oppslaget timer ut etter pushen, sjekk resolverens egne logger før du rører klienten igjen.

På klienten, kontroller hva som ble brukt: resolvectl status på systemd-resolved Linux, scutil --dns på macOS, ipconfig /all på Windows. En pushet DNS-server som aldri dukker opp betyr at profilen ikke ble lastet inn på nytt.

Alternativ B: hosts-oppføringer og betinget videresending

En hosts-oppføring er den minste mulige rettelsen og den mest skjøre. Den kobler ett navn til én adresse på én maskin, så den virker til en demo og brytes når det private endepunktet eller IP-en bygges på nytt. Den skjuler også den virkelige mangelen for resten av teamet.

En betinget forwarder skalerer bedre uten å pushe DNS til hver klient. dnsmasq kan sende én sone til VNet-resolveren og la alt annet være: server=/cluster.internal/10.0.0.4. Windows DNS har betingede forwardere, og Windows-klienter kan bruke en NRPT-regel for samme oppdeling. Forwarderen trenger fortsatt en rute til VNet-resolveren.

Videresending holder vanlig surfing lokalt, noe som betyr noe på split tunnel. Det gir deg også ett sted å logge spørringer for den private sonen, og ett sted som brytes når forwarder-verten flytter.

Velg etter eierskap, ikke etter bekvemmelighet

Push resolveren når du kontrollerer VPN-profilen og vil at hvert private navn skal virke, ikke bare API-et. Velg en forwarder når klientene må beholde sin lokale DNS for alt annet, eller når VPN-et administreres av et annet team enn clusteret.

hosts-oppføringer er diagnostikk, ikke utrulling. Bruk en til å bevise at API-et er tilgjengelig, fjern den deretter og reparer resolver-stien; blir den liggende, blir et rutingspørsmål til en skattejakt senere. Uansett hvilket alternativ du velger, skriv ned sonen, resolver-adressen og ruten som bærer spørringen.

Test API-endepunktet, ikke bare navnet

Når oppslaget lykkes, hent API-ets versjonsendepunkt med clusterets CA. curl --cacert ca.crt https://api.internal.example:6443/version skiller TLS- og autorisasjonsfeil fra DNS. En 403 betyr at navnet og tilkoblingen virker og identiteten ikke.

Kontroller også om klientens adresseområde er tillatt av clusterets autoriserte nettverk eller brannmur. Private clustere godtar ofte bare API-trafikk fra VNet eller peered områder, så en tunnel som tildeler adresser fra en annen pool kobler til på nettverkslaget og blir droppet i API-et.

Noter fire fakta når du eskalerer: resolveren klienten brukte, adressen den returnerte, server-URL-en i den valgte kubeconfig-konteksten og den første operasjonen som feilet. Den registreringen forteller den neste ingeniøren om det skal endres DNS, ruting eller brannmurpolicy, og den stopper den neste hosts-filredigeringen.

Start med oppslaget, velg resolver-stien som passer til hvem som eier sonen, og bekreft deretter endepunktet. Hvis alle tre passerer, er det gjenværende problemet autorisasjon, ikke navneoppslag.