kubectl nuk mund të zgjidhë API-n e klasterit privat përmes OpenVPN

kubectl dështon në kërkimin e emrit ndërsa tuneli është aktiv dhe adresa private e API-së vazhdon t’i përgjigjet ping-ut. Rruga është në rregull; klienti pyet një zgjidhës që nuk ka dëgjuar kurrë për zonën private të klasterit. Dy rregullime përdoren më shumë: dërgimi i zgjidhësit të rrjetit virtual te çdo klient VPN, ose fiksimi i emrit lokalisht me një shënim hosts ose një përcjellës të kushtëzuar. Ato zgjidhin të njëjtin simptom me pronësi të ndryshme, dhe përzierja e tyre është mënyra se si ekipet përfundojnë duke redaktuar skedarë hosts sa herë që një pikë fundore rindërtohet.

Zgjidhja dhe arrishmëria dështojnë në shtresa të ndryshme

Kryeni vetë kërkimin përpara se të ndryshoni diçka. getent hosts në Linux ose nslookup në Windows ju tregon nëse klienti merr ndonjë përgjigje; një timeout ose NXDOMAIN tregojnë zgjidhësin, ndërsa një përgjigje me adresë të gabuar tregon një regjistrim të vjetëruar ose një kalim publik.

Pastaj konfirmoni cilit server i lidhet vërtet kubectl. Një kontekst kubeconfig ruan një URL, dhe një rrugë VPN nuk e rishkruan atë: nëse konteksti përmend një pikë fundore publike, DNS mund të jetë i përsosur dhe komanda përsëri dështon.

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

Sinjali i tretë është forma e dështimit pas kërkimit. Një emër që zgjidhet në adresën private dhe pastaj pëson një timeout TCP është problem i firewall-it ose i rrjetit të autorizuar. Një emër që zgjidhet në një adresë publike do të thotë që kërkesa iku nga zona private. Mbani këto tre rezultate të ndara; secili ju çon te një pronar tjetër.

Opsioni A: dërgoni zgjidhësin e rrjetit virtual në tunel

Kur serveri VPN ekzekutohet brenda rrjetit virtual, klientët mund të përdorin të njëjtin zgjidhës si hosti i serverit. Në OpenVPN Community serveri dërgon një opsion DNS; Access Server shfaq të njëjtën cilësim në ndërfaqen e administrimit, dhe klientët duhet ta shkarkojnë profilin përsëri sepse direktiva DNS udhëton brenda tij.

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

Rreshti i rrugës ka rëndësi në profilet split tunnel. Dërgimi i një adrese zgjidhësi nuk është e njëjta gjë me bërjen e saj të arrishme: nëse vetëm nënrrjeti i klasterit kalon nëpër tunel, kërkesa për 10.0.0.4 del përmes LAN-it lokal dhe vdes. Dërgoni një rrugë hosti për zgjidhësin, ose përfshini nënrrjetin e tij në tunel.

Edhe ana marrëse ka një politikë. Një zgjidhës i arrishëm nga diapazoni i adresave të klientit mund të refuzojë përsëri kërkesat prej tij, dhe një zonë private e lidhur me rrjetin virtual u përgjigjet vetëm klientëve që vijnë përmes rrugës DNS të atij rrjeti. Nëse kërkimi skadon pas dërgimit, shikoni regjistrat e vetë zgjidhësit përpara se të prekni përsëri klientin.

Në klient, verifikoni çfarë u zbatua: resolvectl status në Linux me systemd-resolved, scutil --dns në macOS, ipconfig /all në Windows. Një server DNS i dërguar që nuk shfaqet kurrë do të thotë që profili nuk u ringarkua.

Opsioni B: shënime hosts dhe përcjellje e kushtëzuar

Një shënim hosts është rregullimi më i vogël i mundshëm dhe më i brishtë. Ai harton një emër në një adresë në një makinë, kështu që funksionon për një demonstrim dhe prishet kur pika fundore private ose IP-ja e saj rindërtohet. Ai gjithashtu fsheh boshllëkun e vërtetë nga pjesa tjetër e ekipit.

Një përcjellës i kushtëzuar shkallëzohet më mirë pa dërguar DNS te çdo klient. dnsmasq mund të dërgojë një zonë te zgjidhësi i VNet dhe të lërë gjithçka tjetër në paqe: server=/cluster.internal/10.0.0.4. DNS i Windows ka përcjellës të kushtëzuar, dhe klientët Windows mund të përdorin një rregull NRPT për të njëjtën ndarje. Përcjellësi përsëri ka nevojë për një rrugë drejt zgjidhësit të VNet.

Përcjellja e mban shfletimin normal lokal, gjë që ka rëndësi në split tunnel. Ju jep gjithashtu një vend të vetëm për të regjistruar kërkesat e zonës private, dhe një vend të vetëm që prishet kur hosti i përcjellësit zhvendoset.

Zgjidhni sipas pronësisë, jo sipas komoditetit

Dërgoni zgjidhësin kur kontrolloni profilin VPN dhe dëshironi që çdo emër privat të funksionojë, jo vetëm API-ja. Zgjidhni një përcjellës kur klientët duhet të mbajnë DNS-në e tyre lokale për gjithçka tjetër, ose kur VPN-në e menaxhon një ekip tjetër nga klasteri.

Shënimet hosts janë diagnostikim, jo vendosje. Përdorni një për të provuar që API-ja është e arrishme, pastaj hiqeni dhe rregulloni rrugën e zgjidhësit; lënia e saj në vend e kthen një pyetje rrugëtimi në një gjueti thesari më vonë. Cilindo opsion të zgjidhni, shkruani zonën, adresën e zgjidhësit dhe rrugën që mbart kërkesën.

Provoni pikën fundore të API-së, jo vetëm emrin

Kur kërkimi të ketë sukses, merrni pikën fundore të versionit të API-së me CA-në e klasterit. curl --cacert ca.crt https://api.internal.example:6443/version ndan dështimet TLS dhe të autorizimit nga DNS. Një 403 do të thotë që emri dhe lidhja funksionojnë dhe identiteti jo.

Kontrolloni gjithashtu nëse diapazoni i adresave të klientit lejohet nga rrjetet e autorizuara ose firewall-i i klasterit. Klasterët privatë shpesh pranojnë trafik API vetëm nga VNet ose diapazonet peer, kështu që një tunel që cakton adresa nga një pishinë tjetër lidhet në shtresën e rrjetit dhe hidhet në API.

Shënoni katër fakte kur eskaloni: zgjidhësin që përdori klienti, adresën që ktheu, URL-në e serverit në kontekstin kubeconfig të zgjedhur dhe operacionin e parë që dështoi. Ai regjistrim i thotë inxhinierit tjetër nëse duhet ndryshuar DNS, rrugëtimi ose politika e firewall-it, dhe ndalon redaktimin e radhës të skedarit hosts.

Filloni me kërkimin, zgjidhni rrugën e zgjidhësit që përputhet me atë që zotëron zonën, pastaj verifikoni pikën fundore. Nëse të tre kalojnë, problemi i mbetur është autorizimi, jo zgjidhja e emrave.