kubectl ne peut pas résoudre l’API du cluster privé via OpenVPN

kubectl échoue à la résolution de nom alors que le tunnel est actif et que l’adresse privée de l’API répond encore au ping. La route est bonne ; le client interroge un résolveur qui n’a jamais entendu parler de la zone privée du cluster. Deux corrections sont les plus utilisées : pousser le résolveur du réseau virtuel vers chaque client VPN, ou épingler le nom localement avec une entrée hosts ou un redirecteur conditionnel. Elles traitent le même symptôme avec une responsabilité différente, et les confondre est la façon dont les équipes finissent par modifier des fichiers hosts chaque fois qu’un point de terminaison est reconstruit.

La résolution et l’accessibilité échouent à des couches différentes

Lancez la résolution vous-même avant de changer quoi que ce soit. getent hosts sous Linux ou nslookup sous Windows vous dit si le client obtient une réponse ; un délai dépassé ou NXDOMAIN désigne le résolveur, tandis qu’une réponse avec la mauvaise adresse désigne un enregistrement obsolète ou une fuite publique.

Vérifiez ensuite quel serveur kubectl contacte réellement. Un contexte kubeconfig stocke une URL, et une route VPN ne la réécrit pas : si le contexte nomme un point de terminaison public, le DNS peut être parfait et la commande échouer quand même.

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

Le troisième signal est la forme de l’échec après la résolution. Un nom qui se résout vers l’adresse privée puis subit un délai TCP est un problème de pare-feu ou de réseau autorisé. Un nom qui se résout vers une adresse publique signifie que la requête a échappé à la zone privée. Gardez ces trois issues séparées ; chacune vous envoie vers un responsable différent.

Option A : pousser le résolveur du réseau virtuel dans le tunnel

Lorsque le serveur VPN s’exécute dans le réseau virtuel, les clients peuvent utiliser le même résolveur que l’hôte du serveur. Dans OpenVPN Community, le serveur pousse une option DNS ; Access Server expose le même réglage dans l’interface d’administration, et les clients doivent retélécharger le profil car la directive DNS voyage à l’intérieur.

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

La ligne de route compte sur les profils en tunnel divisé. Pousser une adresse de résolveur n’est pas la même chose que la rendre joignable : si seul le sous-réseau du cluster passe par le tunnel, la requête vers 10.0.0.4 sort par le LAN local et meurt. Poussez une route d’hôte pour le résolveur, ou incluez son sous-réseau dans le tunnel.

Le côté récepteur a aussi une politique. Un résolveur joignable depuis la plage d’adresses du client peut quand même refuser ses requêtes, et une zone privée liée au réseau virtuel ne répond qu’aux clients qui arrivent par le chemin DNS de ce réseau. Si la résolution expire après le push, consultez les journaux du résolveur avant de retoucher le client.

Sur le client, vérifiez ce qui a été appliqué : resolvectl status sous Linux avec systemd-resolved, scutil --dns sous macOS, ipconfig /all sous Windows. Un serveur DNS poussé qui n’apparaît jamais signifie que le profil n’a pas été rechargé.

Option B : entrées hosts et redirection conditionnelle

Une entrée hosts est la plus petite correction possible et la plus fragile. Elle associe un nom à une adresse sur une machine, donc elle fonctionne pour une démo et casse lorsque le point de terminaison privé ou son IP est reconstruit. Elle cache aussi le vrai manque au reste de l’équipe.

Un redirecteur conditionnel s’adapte mieux sans pousser de DNS à chaque client. dnsmasq peut envoyer une zone au résolveur du VNet et laisser tout le reste tranquille : server=/cluster.internal/10.0.0.4. Le DNS de Windows dispose de redirecteurs conditionnels, et les clients Windows peuvent utiliser une règle NRPT pour la même séparation. Le redirecteur a toujours besoin d’une route vers le résolveur du VNet.

La redirection garde la navigation normale en local, ce qui compte en tunnel divisé. Elle vous donne aussi un endroit unique pour journaliser les requêtes de la zone privée, et un endroit unique qui casse quand l’hôte du redirecteur déménage.

Choisissez par responsabilité, pas par commodité

Poussez le résolveur quand vous contrôlez le profil VPN et voulez que chaque nom privé fonctionne, pas seulement l’API. Choisissez un redirecteur quand les clients doivent conserver leur DNS local pour tout le reste, ou quand le VPN est géré par une autre équipe que le cluster.

Les entrées hosts sont un diagnostic, pas un déploiement. Utilisez-en une pour prouver que l’API est joignable, puis retirez-la et corrigez le chemin du résolveur ; la laisser en place transforme une question de routage en chasse au trésor plus tard. Quelle que soit l’option choisie, notez la zone, l’adresse du résolveur et la route qui porte la requête.

Testez le point de terminaison de l’API, pas seulement le nom

Une fois la résolution réussie, récupérez le point de terminaison de version de l’API avec le CA du cluster. curl --cacert ca.crt https://api.internal.example:6443/version sépare les échecs TLS et d’autorisation du DNS. Un 403 signifie que le nom et la connexion fonctionnent et que l’identité non.

Vérifiez aussi si la plage d’adresses du client est autorisée par les réseaux autorisés ou le pare-feu du cluster. Les clusters privés n’acceptent souvent le trafic API que depuis le VNet ou des plages appairées, donc un tunnel qui attribue des adresses d’un autre pool se connecte au niveau réseau et est rejeté au niveau de l’API.

Notez quatre faits quand vous escaladez : le résolveur utilisé par le client, l’adresse qu’il a renvoyée, l’URL du serveur dans le contexte kubeconfig sélectionné, et la première opération qui a échoué. Ce relevé indique au prochain ingénieur s’il faut changer le DNS, le routage ou la politique de pare-feu, et il arrête la prochaine modification du fichier hosts.

Commencez par la résolution, choisissez le chemin de résolveur qui correspond au propriétaire de la zone, puis vérifiez le point de terminaison. Si les trois passent, le problème restant est l’autorisation, pas la résolution de nom.