kubectl nu poate rezolva API-ul clusterului privat prin OpenVPN

kubectl eșuează la căutarea numelui în timp ce tunelul este activ și adresa privată a API-ului încă răspunde la ping. Ruta este în regulă; clientul întreabă un resolver care nu a auzit niciodată de zona privată a clusterului. Se folosesc cel mai des două corecții: trimiterea resolverului rețelei virtuale către fiecare client VPN sau fixarea numelui local cu o intrare hosts sau un forwarder condiționat. Ele rezolvă același simptom cu responsabilități diferite, iar amestecarea lor duce la echipe care editează fișiere hosts de fiecare dată când un endpoint este reconstruit.

Rezolvarea și accesibilitatea eșuează în straturi diferite

Rulați căutarea singur înainte de a schimba ceva. getent hosts pe Linux sau nslookup pe Windows vă spune dacă clientul primește vreun răspuns; un timeout sau NXDOMAIN indică resolverul, în timp ce un răspuns cu adresa greșită indică o înregistrare învechită sau o scurgere publică.

Apoi confirmați la ce server se conectează de fapt kubectl. Un context kubeconfig stochează un URL, iar o rută VPN nu îl rescrie: dacă contextul numește un endpoint public, DNS-ul poate fi perfect și comanda tot eșuează.

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

Al treilea semnal este forma eșecului după căutare. Un nume care se rezolvă la adresa privată și apoi întâmpină un timeout TCP este o problemă de firewall sau de rețea autorizată. Un nume care se rezolvă la o adresă publică înseamnă că interogarea a scăpat din zona privată. Țineți cele trei rezultate separate; fiecare vă trimite la un alt responsabil.

Opțiunea A: trimiteți resolverul rețelei virtuale în tunel

Când serverul VPN rulează în rețeaua virtuală, clienții pot folosi același resolver ca gazda serverului. În OpenVPN Community serverul trimite o opțiune DNS; Access Server expune aceeași setare în interfața de administrare, iar clienții trebuie să descarce din nou profilul pentru că directiva DNS călătorește în el.

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

Linia de rută contează în profilurile split tunnel. Trimiterea unei adrese de resolver nu este același lucru cu a o face accesibilă: dacă doar subrețeaua clusterului trece prin tunel, interogarea către 10.0.0.4 iese prin LAN-ul local și moare. Trimiteți o rută de gazdă pentru resolver sau includeți subrețeaua lui în tunel.

Și partea receptoare are o politică. Un resolver accesibil din intervalul de adrese al clientului poate refuza în continuare interogări de acolo, iar o zonă privată legată de rețeaua virtuală răspunde doar clienților care sosesc prin calea DNS a acelei rețele. Dacă căutarea expiră după trimitere, verificați jurnalele resolverului înainte de a atinge din nou clientul.

Pe client, verificați ce s-a aplicat: resolvectl status pe Linux cu systemd-resolved, scutil --dns pe macOS, ipconfig /all pe Windows. Un server DNS trimis care nu apare niciodată înseamnă că profilul nu a fost reîncărcat.

Opțiunea B: intrări hosts și forwardare condiționată

O intrare hosts este cea mai mică corecție posibilă și cea mai fragilă. Asociază un nume cu o adresă pe o singură mașină, deci funcționează pentru o demonstrație și se strică atunci când endpointul privat sau IP-ul lui este reconstruit. Ascunde și golul real de restul echipei.

Un forwarder condiționat scalează mai bine fără a trimite DNS la fiecare client. dnsmasq poate trimite o zonă către resolverul VNet și lăsa tot restul în pace: server=/cluster.internal/10.0.0.4. DNS-ul Windows are forwardere condiționate, iar clienții Windows pot folosi o regulă NRPT pentru aceeași împărțire. Forwarderul are în continuare nevoie de o rută către resolverul VNet.

Forwardarea menține navigarea normală locală, ceea ce contează în split tunnel. Vă oferă și un singur loc pentru a înregistra interogările zonei private, și un singur loc care se strică atunci când gazda forwarderului se mută.

Alegeți după responsabilitate, nu după comoditate

Trimiteți resolverul când controlați profilul VPN și vreți ca fiecare nume privat să funcționeze, nu doar API-ul. Alegeți un forwarder când clienții trebuie să păstreze DNS-ul local pentru tot restul, sau când VPN-ul este administrat de o altă echipă decât clusterul.

Intrările hosts sunt un diagnostic, nu un deployment. Folosiți una pentru a dovedi că API-ul este accesibil, apoi eliminați-o și reparați calea resolverului; lăsarea ei transformă o întrebare de rutare într-o vânătoare de comori mai târziu. Indiferent de opțiunea aleasă, notați zona, adresa resolverului și ruta care transportă interogarea.

Testați endpointul API, nu doar numele

După ce căutarea reușește, obțineți endpointul de versiune al API-ului cu CA-ul clusterului. curl --cacert ca.crt https://api.internal.example:6443/version separă eșecurile TLS și de autorizare de DNS. Un 403 înseamnă că numele și conexiunea funcționează, iar identitatea nu.

Verificați și dacă intervalul de adrese al clientului este permis de rețelele autorizate sau de firewallul clusterului. Clusterele private acceptă adesea trafic API doar din VNet sau din intervale peer, așa că un tunel care alocă adrese dintr-un alt pool se conectează la nivel de rețea și este eliminat la API.

Notați patru fapte când escalați: resolverul folosit de client, adresa returnată, URL-ul serverului în contextul kubeconfig selectat și prima operație care a eșuat. Acea înregistrare îi spune următorului inginer dacă să schimbe DNS-ul, rutarea sau politica de firewall, și oprește următoarea editare a fișierului hosts.

Începeți cu căutarea, alegeți calea resolverului care corespunde proprietarului zonei, apoi verificați endpointul. Dacă toate trei trec, problema rămasă este autorizarea, nu rezolvarea numelor.