kubectl kan inte lösa upp det privata klustrets API via OpenVPN

kubectl misslyckas med namnsökningen medan tunneln är uppe och API:ets privata adress fortfarande svarar på ping. Rutten är okej; klienten frågar en resolver som aldrig har hört talas om klustrets privata zon. Två åtgärder används mest: att pusha det virtuella nätets resolver till varje VPN-klient, eller att fästa namnet lokalt med en hosts-post eller en villkorad forwarder. De löser samma symptom med olika ägarskap, och att blanda dem är hur team till slut redigerar hosts-filer varje gång en slutpunkt byggs om.

Uppslagning och nåbarhet misslyckas i olika lager

Kör sökningen själv innan du ändrar något. getent hosts på Linux eller nslookup på Windows berättar om klienten överhuvudtaget får ett svar; en timeout eller NXDOMAIN pekar på resolvern, medan ett svar med fel adress pekar på en inaktuell post eller ett offentligt genomsläpp.

Bekräfta sedan vilken server kubectl faktiskt kontaktar. En kubeconfig-kontext lagrar en URL, och en VPN-rutt skriver inte om den: om kontexten anger en offentlig slutpunkt kan DNS vara perfekt och kommandot misslyckas ändå.

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

Den tredje signalen är felets form efter sökningen. Ett namn som löses till den privata adressen och sedan följs av en TCP-timeout är ett brandväggs- eller auktoriserat nätverksproblem. Ett namn som löses till en offentlig adress betyder att frågan slapp ut ur den privata zonen. Håll de tre utfallen åtskilda; var och en leder dig till en annan ägare.

Alternativ A: pusha det virtuella nätets resolver in i tunneln

När VPN-servern körs i det virtuella nätet kan klienter använda samma resolver som servervärden. I OpenVPN Community pushar servern ett DNS-alternativ; Access Server visar samma inställning i administrationsgränssnittet, och klienter måste ladda ner profilen igen eftersom DNS-direktivet färdas inuti den.

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

Ruttraden spelar roll i split-tunnel-profiler. Att pusha en resolveradress är inte samma sak som att göra den nåbar: om bara klustrets subnät går genom tunneln lämnar frågan till 10.0.0.4 det lokala LAN:et och dör. Pusha en värdrutt för resolvern, eller ta med dess subnät i tunneln.

Mottagarsidan har också en policy. En resolver som är nåbar från klientens adressområde kan ändå avvisa frågor därifrån, och en privat zon kopplad till det virtuella nätet svarar bara klienter som kommer via det nätets DNS-väg. Om sökningen tar timeout efter pushen, titta i resolverns egna loggar innan du rör klienten igen.

På klienten, kontrollera vad som tillämpades: resolvectl status på systemd-resolved Linux, scutil --dns på macOS, ipconfig /all på Windows. En pushad DNS-server som aldrig dyker upp betyder att profilen inte laddades om.

Alternativ B: hosts-poster och villkorad vidarebefordran

En hosts-post är den minsta möjliga åtgärden och den mest ömtåliga. Den mappar ett namn till en adress på en maskin, så den fungerar för en demo och går sönder när den privata slutpunkten eller dess IP byggs om. Den döljer också den verkliga luckan för resten av teamet.

En villkorad forwarder skalar bättre utan att pusha DNS till varje klient. dnsmasq kan skicka en zon till VNet-resolvern och lämna allt annat i fred: server=/cluster.internal/10.0.0.4. Windows DNS har villkorade forwarders, och Windows-klienter kan använda en NRPT-regel för samma uppdelning. Forwardern behöver fortfarande en rutt till VNet-resolvern.

Vidarebefordran håller vanligt surfande lokalt, vilket spelar roll i split tunnel. Den ger dig också en plats att logga frågor för den privata zonen, och en plats som går sönder när forwarder-värden flyttar.

Välj efter ägarskap, inte efter bekvämlighet

Pusha resolvern när du styr VPN-profilen och vill att varje privat namn ska fungera, inte bara API:et. Välj en forwarder när klienterna måste behålla sin lokala DNS för allt annat, eller när VPN:et hanteras av ett annat team än klustret.

hosts-poster är en diagnostik, inte en driftsättning. Använd en för att bevisa att API:et är nåbart, ta sedan bort den och reparera resolvervägen; lämnad på plats förvandlas en routingfråga senare till en skattjakt. Vilket alternativ du än väljer, skriv ner zonen, resolveradressen och rutten som bär frågan.

Testa API-slutpunkten, inte bara namnet

När sökningen lyckas, hämta API:ets versionsslutpunkt med klustrets CA. curl --cacert ca.crt https://api.internal.example:6443/version skiljer TLS- och auktoriseringsfel från DNS. En 403 betyder att namnet och anslutningen fungerar och identiteten inte.

Kontrollera också om klientens adressområde tillåts av klustrets auktoriserade nätverk eller brandvägg. Privata kluster accepterar ofta bara API-trafik från VNet eller peer-områden, så en tunnel som delar ut adresser från en annan pool ansluter på nätverkslagret och släpps vid API:et.

Anteckna fyra fakta när du eskalerar: resolvern klienten använde, adressen den returnerade, server-URL:en i den valda kubeconfig-kontexten och den första operationen som misslyckades. Den anteckningen säger till nästa ingenjör om DNS, routing eller brandväggspolicy ska ändras, och den stoppar nästa hosts-filredigering.

Börja med sökningen, välj den resolverväg som matchar vem som äger zonen och verifiera sedan slutpunkten. Om alla tre passerar är det kvarvarande problemet auktorisering, inte namnsökning.