kubectl no pot resoldre l’API del clúster privat per OpenVPN

kubectl falla en la cerca de noms mentre el túnel està actiu i l’adreça privada de l’API encara respon a un ping. La ruta és correcta; el client pregunta a un resolutor que mai no ha sentit parlar de la zona privada del clúster. Les dues solucions més usades són: enviar el resolutor de la xarxa virtual a cada client VPN, o fixar el nom localment amb una entrada a hosts o un reenviador condicional. Resolen el mateix símptoma amb una propietat diferent, i confondre-les és com els equips acaben editant fitxers hosts cada cop que es refà un punt final.

La resolució i l’abastabilitat fallen en capes diferents

Feu la cerca vosaltres mateixos abans de canviar res. getent hosts a Linux o nslookup a Windows us diu si el client rep cap resposta; un temps d’espera esgotat o NXDOMAIN apunten al resolutor, mentre que una resposta amb l’adreça equivocada apunta a un registre obsolet o a una fuita pública.

Després confirmeu a quin servidor es connecta realment kubectl. Un context kubeconfig desa una URL, i una ruta VPN no la reescriu: si el context anomena un punt final públic, el DNS pot ser perfecte i l’ordre encara falla.

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

El tercer senyal és la forma de la fallada després de la cerca. Un nom que es resol a l’adreça privada i després pateix un temps d’espera TCP és un problema de tallafoc o de xarxa autoritzada. Un nom que es resol a una adreça pública vol dir que la consulta ha escapat de la zona privada. Mantingueu aquests tres resultats separats; cadascun us porta a un propietari diferent.

Opció A: enviar el resolutor de la xarxa virtual dins del túnel

Quan el servidor VPN s’executa dins de la xarxa virtual, els clients poden usar el mateix resolutor que l’amfitrió del servidor. A OpenVPN Community el servidor envia una opció DNS; Access Server exposa la mateixa configuració a la interfície d’administració, i els clients han de tornar a baixar el perfil perquè la directiva DNS viatja dins seu.

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

La línia de ruta importa en perfils d’split tunnel. Enviar una adreça de resolutor no és el mateix que fer-la abastable: si només la subxarxa del clúster passa pel túnel, la consulta a 10.0.0.4 surt per la LAN local i mor. Envieu una ruta d’amfitrió per al resolutor, o incloeu la seva subxarxa al túnel.

El costat receptor també té política. Un resolutor abastable des del rang d’adreces del client encara pot refusar-ne les consultes, i una zona privada enllaçada a la xarxa virtual només respon als clients que arriben pel camí DNS d’aquesta xarxa. Si la cerca s’esgota després de l’enviament, reviseu els registres del resolutor abans de tocar el client una altra vegada.

Al client, verifiqueu què s’ha aplicat: resolvectl status a Linux amb systemd-resolved, scutil --dns a macOS, ipconfig /all a Windows. Un servidor DNS enviat que no apareix mai vol dir que el perfil no s’ha recarregat.

Opció B: entrades a hosts i reenviament condicional

Una entrada a hosts és la solució més petita possible i la més fràgil. Mapeja un nom a una adreça en una màquina, així que funciona per a una demo i es trenca quan es refà el punt final privat o la seva IP. També amaga el buit real a la resta de l’equip.

Un reenviador condicional escala millor sense enviar DNS a cada client. dnsmasq pot enviar una zona al resolutor de la VNet i deixar la resta tranquil·la: server=/cluster.internal/10.0.0.4. El DNS de Windows té reenviadors condicionals, i els clients de Windows poden usar una regla NRPT per a la mateixa divisió. El reenviador encara necessita una ruta fins al resolutor de la VNet.

El reenviament manté la navegació normal local, cosa que importa en split tunnel. També us dona un sol lloc per registrar consultes de la zona privada i un sol lloc que es trenca quan l’amfitrió del reenviador es mou.

Trieu per propietat, no per comoditat

Envieu el resolutor quan controleu el perfil VPN i vulgueu que tots els noms privats funcionin, no només l’API. Trieu un reenviador quan els clients hagin de conservar el seu DNS local per a tota la resta, o quan el VPN el gestioni un equip diferent del clúster.

Les entrades a hosts són un diagnòstic, no un desplegament. Useu-ne una per provar que l’API és abastable, després traieu-la i arregleu el camí del resolutor; deixar-la allà converteix una qüestió d’encaminament en una cacera del tresor més endavant. Trieu l’opció que trieu, anoteu la zona, l’adreça del resolutor i la ruta que porta la consulta.

Proveu el punt final de l’API, no només el nom

Quan la cerca tingui èxit, obteniu el punt final de versió de l’API amb la CA del clúster. curl --cacert ca.crt https://api.internal.example:6443/version separa les fallades de TLS i d’autorització del DNS. Un 403 vol dir que el nom i la connexió funcionen i la identitat no.

Comproveu també si el rang d’adreces del client és permès per les xarxes autoritzades o el tallafoc del clúster. Els clústers privats sovint accepten trànsit d’API només des de la VNet o rangs empetits, així que un túnel que assigna adreces d’un altre pool connecta a la capa de xarxa i es descarta a l’API.

Anoteu quatre fets quan escaleu: el resolutor que va usar el client, l’adreça que va retornar, l’URL del servidor al context kubeconfig seleccionat i la primera operació que va fallar. Aquest registre diu al proper enginyer si cal canviar DNS, encaminament o política de tallafoc, i atura la propera edició del fitxer hosts.

Començeu per la cerca, trieu el camí de resolutor que encaixi amb qui posseeix la zona i després verifiqueu el punt final. Si els tres passen, el problema restant és d’autorització, no de resolució de noms.