kubectl ma jistax isolvi l-API tal-cluster privat permezz ta’ OpenVPN

kubectl ifalli fit-tfittxija tal-isem waqt li t-tunnel huwa attiv u l-indirizz privat tal-API għadu jwieġeb il-ping. Ir-rotta hija tajba; il-klijent qed jistaqsi resolver li qatt ma sema’ biż-żona privata tal-cluster. Jiġu użati l-aktar żewġ tiswijiet: tibgħat ir-resolver tan-netwerk virtwali lil kull klijent VPN, jew tiffissa l-isem lokalment b’entrata hosts jew forwarder kondizzjonali. Dawn isolvu l-istess sintomu b’responsabbiltà differenti, u li tħallathom huwa kif it-timijiet jispiċċaw jeditaw fajls hosts kull darba li endpoint jerġa’ jinbena.

Is-soluzzjoni u l-aċċessibilità jfallu f’saffi differenti

Agħmel it-tfittxija int stess qabel ma tbiddel xejn. getent hosts fuq Linux jew nslookup fuq Windows jgħidlek jekk il-klijent jirċevix tweġiba xejn; timeout jew NXDOMAIN jindikaw ir-resolver, filwaqt li tweġiba bl-indirizz ħażin tindika rekord antik jew ħruġ pubbliku.

Imbagħad ivverifika liema server kubectl tassew iċempel. Kuntest kubeconfig jaħżen URL, u rotta VPN ma terġax tikitha: jekk il-kuntest isemmi endpoint pubbliku, id-DNS jista’ jkun perfett u l-kmand xorta jfalli.

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

It-tielet sinjal hija l-forma tal-falliment wara t-tfittxija. Isem li jiġi solvut għall-indirizz privat u mbagħad isib timeout TCP hija problema ta’ firewall jew netwerk awtorizzat. Isem li jiġi solvut għal indirizz pubbliku jfisser li t-talba ħarbet miż-żona privata. Żomm dawn it-tliet eżiti separati; kull wieħed iwasslek għand min hu responsabbli differenti.

Għażla A: ibgħat ir-resolver tan-netwerk virtwali fit-tunnel

Meta s-server VPN jaħdem ġewwa n-netwerk virtwali, il-klijenti jistgħu jużaw l-istess resolver bħall-host tas-server. F’OpenVPN Community is-server jibgħat għażla DNS; Access Server juri l-istess setting fl-interface amministrattiva, u l-klijenti jridu jniżżlu l-profil mill-ġdid għax id-direttiva DNS tivvjaġġa ġo fih.

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

Il-linja tar-rotta hija importanti fil-profili split tunnel. Li tibgħat indirizz ta’ resolver mhuwiex l-istess bħallik tagħmlu aċċessibbli: jekk is-subnet tal-cluster biss tgħaddi mit-tunnel, it-talba għal 10.0.0.4 toħroġ mil-LAN lokali u tmut. Ibgħat rotta host għar-resolver, jew inkludi s-subnet tiegħu fit-tunnel.

In-naħa li tirċievi għandha wkoll politika. Resolver aċċessibbli mill-firxa tal-indirizzi tal-klijent xorta jista’ jirrifjuta talbiet minnha, u żona privata marbuta man-netwerk virtwali twieġeb biss lill-klijenti li jaslu mill-passaġġ DNS ta’ dak in-netwerk. Jekk it-tfittxija tagħti timeout wara l-bgħit, iċċekkja l-logs tar-resolver stess qabel ma terġa’ tmiss il-klijent.

Fuq il-klijent, ivverifika x’ġie applikat: resolvectl status fuq Linux systemd-resolved, scutil --dns fuq macOS, ipconfig /all fuq Windows. Server DNS mibgħut li qatt ma jidher ifisser li l-profil ma ġiex rilokat.

Għażla B: entrati hosts u forwarding kondizzjonali

Entrata hosts hija l-iżgħar tiswija possibbli u l-aktar fraġli. Tippjana isem wieħed għal indirizz wieħed fuq magna waħda, għalhekk taħdem għal demo u tinkiser meta l-endpoint privat jew l-IP tiegħu jerġa’ jinbena. Tistaħbi wkoll il-vojt reali mill-bqija tat-tim.

Forwarder kondizzjonali jiskala aħjar mingħajr ma jibgħat DNS lil kull klijent. dnsmasq jista’ jibgħat żona waħda lir-resolver tal-VNet u jħalli kollox ieħor kwiet: server=/cluster.internal/10.0.0.4. Id-DNS ta’ Windows għandu forwarders kondizzjonali, u l-klijenti ta’ Windows jistgħu jużaw regola NRPT għall-istess qsim. Il-forwarder xorta jeħtieġ rotta lejn ir-resolver tal-VNet.

Il-forwarding iżomm il-browsing normali lokali, li huwa importanti fis-split tunnel. Jagħtik ukoll post wieħed biex tirreġistra t-talbiet taż-żona privata, u post wieħed li jinkiser meta l-host tal-forwarder jiċċaqlaq.

Agħżel skont ir-responsabbiltà, mhux skont il-kumdità

Ibgħat ir-resolver meta tikkontrolla l-profil VPN u trid li kull isem privat jaħdem, mhux biss l-API. Agħżel forwarder meta l-klijenti jridu jżommu d-DNS lokali għal kollox ieħor, jew meta l-VPN jiġi amministrat minn tim differenti mill-cluster.

L-entrati hosts huma dijanjostika, mhux varar. Uża waħda biex tipprova li l-API hija aċċessibbli, imbagħad neħħiha u sewwi l-mogħdija tar-resolver; jekk tħalliha hemmhekk tinbidel mistoqsija ta’ routing fi tiftixa ta’ teżor aktar tard. Liema għażla tagħżel, innota ż-żona, l-indirizz tar-resolver u r-rotta li ġġorr it-talba.

Iċċekkja l-endpoint tal-API, mhux biss l-isem

Ladarba t-tfittxija tirnexxi, ġib l-endpoint tal-verżjoni tal-API bis-CA tal-cluster. curl --cacert ca.crt https://api.internal.example:6443/version jifred il-fallimenti TLS u ta’ awtorizzazzjoni mid-DNS. 403 ifisser li l-isem u l-konnessjoni jaħdmu u l-identità le.

Iċċekkja wkoll jekk il-firxa tal-indirizzi tal-klijent hijiex permessa min-netwerks awtorizzati jew mill-firewall tal-cluster. Il-clusters privati spiss jaċċettaw traffiku tal-API biss mill-VNet jew minn firxiet peer, għalhekk tunnel li jassenja indirizzi minn pool ieħor jikkonnettja fis-saff tan-netwerk u jiġi miċħud fl-API.

Innota erba’ fatti meta tescala: ir-resolver li uża l-klijent, l-indirizz li rritorna, l-URL tas-server fil-kuntest kubeconfig magħżul, u l-ewwel operazzjoni li falliet. Dak ir-rekord jgħid lill-inġinier li jmiss jekk għandux ibiddel id-DNS, ir-routing jew il-politika tal-firewall, u jwaqqaf l-edizzjoni li jmiss tal-fajl hosts.

Ibda bit-tfittxija, agħżel il-mogħdija tar-resolver li taqbel ma’ min jippossjedi ż-żona, imbagħad ivverifika l-endpoint. Jekk it-tlieta jgħaddu, il-problema li tibqa’ hija awtorizzazzjoni, mhux soluzzjoni tal-ismijiet.