kubectl non pode resolver a API do clúster privado por OpenVPN

kubectl falla ao resolver o nome mentres o túnel está activo e o enderezo privado da API segue respondendo a un ping. A ruta está ben; o cliente pregunta a un resolutor que nunca oíu falar da zona privada do clúster. As dúas correccións máis usadas son: enviar o resolutor da rede virtual a cada cliente VPN, ou fixar o nome localmente cunha entrada en hosts ou un reenviador condicional. Resolven o mesmo síntoma con distinta propiedade, e confundilas é como os equipos acaban editando ficheiros hosts cada vez que se reconstrúe un extremo.

A resolución e a accesibilidade fallan en capas distintas

Execute a consulta vostede mesmo antes de cambiar nada. getent hosts en Linux ou nslookup en Windows dille se o cliente recibe algunha resposta; un tempo de espera esgotado ou NXDOMAIN apuntan ao resolutor, mentres que unha resposta co enderezo incorrecto apunta a un rexistro obsoleto ou a unha fuga pública.

Despois confirme a que servidor se conecta realmente kubectl. Un contexto de kubeconfig garda un URL, e unha ruta VPN non a reescribe: se o contexto nomea un extremo público, o DNS pode ser perfecto e o comando seguir fallando.

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

O terceiro sinal é a forma do fallo despois da consulta. Un nome que resolve ao enderezo privado e logo sofre un tempo de espera TCP é un problema de firewall ou de rede autorizada. Un nome que resolve a un enderezo público significa que a consulta escapou da zona privada. Manteña eses tres resultados separados; cada un lévao a un propietario distinto.

Opción A: enviar o resolutor da rede virtual ao túnel

Cando o servidor VPN se executa dentro da rede virtual, os clientes poden usar o mesmo resolutor que o host do servidor. En OpenVPN Community o servidor envía unha opción DNS; Access Server expón o mesmo axuste na interface de administración, e os clientes deben descargar o perfil de novo porque a directiva DNS viaxa dentro del.

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

A liña de ruta importa nos perfís de túnel dividido. Enviar un enderezo de resolutor non é o mesmo que facelo accesible: se só a subrede do clúster pasa polo túnel, a consulta a 10.0.0.4 sae pola LAN local e morre. Envíe unha ruta de host para o resolutor, ou inclúa a súa subrede no túnel.

O lado receptor tamén ten política. Un resolutor accesible desde o rango de enderezos do cliente pode rexeitar as súas consultas, e unha zona privada vinculada á rede virtual só responde aos clientes que chegan pola ruta DNS desa rede. Se a consulta esgota o tempo despois do envío, revise os rexistros do propio resolutor antes de tocar o cliente outra vez.

No cliente, verifique que se aplicou: resolvectl status en Linux con systemd-resolved, scutil --dns en macOS, ipconfig /all en Windows. Un servidor DNS enviado que nunca aparece significa que o perfil non se recargou.

Opción B: entradas en hosts e reenvío condicional

Unha entrada en hosts é a corrección máis pequena posible e a máis fráxil. Asigna un nome a un enderezo nunha máquina, así que serve para unha demostración e rompe cando se reconstrúe o extremo privado ou o seu IP. Tamén agocha a fenda real ao resto do equipo.

Un reenviador condicional escala mellor sen enviar DNS a cada cliente. dnsmasq pode enviar unha zona ao resolutor da VNet e deixar todo o demais en paz: server=/cluster.internal/10.0.0.4. O DNS de Windows ten reenviadores condicionais, e os clientes de Windows poden usar unha regra NRPT para a mesma división. O reenviador segue necesitando unha ruta cara ao resolutor da VNet.

O reenvío mantén a navegación normal local, o que importa en túnel dividido. Tamén lle dá un só lugar para rexistrar consultas da zona privada, e un só lugar que rompe cando o host do reenviador se move.

Escolla por propiedade, non por comodidade

Envíe o resolutor cando controle o perfil VPN e queira que funcione cada nome privado, non só a API. Escolla un reenviador cando os clientes deban conservar o seu DNS local para todo o demais, ou cando o VPN o xestione un equipo distinto do clúster.

As entradas en hosts son un diagnóstico, non un despregamento. Use unha para demostrar que a API é accesible, despois retírea e arranxe a ruta do resolutor; deixala no seu sitio converte unha cuestión de encamiñamento nunha caza do tesouro máis adiante. Escolla a opción que escolla, anote a zona, o enderezo do resolutor e a ruta que transporta a consulta.

Probe o extremo da API, non só o nome

Cando a consulta teña éxito, obteña o extremo de versión da API coa CA do clúster. curl --cacert ca.crt https://api.internal.example:6443/version separa os fallos de TLS e de autorización do DNS. Un 403 significa que o nome e a conexión funcionan e a identidade non.

Comprobe tamén se o rango de enderezos do cliente está permitido polas redes autorizadas ou o firewall do clúster. Os clústers privados adoitan aceptar tráfico de API só desde a VNet ou rangos emparellados, así que un túnel que asigna enderezos doutro grupo conecta na capa de rede e descártase na API.

Anote catro feitos cando escale: o resolutor que usou o cliente, o enderezo que devolveu, o URL do servidor no contexto de kubeconfig seleccionado e a primeira operación que fallou. Ese rexistro di ao seguinte enxeñeiro se cambiar DNS, encamiñamento ou política de firewall, e detén a seguinte edición do ficheiro hosts.

Empece pola consulta, escolla a ruta de resolutor que coincida con quen posúe a zona e despois verifique o extremo. Se as tres pasan, o problema restante é de autorización, non de resolución de nomes.