kubectl ne povas solvi la API-on de privata klastero per OpenVPN

kubectl malsukcesas ĉe nomserĉo dum la tunelo funkcias kaj la privata adreso de la API ankoraŭ respondas al ping. La vojo estas en ordo; la kliento demandas solvilon, kiu neniam aŭdis pri la privata zono de la klastero. Du riparoj estas plej uzataj: puŝi la solvilon de la virtuala reto al ĉiu VPN-kliento, aŭ najli la nomon loke per hosts-ero aŭ per kondiĉa plusendaĵo. Ili solvas la saman simptomon kun malsama posedo, kaj miksado de ili estas kial teamoj finas redakti hosts-dosierojn ĉiufoje kiam finpunkto estas rekonstruata.

Solvado kaj atingeblo malsukcesas ĉe malsamaj tavoloj

Faru la serĉon mem antaŭ ol ŝanĝi ion ajn. getent hosts en Linux aŭ nslookup en Windows diras al vi ĉu la kliento entute ricevas respondon; tempolimo aŭ NXDOMAIN montras al la solvilo, dum respondo kun malĝusta adreso montras al kaduka rikordo aŭ publika trairejo.

Poste konfirmu kiun servilon kubectl efektive alvokas. kubeconfig-kunteksto konservas URL-on, kaj VPN-vojo ne reskribas ĝin: se la kunteksto nomas publikan finpunkton, DNS povas esti perfekta kaj la komando tamen malsukcesas.

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

La tria signalo estas la formo de la malsukceso post la serĉo. Nomo, kiu solviĝas al la privata adreso kaj poste trafas TCP-tempolimon, estas problemo de fajroŝirmilo aŭ de rajtigita reto. Nomo, kiu solviĝas al publika adreso, signifas ke la demando eskapis el la privata zono. Tenu tiujn tri rezultojn aparte; ĉiu kondukas vin al alia posedanto.

Opcio A: puŝi la solvilon de la virtuala reto en la tunelon

Kiam la VPN-servilo funkcias ene de la virtuala reto, klientoj povas uzi la saman solvilon kiel la servila gastiganto. En OpenVPN Community la servilo puŝas DNS-opcion; Access Server montras la saman agordon en la administra fasado, kaj klientoj devas denove elŝuti la profilon ĉar la DNS-direktivo vojaĝas ene de ĝi.

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

La voja linio gravas ĉe split-tunnel-profiloj. Puŝi solvilan adreson ne samas kiel igi ĝin atingebla: se nur la klastera subreto iras tra la tunelo, la demando al 10.0.0.4 eliras per la loka LAN kaj mortas. Puŝu gastigan vojon por la solvilo, aŭ inkluzivu ĝian subreton en la tunelon.

Ankaŭ la ricevanta flanko havas politikon. Solvilo atingebla el la klienta adresaro ankoraŭ povas rifuzi demandojn el ĝi, kaj privata zono ligita al la virtuala reto respondas nur al klientoj, kiuj alvenas tra la DNS-vojo de tiu reto. Se la serĉo tempolimas post la puŝo, kontrolu la proprajn protokolojn de la solvilo antaŭ ol denove tuŝi la klienton.

Ĉe la kliento, kontrolu kio estis aplikita: resolvectl status en systemd-resolved Linux, scutil --dns en macOS, ipconfig /all en Windows. Puŝita DNS-servilo, kiu neniam aperas, signifas ke la profilo ne estis reŝargita.

Opcio B: hosts-eroj kaj kondiĉa plusendado

hosts-ero estas la plej malgranda ebla ripareto kaj la plej rompiĝema. Ĝi mapas unu nomon al unu adreso sur unu maŝino, do ĝi funkcias por demonstro kaj rompiĝas kiam la privata finpunkto aŭ ĝia IP estas rekonstruata. Ĝi ankaŭ kaŝas la veran mankon for de la resto de la teamo.

Kondiĉa plusendilo skaliĝas pli bone sen puŝi DNS al ĉiu kliento. dnsmasq povas sendi unu zonon al la VNet-solvilo kaj lasi ĉion alian trankvile: server=/cluster.internal/10.0.0.4. Windows DNS havas kondiĉajn plusendilojn, kaj Windows-klientoj povas uzi NRPT-regulon por la sama disigo. La plusendilo ankoraŭ bezonas vojon al la VNet-solvilo.

Plusendado tenas normalan retumadon loke, kio gravas ĉe split tunnel. Ĝi ankaŭ donas al vi unu lokon por protokoli demandojn por la privata zono, kaj unu lokon por rompiĝi kiam la plusendila gastiganto translokiĝas.

Elektu laŭ posedo, ne laŭ oportuneco

Puŝu la solvilon kiam vi regas la VPN-profilon kaj volas ke ĉiu privata nomo funkciu, ne nur la API. Elektu plusendilon kiam klientoj devas konservi sian lokan DNS por ĉio alia, aŭ kiam la VPN estas administrata de alia teamo ol la klastero.

hosts-eroj estas diagnozo, ne deplojo. Uzu unu por pruvi ke la API estas atingebla, poste forigu ĝin kaj riparu la solvilan vojon; lasi ĝin en loko transformas vojan demandon en ĉasadon poste. Kiun ajn opcion vi elektos, notu la zonon, la solvilan adreson kaj la vojon, kiu portas la demandon.

Testu la API-finpunkton, ne nur la nomon

Post kiam la serĉo sukcesas, prenu la versian finpunkton de la API per la klastera CA. curl --cacert ca.crt https://api.internal.example:6443/version apartigas TLS- kaj rajtigajn malsukcesojn de DNS. 403 signifas ke la nomo kaj konekto funkcias kaj la identeco ne.

Kontrolu ankaŭ ĉu la klienta adresaro estas permesata de la rajtigitaj retoj aŭ fajroŝirmilo de la klastero. Privataj klasteroj ofte akceptas API-trafikon nur el la VNet aŭ el kunligitaj adresaroj, do tunelo, kiu asignas adresojn el alia baseno, konektiĝas ĉe la reta tavolo kaj estas forĵetata ĉe la API.

Notu kvar faktojn kiam vi eskalas: la solvilon, kiun la kliento uzis, la adreson, kiun ĝi redonis, la servilan URL-on en la elektita kubeconfig-kunteksto, kaj la unuan operacion, kiu malsukcesis. Tiu rikordo diras al la sekva inĝeniero ĉu ŝanĝi DNS, vojigon aŭ fajroŝirmilan politikon, kaj ĝi haltigas la sekvan hosts-dosieran redakton.

Komencu per la serĉo, elektu la solvilan vojon kongruan kun tiu, kiu posedas la zonon, poste kontrolu la finpunkton. Se ĉiuj tri pasas, la restanta problemo estas rajtigo, ne nomsolvado.