kubectl no puede resolver la API del clúster privado por OpenVPN

kubectl falla al resolver el nombre mientras el túnel está activo y la dirección privada de la API sigue respondiendo a un ping. La ruta está bien; el cliente pregunta a un resolutor que nunca ha oído hablar de la zona privada del clúster. Las dos correcciones más usadas son: enviar el resolutor de la red virtual a cada cliente VPN, o fijar el nombre localmente con una entrada en hosts o un reenviador condicional. Resuelven el mismo síntoma con distinta propiedad, y confundirlas es como los equipos acaban editando archivos hosts cada vez que se reconstruye un extremo.

La resolución y la accesibilidad fallan en capas distintas

Ejecute la consulta usted mismo antes de cambiar nada. getent hosts en Linux o nslookup en Windows le dice si el cliente recibe alguna respuesta; un tiempo de espera agotado o NXDOMAIN apuntan al resolutor, mientras que una respuesta con la dirección equivocada apunta a un registro obsoleto o a una fuga pública.

Después confirme a qué servidor se conecta realmente kubectl. Un contexto de kubeconfig guarda una URL, y una ruta VPN no la reescribe: si el contexto nombra un extremo público, el DNS puede ser perfecto y el 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

La tercera señal es la forma del fallo después de la consulta. Un nombre que resuelve a la dirección privada y luego sufre un tiempo de espera TCP es un problema de firewall o de red autorizada. Un nombre que resuelve a una dirección pública significa que la consulta se escapó de la zona privada. Mantenga esos tres resultados separados; cada uno le lleva a un propietario distinto.

Opción A: enviar el resolutor de la red virtual al túnel

Cuando el servidor VPN se ejecuta dentro de la red virtual, los clientes pueden usar el mismo resolutor que el host del servidor. En OpenVPN Community el servidor envía una opción DNS; Access Server expone el mismo ajuste en la interfaz de administración, y los clientes deben descargar el perfil de nuevo porque la directiva DNS viaja dentro de él.

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

La línea de ruta importa en los perfiles de túnel dividido. Enviar una dirección de resolutor no es lo mismo que hacerla accesible: si solo la subred del clúster pasa por el túnel, la consulta a 10.0.0.4 sale por la LAN local y muere. Envíe una ruta de host para el resolutor, o incluya su subred en el túnel.

El lado receptor también tiene política. Un resolutor accesible desde el rango de direcciones del cliente puede rechazar sus consultas, y una zona privada vinculada a la red virtual solo responde a los clientes que llegan por la ruta DNS de esa red. Si la consulta agota el tiempo después del envío, revise los registros del propio resolutor antes de tocar el cliente otra vez.

En el cliente, verifique qué se aplicó: resolvectl status en Linux con systemd-resolved, scutil --dns en macOS, ipconfig /all en Windows. Un servidor DNS enviado que nunca aparece significa que el perfil no se recargó.

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

Una entrada en hosts es la corrección más pequeña posible y la más frágil. Asigna un nombre a una dirección en una máquina, así que sirve para una demostración y se rompe cuando se reconstruye el extremo privado o su IP. También oculta la brecha real al resto del equipo.

Un reenviador condicional escala mejor sin enviar DNS a cada cliente. dnsmasq puede enviar una zona al resolutor de la VNet y dejar todo lo demás en paz: server=/cluster.internal/10.0.0.4. El DNS de Windows tiene reenviadores condicionales, y los clientes de Windows pueden usar una regla NRPT para la misma división. El reenviador sigue necesitando una ruta hacia el resolutor de la VNet.

El reenvío mantiene local la navegación normal, lo que importa en el túnel dividido. También le da un solo lugar para registrar consultas de la zona privada y un solo lugar que se rompe cuando el host del reenviador se mueve.

Elija por propiedad, no por comodidad

Envíe el resolutor cuando controle el perfil VPN y quiera que funcione cada nombre privado, no solo la API. Elija un reenviador cuando los clientes deban conservar su DNS local para todo lo demás, o cuando el VPN lo gestione un equipo distinto del clúster.

Las entradas en hosts son un diagnóstico, no un despliegue. Use una para demostrar que la API es accesible, luego retírela y arregle la ruta del resolutor; dejarla puesta convierte una cuestión de enrutamiento en una búsqueda del tesoro más adelante. Elija la opción que elija, anote la zona, la dirección del resolutor y la ruta que transporta la consulta.

Pruebe el extremo de la API, no solo el nombre

Cuando la consulta tenga éxito, obtenga el extremo de versión de la API con la CA del clúster. curl --cacert ca.crt https://api.internal.example:6443/version separa los fallos de TLS y de autorización del DNS. Un 403 significa que el nombre y la conexión funcionan y la identidad no.

Compruebe también si el rango de direcciones del cliente está permitido por las redes autorizadas o el firewall del clúster. Los clústeres privados a menudo aceptan tráfico de API solo desde la VNet o rangos emparejados, así que un túnel que asigna direcciones de otro grupo conecta en la capa de red y se descarta en la API.

Anote cuatro hechos cuando escale: el resolutor que usó el cliente, la dirección que devolvió, la URL del servidor en el contexto de kubeconfig seleccionado y la primera operación que falló. Ese registro dice al siguiente ingeniero si cambiar DNS, enrutamiento o política de firewall, y detiene la siguiente edición del archivo hosts.

Empiece por la consulta, elija la ruta de resolutor que coincida con quién posee la zona y luego verifique el extremo. Si las tres pasan, el problema restante es de autorización, no de resolución de nombres.