kubectl getur ekki leyst API einkaklasans í gegnum OpenVPN

kubectl mistekst við nafnaleit þótt göngin séu virk og einkafang API-sins svari enn pingi. Leiðin er í lagi; biðlarinn spyr leysi sem hefur aldrei heyrt um einkasvæði klasans. Tvær lagfæringar eru algengastar: að ýta leysi sýndarnetsins til hvers VPN-biðlara, eða festa nafnið staðbundið með færslu í hosts eða skilyrtri framsendingu. Þær leysa sömu einkennin með mismunandi ábyrgð, og að rugla þeim saman er hvernig teymi enda á að breyta hosts-skrám í hvert sinn sem endapunktur er endurbyggður.

Upplausn og aðgengi mistekst á mismunandi lögum

Keyrðu leitina sjálfur áður en þú breytir nokkru. getent hosts á Linux eða nslookup á Windows segir þér hvort biðlarinn fái nokkurt svar; tímamörk eða NXDOMAIN benda á leysinn, en svar með röngu vistfangi bendir á úrelta færslu eða opinbera framrás.

Staðfestu síðan hvaða þjóni kubectl hringir í raun. kubeconfig-samhengi geymir URL og VPN-leið endurskrifar hana ekki: ef samhengið nefnir opinn endapunkt getur DNS verið fullkomið og skipunin samt mistekist.

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

Þriðja merkið er lögun mistakans eftir leitina. Nafn sem leysist í einkafangið og fær síðan TCP-tímamörk er vandamál eldveggs eða heimilaðs nets. Nafn sem leysist í opið vistfang þýðir að fyrirspurnin slapp út af einkasvæðinu. Haltu þessum þremur útkomum aðskildum; hver þeirra sendir þig til annars eiganda.

Valkostur A: ýttu leysi sýndarnetsins inn í göngin

Þegar VPN-þjónninn keyrir innan sýndarnetsins geta biðlarar notað sama leysi og þjónsgestgjafinn. Í OpenVPN Community ýtir þjónninn DNS-valkosti; Access Server sýnir sömu stillingu í stjórnviðmótinu og biðlarar verða að sækja sniðið aftur því DNS-tilskipunin ferðast inni í því.

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

Leiðarlínan skiptir máli á split-tunnel-sniðum. Að ýta leysivisti er ekki það sama og að gera hana aðgengilega: ef aðeins undirnet klasans fer í gegnum göngin fer fyrirspurnin á 10.0.0.4 út um staðbundið LAN og deyr. Ýttu gestgjafaleið fyrir leysinn, eða hafðu undirnetið með í göngunum.

Móttökuhliðin hefur líka stefnu. Leysir sem er aðgengilegur frá vistfangasviði biðlarans getur samt synjað fyrirspurnum frá því, og einkasvæði sem er tengt sýndarnetinu svarar aðeins biðlurum sem koma um DNS-leið þess nets. Ef leitin fer á tímamörk eftir ýtinguna skaltu skoða eigin annála leysisins áður en þú snertir biðlarann aftur.

Á biðlaranum skaltu staðfesta hvað var beitt: resolvectl status á systemd-resolved Linux, scutil --dns á macOS, ipconfig /all á Windows. DNS-þjónn sem var ýtt en birtist aldrei þýðir að sniðið var ekki endurhlaðið.

Valkostur B: hosts-færslur og skilyrt framsending

Hosts-færsla er minnsta mögulega lagfæringin og sú brothættasta. Hún varpar einu nafni á eitt vistfang á einni vél, svo hún virkar fyrir kynningu og brotnar þegar einkendapunkturinn eða IP hans er endurbyggður. Hún felur líka raunverulega bilið fyrir restinni af teyminu.

Skilyrt framsending skalar betur án þess að ýta DNS til hvers biðlara. dnsmasq getur sent eitt svæði til leysisins VNet og látið allt annað í friði: server=/cluster.internal/10.0.0.4. Windows DNS hefur skilyrtar framsendingar og Windows-biðlarar geta notað NRPT-reglu fyrir sömu skiptingu. Framsendingin þarf samt leið að leysinum VNet.

Framsending heldur venjulegri vafrun staðbundinni, sem skiptir máli á split tunnel. Hún gefur þér líka einn stað til að skrá fyrirspurnir fyrir einkasvæðið og einn stað sem brotnar þegar gestgjafi framsendingarinnar flyst.

Veldu eftir eignarhaldi, ekki eftir þægindum

Ýttu leysinum þegar þú stýrir VPN-sniðinu og vilt að hvert einkanafn virki, ekki bara API. Veldu framsendingu þegar biðlarar verða að halda staðbundnu DNS fyrir allt annað, eða þegar annað teymi en klasinn stýrir VPN.

hosts-færslur eru greining, ekki uppsetning. Notaðu eina til að sanna að API sé aðgengilegt, fjarlægðu hana síðan og lagaðu leið leysisins; að láta hana vera breytir leiðarspurningu í fjársjóðsleit síðar. Hvaða valkost sem þú velur, skrifaðu niður svæðið, vistfang leysisins og leiðina sem ber fyrirspurnina.

Prófaðu API-endapunktinn, ekki bara nafnið

Þegar leitin tekst skaltu sækja útgáfuendapunkt API-sins með CA klasans. curl --cacert ca.crt https://api.internal.example:6443/version aðgreinir TLS- og heimildarmistök frá DNS. 403 þýðir að nafnið og tengingin virka og auðkennið ekki.

Athugaðu líka hvort vistfangasvið biðlarans sé leyft af heimiluðum netum klasans eða eldvegg. Einkaklasar samþykkja API-umferð oft aðeins frá VNet eða jafningjasviðum, svo göng sem úthluta vistföngum úr öðrum laug tengjast á netlaginu og eru felld á API-inu.

Skráðu fjórar staðreyndir þegar þú gerir mál: leysinn sem biðlarinn notaði, vistfangið sem hann skilaði, URL þjónsins í völdu kubeconfig-samhengi og fyrstu aðgerðina sem mistókst. Þessi skráning segir næsta verkfræðingi hvort breyta eigi DNS, leiðum eða eldveggjarstefnu, og hún stöðvar næstu hosts-skrárbreytingu.

Byrjaðu á leitinni, veldu leið leysisins sem passar við hver á svæðið, og staðfestu síðan endapunktinn. Ef allar þrjár standast er vandamálið sem eftir er heimild, ekki nafnaupplausn.