kubectl kann die private Cluster-API über OpenVPN nicht auflösen

kubectl scheitert an der Namensauflösung, während der Tunnel steht und die private Adresse der API noch auf einen Ping antwortet. Die Route ist in Ordnung; der Client fragt einen Resolver, der von der privaten Zone des Clusters noch nie gehört hat. Zwei Korrekturen werden am häufigsten verwendet: den Resolver des virtuellen Netzwerks an jeden VPN-Client pushen oder den Namen lokal mit einem hosts-Eintrag oder einem bedingten Forwarder festnageln. Beide beheben dasselbe Symptom mit unterschiedlicher Zuständigkeit, und wer sie verwechselt, bearbeitet hosts-Dateien, sobald ein Endpunkt neu aufgebaut wird.

Auflösung und Erreichbarkeit scheitern auf verschiedenen Ebenen

Führen Sie die Abfrage selbst aus, bevor Sie etwas ändern. getent hosts unter Linux oder nslookup unter Windows zeigt Ihnen, ob der Client überhaupt eine Antwort erhält; ein Timeout oder NXDOMAIN deutet auf den Resolver hin, während eine Antwort mit der falschen Adresse auf einen veralteten Eintrag oder einen öffentlichen Durchgriff deutet.

Bestätigen Sie dann welchen Server kubectl tatsächlich anspricht. Ein kubeconfig-Kontext speichert eine URL, und eine VPN-Route schreibt sie nicht um: Wenn der Kontext einen öffentlichen Endpunkt nennt, kann DNS perfekt sein und der Befehl scheitert trotzdem.

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

Das dritte Signal ist die Form des Fehlers nach der Abfrage. Ein Name, der auf die private Adresse auflöst und dann in einen TCP-Timeout läuft, ist ein Firewall- oder autorisiertes-Netz-Problem. Ein Name, der auf eine öffentliche Adresse auflöst, bedeutet, dass die Abfrage die private Zone verlassen hat. Halten Sie diese drei Ergebnisse auseinander; jedes schickt Sie zu einem anderen Zuständigen.

Option A: den Resolver des virtuellen Netzwerks in den Tunnel pushen

Wenn der VPN-Server im virtuellen Netzwerk läuft, können Clients denselben Resolver wie der Serverhost verwenden. In OpenVPN Community pusht der Server eine DNS-Option; Access Server zeigt dieselbe Einstellung in der Admin-Oberfläche, und Clients müssen das Profil erneut herunterladen, weil die DNS-Direktive darin mitreist.

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

Die Routenzeile ist bei Split-Tunnel-Profilen wichtig. Eine Resolver-Adresse zu pushen ist nicht dasselbe, wie sie erreichbar zu machen: Wenn nur das Cluster-Subnetz durch den Tunnel geht, verlässt die Abfrage an 10.0.0.4 das lokale LAN und stirbt. Pushen Sie eine Host-Route für den Resolver oder nehmen Sie dessen Subnetz in den Tunnel auf.

Auch die Empfangsseite hat eine Richtlinie. Ein Resolver, der aus dem Client-Adressbereich erreichbar ist, kann Abfragen von dort trotzdem ablehnen, und eine private Zone, die mit dem virtuellen Netzwerk verknüpft ist, antwortet nur Clients, die über den DNS-Pfad dieses Netzwerks ankommen. Wenn die Abfrage nach dem Push in einen Timeout läuft, prüfen Sie die Logs des Resolvers, bevor Sie den Client erneut anfassen.

Prüfen Sie auf dem Client, was angewendet wurde: resolvectl status unter systemd-resolved Linux, scutil --dns unter macOS, ipconfig /all unter Windows. Ein gepushter DNS-Server, der nie auftaucht, bedeutet, dass das Profil nicht neu geladen wurde.

Option B: hosts-Einträge und bedingte Weiterleitung

Ein hosts-Eintrag ist die kleinste mögliche Korrektur und die brüchigste. Er ordnet einen Namen einer Adresse auf einer Maschine zu, funktioniert also für eine Demo und bricht, wenn der private Endpunkt oder seine IP neu aufgebaut wird. Er verbirgt die eigentliche Lücke auch vor dem Rest des Teams.

Ein bedingter Forwarder skaliert besser, ohne DNS an jeden Client zu pushen. dnsmasq kann eine Zone an den VNet-Resolver schicken und alles andere in Ruhe lassen: server=/cluster.internal/10.0.0.4. Windows DNS kennt bedingte Forwarder, und Windows-Clients können für dieselbe Aufteilung eine NRPT-Regel verwenden. Der Forwarder braucht weiterhin eine Route zum VNet-Resolver.

Weiterleitung hält normales Surfen lokal, was beim Split Tunnel zählt. Sie gibt Ihnen außerdem eine Stelle zum Protokollieren von Abfragen für die private Zone und eine Stelle, die bricht, wenn der Forwarder-Host umzieht.

Nach Zuständigkeit wählen, nicht nach Bequemlichkeit

Pushen Sie den Resolver, wenn Sie das VPN-Profil kontrollieren und möchten, dass jeder private Name funktioniert, nicht nur die API. Wählen Sie einen Forwarder, wenn Clients ihr lokales DNS für alles andere behalten müssen oder wenn das VPN von einem anderen Team als der Cluster verwaltet wird.

hosts-Einträge sind eine Diagnose, keine Bereitstellung. Verwenden Sie einen, um zu beweisen, dass die API erreichbar ist, entfernen Sie ihn dann und reparieren Sie den Resolver-Pfad; bleibt er stehen, wird aus einer Routing-Frage später eine Schnitzeljagd. Welche Option Sie auch wählen, notieren Sie die Zone, die Resolver-Adresse und die Route, die die Abfrage trägt.

Testen Sie den API-Endpunkt, nicht nur den Namen

Sobald die Abfrage gelingt, rufen Sie den Versions-Endpunkt der API mit dem Cluster-CA ab. curl --cacert ca.crt https://api.internal.example:6443/version trennt TLS- und Autorisierungsfehler von DNS. Ein 403 bedeutet, dass Name und Verbindung funktionieren und die Identität nicht.

Prüfen Sie außerdem, ob der Client-Adressbereich von den autorisierten Netzwerken oder der Firewall des Clusters zugelassen ist. Private Cluster akzeptieren API-Verkehr oft nur aus dem VNet oder aus Peering-Bereichen, sodass ein Tunnel, der Adressen aus einem anderen Pool vergibt, auf der Netzwerkebene verbindet und an der API verworfen wird.

Notieren Sie vier Fakten, wenn Sie eskalieren: den Resolver, den der Client verwendet hat, die Adresse, die er zurückgegeben hat, die Server-URL im ausgewählten kubeconfig-Kontext und den ersten Vorgang, der fehlgeschlagen ist. Dieser Datensatz sagt dem nächsten Engineer, ob DNS, Routing oder Firewall-Richtlinie geändert werden muss, und er beendet die nächste hosts-Datei-Bearbeitung.

Beginnen Sie mit der Abfrage, wählen Sie den Resolver-Pfad, der dazu passt, wer die Zone besitzt, und prüfen Sie dann den Endpunkt. Wenn alle drei bestehen, ist das verbleibende Problem die Autorisierung, nicht die Namensauflösung.