kubectl ei suuda privaatse klastri API-t OpenVPN-i kaudu lahendada

kubectl ebaõnnestub nimeotsingul, kuigi tunnel on üleval ja API privaatne aadress vastab endiselt pingile. Marsruut on korras; klient küsib lahendajalt, kes ei ole klastri privaatsest tsoonist kunagi kuulnud. Kõige sagedamini kasutatakse kahte parandust: saata virtuaalvõrgu lahendaja igale VPN-kliendile või kinnitada nimi kohapeal hosts-kirje või tingimusliku edastajaga. Need lahendavad sama sümptomi erineva vastutusega ja nende segiajamine viib selleni, et meeskonnad muudavad hosts-faile iga kord, kui lõpp-punkt uuesti luuakse.

Nimelahendus ja kättesaadavus ebaõnnestuvad erinevates kihtides

Tehke otsing ise enne, kui midagi muudate. getent hosts Linuxis või nslookup Windowsis ütleb, kas klient saab üldse vastuse; aegumine või NXDOMAIN viitab lahendajale, vale aadressiga vastus aga vananenud kirjele või avalikule läbipääsule.

Seejärel kinnitage, millise serveriga kubectl tegelikult ühendub. kubeconfig-i kontekst salvestab URL-i ja VPN-i marsruut ei kirjuta seda ümber: kui kontekst nimetab avalikku lõpp-punkti, võib DNS olla täiuslik ja käsk siiski ebaõnnestuda.

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

Kolmas signaal on vea kuju pärast otsingut. Nimi, mis lahendub privaatsele aadressile ja millele järgneb TCP aegumine, on tulemüüri või autoriseeritud võrgu probleem. Nimi, mis lahendub avalikule aadressile, tähendab, et päring pääses privaatsest tsoonist välja. Hoidke need kolm tulemust lahus; igaüks viib teid erineva omaniku juurde.

Valik A: saada virtuaalvõrgu lahendaja tunnelisse

Kui VPN-server töötab virtuaalvõrgu sees, saavad kliendid kasutada sama lahendajat kui serveri host. OpenVPN Communitys saadab server DNS-valiku; Access Server näitab sama sätet haldusliideses ja kliendid peavad profiili uuesti alla laadima, sest DNS-direktiiv liigub selle sees.

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

Marsruudirida on split-tunnel-profiilide puhul oluline. Lahendaja aadressi saatmine ei ole sama, mis selle kättesaadavaks muutmine: kui tunnelist läbib ainult klastri alamvõrk, väljub päring aadressile 10.0.0.4 kohaliku LAN-i kaudu ja sureb. Saatke lahendajale host-marsruut või lisage selle alamvõrk tunnelisse.

Vastuvõtval poolel on samuti poliitika. Kliendi aadressivahemikust kättesaadav lahendaja võib sealt päringuid siiski keelduda ja virtuaalvõrguga seotud privaatne tsoon vastab ainult klientidele, kes saabuvad selle võrgu DNS-teed pidi. Kui otsing pärast saatmist aegub, kontrollige enne kliendi uuesti puudutamist lahendaja enda logisid.

Kliendis kontrollige, mida rakendati: resolvectl status systemd-resolved Linuxis, scutil --dns macOS-is, ipconfig /all Windowsis. Saadetud DNS-server, mis kunagi ei ilmu, tähendab, et profiili ei laaditud uuesti.

Valik B: hosts-kirjed ja tingimuslik edastamine

hosts-kirje on väikseim võimalik parandus ja kõige hapram. See vastendab ühe nime ühe aadressiga ühes masinas, nii et see töötab demo jaoks ja läheb katki, kui privaatne lõpp-punkt või selle IP uuesti luuakse. See varjab ka tegelikku lünka ülejäänud meeskonna eest.

Tingimuslik edastaja skaleerub paremini, ilma et DNS-i igale kliendile saadetaks. dnsmasq saab saata ühe tsooni VNet-i lahendajale ja jätta kõik muu rahule: server=/cluster.internal/10.0.0.4. Windowsi DNS-is on tingimuslikud edastajad ja Windowsi kliendid saavad sama jaotuse jaoks kasutada NRPT-reeglit. Edastaja vajab endiselt marsruuti VNet-i lahendajani.

Edastamine hoiab tavapärase sirvimise kohalikuna, mis on split tunnelil oluline. See annab teile ka ühe koha privaatse tsooni päringute logimiseks ja ühe koha, mis läheb katki, kui edastaja host liigub.

Valige omandi, mitte mugavuse järgi

Saatke lahendaja siis, kui kontrollite VPN-profiili ja soovite, et töötaks iga privaatne nimi, mitte ainult API. Valige edastaja siis, kui kliendid peavad kogu muu jaoks säilitama kohaliku DNS-i, või kui VPN-i haldab klastrist erinev meeskond.

hosts-kirjed on diagnostika, mitte juurutamine. Kasutage üht, et tõestada API kättesaadavust, seejärel eemaldage see ja parandage lahendaja tee; selle allesjätmine muudab marsruudiküsimuse hiljem aardejahiks. Ükskõik millise valiku teete, kirjutage üles tsoon, lahendaja aadress ja marsruut, mis päringut kannab.

Testige API lõpp-punkti, mitte ainult nime

Kui otsing õnnestub, hankige API versiooni lõpp-punkt klastri CA-ga. curl --cacert ca.crt https://api.internal.example:6443/version eraldab TLS-i ja autoriseerimise vead DNS-ist. 403 tähendab, et nimi ja ühendus töötavad ning identiteet mitte.

Kontrollige ka, kas kliendi aadressivahemikku lubavad klastri autoriseeritud võrgud või tulemüür. Privaatsed klastrid aktsepteerivad API-liiklust sageli ainult VNet-ist või peeritud vahemikest, nii et teisest poolist aadresse määrav tunnel ühendub võrgukihis ja visatakse API juures kõrvale.

Eskaleerimisel kirjutage üles neli fakti: lahendaja, mida klient kasutas, aadress, mille see tagastas, serveri URL valitud kubeconfig-i kontekstis ja esimene nurjunud toiming. See kirje ütleb järgmisele insenerile, kas muuta DNS-i, marsruutimist või tulemüüri poliitikat, ja peatab järgmise hosts-faili muutmise.

Alustage otsingust, valige lahendaja tee, mis vastab sellele, kellele tsoon kuulub, seejärel kontrollige lõpp-punkti. Kui kõik kolm läbivad, on järelejäänud probleem autoriseerimine, mitte nimelahendus.