kubectl kan nie die privaat cluster-API oor OpenVPN oplos nie

kubectl misluk met naamopsoek terwyl die tonnel op is en die API se privaat adres steeds op ’n ping antwoord. Die roete is reg; die kliënt vra ’n oplosser wat nog nooit van die cluster se privaat sone gehoor het nie. Twee regstellings word die meeste gebruik: stuur die virtuele netwerk se oplosser na elke VPN-kliënt, of pen die naam plaaslik vas met ’n hosts-inskrywing of ’n voorwaardelike aanstuurder. Hulle los dieselfde simptoom met verskillende eienaarskap op, en om hulle te verwar is hoe spanne elke keer hosts-lêers regmaak wanneer ’n eindpunt herbou word.

Ontleding en bereikbaarheid faal op verskillende vlakke

Voer die opsoek self uit voordat jy iets verander. getent hosts op Linux of nslookup op Windows vertel jou of die kliënt hoegenaamd ’n antwoord kry; ’n tydsverloop of NXDOMAIN wys na die oplosser, terwyl ’n antwoord met die verkeerde adres na ’n verouderde rekord of ’n publieke deurval wys.

Bevestig dan watter bediener kubectl werklik skakel. ’n kubeconfig-konteks stoor ’n URL, en ’n VPN-roete herskryf dit nie: as die konteks ’n publieke eindpunt noem, kan DNS perfek wees en die opdrag steeds misluk.

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

Die derde sein is die vorm van die mislukking ná die opsoek. ’n Naam wat na die privaat adres oplos en dan deur ’n TCP-tydsverloop gevolg word, is ’n brandmuur- of gemagtigde-netwerk-probleem. ’n Naam wat na ’n publieke adres oplos, beteken die navraag het die privaat sone ontsnap. Hou daardie drie uitkomste apart; elkeen stuur jou na ’n ander eienaar.

Opsie A: stuur die virtuele netwerk se oplosser in die tonnel in

Wanneer die VPN-bediener binne die virtuele netwerk loop, kan kliënte dieselfde oplosser as die bediener-gasheer gebruik. In OpenVPN Community stuur die bediener ’n DNS-opsie; Access Server wys dieselfde instelling in die admin-UI, en kliënte moet die profiel weer aflaai omdat die DNS-richtlijn daarin reis.

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

Die roete-reël maak saak op split-tonnel-profiele. Om ’n oplosser-adres te stuur is nie dieselfde as om dit bereikbaar te maak nie: as net die cluster-subnet deur die tonnel gaan, verlaat die navraag na 10.0.0.4 via die plaaslike LAN en sterf. Stuur ’n gasheerroete vir die oplosser, of sluit sy subnet in die tonnel in.

Die ontvangkant het ook ’n beleid. ’n Oplosser wat vanaf die kliënt-adresreeks bereikbaar is, kan steeds navrae daarvan weier, en ’n privaat sone wat aan die virtuele netwerk gekoppel is, antwoord net kliënte wat via daardie netwerk se DNS-pad aankom. As die opsoek ná die stuur verval, kyk na die oplosser se eie logs voordat jy weer aan die kliënt raak.

Op die kliënt, verifieer wat toegepas is: resolvectl status op systemd-resolved Linux, scutil --dns op macOS, ipconfig /all op Windows. ’n Gestuurde DNS-bediener wat nooit verskyn nie, beteken die profiel is nie herlaai nie.

Opsie B: hosts-inskrywings en voorwaardelike aansturing

’n hosts-inskrywing is die kleinste moontlike regstelling en die broosste. Dit koppel een naam aan een adres op een masjien, so dit werk vir ’n demo en breek wanneer die privaat eindpunt of sy IP herbou word. Dit verberg ook die werklike gaping vir almal anders in die span.

’n Voorwaardelike aanstuurder skaleer beter sonder om DNS na elke kliënt te stuur. dnsmasq kan een sone na die VNet-oplosser stuur en alles anders alleen laat: server=/cluster.internal/10.0.0.4. Windows DNS het voorwaardelike aanstuurders, en Windows-kliënte kan ’n NRPT-reël vir dieselfde splitsing gebruik. Die aanstuurder het steeds ’n roete na die VNet-oplosser nodig.

Aansturing hou normale blaai plaaslik, wat op split-tonnel saak maak. Dit gee jou ook een plek om navrae vir die privaat sone te log, en een plek om te breek wanneer die aanstuurder-gasheer skuif.

Kies volgens eienaarskap, nie volgens gerief nie

Stuur die oplosser wanneer jy die VPN-profiel beheer en wil hê elke privaat naam moet werk, nie net die API nie. Kies ’n aanstuurder wanneer kliënte hul plaaslike DNS vir alles anders moet hou, of wanneer die VPN deur ’n ander span as die cluster bestuur word.

hosts-inskrywings is ’n diagnostikum, nie ’n ontplooiing nie. Gebruik een om te bewys die API is bereikbaar, verwyder dit dan en reg die oplosser-pad; om dit te laat staan verander ’n roetevraag later in ’n skattejag. Watter opsie jy ook kies, skryf die sone, die oplosser-adres en die roete wat die navraag dra neer.

Toets die API-eindpunt, nie net die naam nie

Sodra die opsoek slaag, haal die API se weergawe-eindpunt met die cluster-CA. curl --cacert ca.crt https://api.internal.example:6443/version skei TLS- en magtigingsfoute van DNS. ’n 403 beteken die naam en verbinding werk en die identiteit nie.

Kyk ook of die kliënt-adresreeks deur die cluster se gemagtigde netwerke of brandmuur toegelaat word. Privaat clusters aanvaar dikwels API-verkeer net vanaf die VNet of peered reekse, so ’n tonnel wat adresse uit ’n ander poel toeken, verbind op die netwerklaag en word by die API laat val.

Teken vier feite aan wanneer jy eskaleer: die oplosser wat die kliënt gebruik het, die adres wat dit teruggegee het, die bediener-URL in die gekose kubeconfig-konteks, en die eerste bewerking wat misluk het. Daardie rekord sê vir die volgende ingenieur of DNS, roetering of brandmuurbeleid verander moet word, en dit stop die volgende hosts-lêer-redigering.

Begin met die opsoek, kies die oplosser-pad wat pas by wie die sone besit, verifieer dan die eindpunt. As al drie slaag, is die oorblywende probleem magtiging, nie naamresolusie nie.