kubectl kan de private cluster-API niet via OpenVPN resolven

kubectl faalt bij het opzoeken van de naam terwijl de tunnel actief is en het private adres van de API nog op een ping reageert. De route is in orde; de client vraagt een resolver die nog nooit van de private zone van het cluster heeft gehoord. Twee oplossingen worden het meest gebruikt: de resolver van het virtuele netwerk naar elke VPN-client pushen, of de naam lokaal vastpinnen met een hosts-regel of een conditionele forwarder. Ze verhelpen hetzelfde symptoom met een andere verantwoordelijkheid, en ze door elkaar halen is hoe teams hosts-bestanden aanpassen telkens als een endpoint opnieuw wordt gebouwd.

Resolutie en bereikbaarheid falen op verschillende lagen

Voer de opzoeking zelf uit voordat u iets wijzigt. getent hosts op Linux of nslookup op Windows vertelt u of de client überhaupt een antwoord krijgt; een time-out of NXDOMAIN wijst op de resolver, terwijl een antwoord met het verkeerde adres op een verouderde record of een publieke doorval wijst.

Bevestig daarna welke server kubectl werkelijk benadert. Een kubeconfig-context bewaart een URL, en een VPN-route herschrijft die niet: als de context een publiek endpoint noemt, kan DNS perfect zijn en faalt de opdracht alsnog.

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

Het derde signaal is de vorm van de fout na de opzoeking. Een naam die naar het private adres resolvet en daarna een TCP time-out krijgt, is een firewall- of geautoriseerd-netwerkprobleem. Een naam die naar een publiek adres resolvet, betekent dat de query uit de private zone is ontsnapt. Houd die drie uitkomsten apart; elk brengt u bij een andere eigenaar.

Optie A: de resolver van het virtuele netwerk in de tunnel pushen

Wanneer de VPN-server in het virtuele netwerk draait, kunnen clients dezelfde resolver gebruiken als de serverhost. In OpenVPN Community pusht de server een DNS-optie; Access Server toont dezelfde instelling in de beheerinterface, en clients moeten het profiel opnieuw downloaden omdat de DNS-instructie erin meereist.

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

De routelijn is belangrijk bij split-tunnel-profielen. Een resolveradres pushen is niet hetzelfde als het bereikbaar maken: als alleen het subnet van het cluster door de tunnel gaat, verlaat de query naar 10.0.0.4 het lokale LAN en sterft. Push een hostroute voor de resolver, of neem het subnet ervan op in de tunnel.

De ontvangende kant heeft ook beleid. Een resolver die bereikbaar is vanuit het adresbereik van de client kan query’s ervandaan alsnog weigeren, en een private zone die aan het virtuele netwerk is gekoppeld, antwoordt alleen clients die via het DNS-pad van dat netwerk binnenkomen. Als de opzoeking na de push in een time-out loopt, bekijk dan de eigen logs van de resolver voordat u de client opnieuw aanraakt.

Controleer op de client wat er is toegepast: resolvectl status op systemd-resolved Linux, scutil --dns op macOS, ipconfig /all op Windows. Een gepushte DNS-server die nooit verschijnt, betekent dat het profiel niet opnieuw is geladen.

Optie B: hosts-regels en conditionele forwarding

Een hosts-regel is de kleinst mogelijke oplossing en de meest breekbare. Hij koppelt één naam aan één adres op één machine, dus hij werkt voor een demo en breekt wanneer het private endpoint of het IP ervan opnieuw wordt gebouwd. Hij verbergt ook de echte kloof voor de rest van het team.

Een conditionele forwarder schaalt beter zonder DNS naar elke client te pushen. dnsmasq kan één zone naar de VNet-resolver sturen en al het andere met rust laten: server=/cluster.internal/10.0.0.4. Windows DNS heeft conditionele forwarders, en Windows-clients kunnen een NRPT-regel gebruiken voor dezelfde splitsing. De forwarder heeft nog steeds een route naar de VNet-resolver nodig.

Forwarding houdt normaal browsen lokaal, wat bij split tunnel uitmaakt. Het geeft u ook één plek om query’s voor de private zone te loggen, en één plek die breekt wanneer de forwarderhost verhuist.

Kies op basis van eigenaarschap, niet van gemak

Push de resolver wanneer u het VPN-profiel beheert en wilt dat elke private naam werkt, niet alleen de API. Kies een forwarder wanneer clients hun lokale DNS voor al het andere moeten behouden, of wanneer de VPN door een ander team dan het cluster wordt beheerd.

hosts-regels zijn een diagnose, geen uitrol. Gebruik er een om te bewijzen dat de API bereikbaar is, verwijder hem daarna en repareer het resolvenpad; laten staan verandert een routingvraag later in een speurtocht. Welke optie u ook kiest, noteer de zone, het resolveradres en de route die de query draagt.

Test het API-endpoint, niet alleen de naam

Zodra de opzoeking slaagt, haal het versie-endpoint van de API op met de CA van het cluster. curl --cacert ca.crt https://api.internal.example:6443/version scheidt TLS- en autorisatiefouten van DNS. Een 403 betekent dat de naam en de verbinding werken en de identiteit niet.

Controleer ook of het adresbereik van de client is toegestaan door de geautoriseerde netwerken of de firewall van het cluster. Private clusters accepteren API-verkeer vaak alleen vanuit de VNet of peered bereiken, dus een tunnel die adressen uit een andere pool toekent, verbindt op de netwerklaag en wordt bij de API gedropt.

Noteer vier feiten wanneer u escaleert: de resolver die de client gebruikte, het adres dat die teruggaf, de server-URL in de geselecteerde kubeconfig-context en de eerste bewerking die faalde. Dat verslag vertelt de volgende engineer of DNS, routing of firewallbeleid moet veranderen, en het stopt de volgende hosts-bestandsbewerking.

Begin met de opzoeking, kies het resolvenpad dat past bij wie de zone bezit, en verifieer daarna het endpoint. Als alle drie slagen, is het resterende probleem autorisatie, niet naamresolutie.