kubectl não consegue resolver a API do cluster privado via OpenVPN

kubectl falha na pesquisa de nome enquanto o túnel está ativo e o endereço privado da API ainda responde a um ping. A rota está bem; o cliente pergunta a um resolver que nunca ouviu falar da zona privada do cluster. As duas correções mais usadas são: enviar o resolver da rede virtual para cada cliente VPN, ou fixar o nome localmente com uma entrada hosts ou um encaminhador condicional. Resolvem o mesmo sintoma com responsabilidades diferentes, e confundi-las é como as equipas acabam a editar ficheiros hosts sempre que um endpoint é reconstruído.

A resolução e a acessibilidade falham em camadas diferentes

Execute a pesquisa você mesmo antes de mudar nada. getent hosts no Linux ou nslookup no Windows diz-lhe se o cliente recebe alguma resposta; um tempo limite ou NXDOMAIN apontam para o resolver, enquanto uma resposta com o endereço errado aponta para um registo obsoleto ou uma fuga pública.

Depois confirme a que servidor o kubectl se liga realmente. Um contexto kubeconfig guarda um URL, e uma rota VPN não o reescreve: se o contexto indica um endpoint público, o DNS pode estar perfeito e o comando falhar na mesma.

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 da falha depois da pesquisa. Um nome que resolve para o endereço privado e depois sofre um tempo limite TCP é um problema de firewall ou de rede autorizada. Um nome que resolve para um endereço público significa que a consulta escapou da zona privada. Mantenha estes três resultados separados; cada um leva-o a um responsável diferente.

Opção A: enviar o resolver da rede virtual para o túnel

Quando o servidor VPN corre dentro da rede virtual, os clientes podem usar o mesmo resolver que o host do servidor. No OpenVPN Community o servidor envia uma opção DNS; o Access Server expõe a mesma definição na interface de administração, e os clientes têm de descarregar o perfil novamente porque a diretiva DNS viaja dentro dele.

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

A linha de rota importa nos perfis de túnel dividido. Enviar um endereço de resolver não é o mesmo que torná-lo acessível: se só a sub-rede do cluster passa pelo túnel, a consulta para 10.0.0.4 sai pela LAN local e morre. Envie uma rota de host para o resolver, ou inclua a sub-rede dele no túnel.

O lado recetor também tem política. Um resolver acessível a partir do intervalo de endereços do cliente pode mesmo assim recusar consultas dele, e uma zona privada ligada à rede virtual só responde a clientes que chegam pelo caminho DNS dessa rede. Se a pesquisa expirar depois do envio, verifique os registos do próprio resolver antes de tocar no cliente outra vez.

No cliente, verifique o que foi aplicado: resolvectl status no Linux com systemd-resolved, scutil --dns no macOS, ipconfig /all no Windows. Um servidor DNS enviado que nunca aparece significa que o perfil não foi recarregado.

Opção B: entradas hosts e encaminhamento condicional

Uma entrada hosts é a correção mais pequena possível e a mais frágil. Mapeia um nome para um endereço numa máquina, por isso funciona numa demonstração e quebra quando o endpoint privado ou o seu IP é reconstruído. Também esconde a lacuna real do resto da equipa.

Um encaminhador condicional escala melhor sem enviar DNS a cada cliente. O dnsmasq pode enviar uma zona para o resolver da VNet e deixar tudo o resto em paz: server=/cluster.internal/10.0.0.4. O DNS do Windows tem encaminhadores condicionais, e os clientes Windows podem usar uma regra NRPT para a mesma divisão. O encaminhador continua a precisar de uma rota para o resolver da VNet.

O encaminhamento mantém a navegação normal local, o que importa em túnel dividido. Também lhe dá um único local para registar consultas da zona privada, e um único local que quebra quando o host do encaminhador se muda.

Escolha pela responsabilidade, não pela conveniência

Envie o resolver quando controla o perfil VPN e quer que todos os nomes privados funcionem, não só a API. Escolha um encaminhador quando os clientes têm de manter o DNS local para tudo o resto, ou quando a VPN é gerida por uma equipa diferente do cluster.

As entradas hosts são um diagnóstico, não uma implementação. Use uma para provar que a API é acessível, depois remova-a e corrija o caminho do resolver; deixá-la no lugar transforma uma questão de encaminhamento numa caça ao tesouro mais tarde. Seja qual for a opção, anote a zona, o endereço do resolver e a rota que transporta a consulta.

Teste o endpoint da API, não apenas o nome

Quando a pesquisa tiver êxito, obtenha o endpoint de versão da API com a CA do cluster. curl --cacert ca.crt https://api.internal.example:6443/version separa as falhas de TLS e de autorização do DNS. Um 403 significa que o nome e a ligação funcionam e a identidade não.

Verifique também se o intervalo de endereços do cliente é permitido pelas redes autorizadas ou pela firewall do cluster. Os clusters privados aceitam muitas vezes tráfego de API apenas da VNet ou de intervalos emparelhados, por isso um túnel que atribui endereços de outro conjunto liga-se na camada de rede e é descartado na API.

Anote quatro factos quando escala: o resolver que o cliente usou, o endereço que devolveu, o URL do servidor no contexto kubeconfig selecionado e a primeira operação que falhou. Esse registo diz ao próximo engenheiro se deve mudar DNS, encaminhamento ou política de firewall, e trava a próxima edição do ficheiro hosts.

Comece pela pesquisa, escolha o caminho do resolver que corresponde a quem possui a zona e depois verifique o endpoint. Se os três passarem, o problema restante é de autorização, não de resolução de nomes.