kubectl ne more razrešiti API zasebnega grozda prek OpenVPN

kubectl spodleti pri iskanju imena, čeprav tunel deluje in zasebni naslov API še vedno odgovarja na ping. Pot je v redu; odjemalec sprašuje resolver, ki ni nikoli slišal za zasebno cono grozda. Najpogosteje se uporabita dva popravka: pošiljanje resolverja virtualnega omrežja vsakemu odjemalcu VPN ali pritrditev imena lokalno z vnosom hosts ali pogojnim posredovalnikom. Rešujeta isto težavo z različno odgovornostjo, njuna zamenjava pa vodi v to, da ekipe urejajo datoteke hosts vsakič, ko je končna točka ponovno zgrajena.

Razreševanje in dosegljivost spodletita na različnih plasteh

Iskanje izvedite sami, preden karkoli spremenite. getent hosts v Linuxu ali nslookup v Windowsu vam pove, ali odjemalec sploh dobi odgovor; časovna omejitev ali NXDOMAIN kaže na resolver, medtem ko odgovor z napačnim naslovom kaže na zastarel zapis ali javni prehod.

Nato potrdite, na kateri strežnik se kubectl dejansko povezuje. Kontekst kubeconfig shrani URL, pot VPN pa ga ne prepiše: če kontekst navaja javno končno točko, je lahko DNS popoln, ukaz pa vseeno spodleti.

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

Tretji signal je oblika napake po iskanju. Ime, ki se razreši v zasebni naslov in mu sledi časovna omejitev TCP, je težava požarnega zidu ali avtoriziranega omrežja. Ime, ki se razreši v javni naslov, pomeni, da je poizvedba ušla iz zasebne cone. Te tri izide hranite ločeno; vsak vas vodi k drugemu lastniku.

Možnost A: pošljite resolver virtualnega omrežja v tunel

Ko strežnik VPN deluje znotraj virtualnega omrežja, lahko odjemalci uporabljajo isti resolver kot gostitelj strežnika. V OpenVPN Community strežnik pošlje možnost DNS; Access Server prikaže isto nastavitev v skrbniškem vmesniku, odjemalci pa morajo profil znova prenesti, ker direktiva DNS potuje v njem.

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

Vrstica poti je pomembna pri profilih split tunnel. Pošiljanje naslova resolverja ni isto kot to, da ga naredite dosegljivega: če skozi tunel gre le podomrežje grozda, poizvedba na 10.0.0.4 zapusti lokalni LAN in umre. Pošljite gostiteljsko pot za resolver ali vključite njegovo podomrežje v tunel.

Tudi sprejemna stran ima pravilnik. Resolver, dosegljiv iz naslovnega obsega odjemalca, lahko poizvedbe iz njega vseeno zavrne, zasebna cona, povezana z virtualnim omrežjem, pa odgovarja le odjemalcem, ki pridejo po poti DNS tega omrežja. Če iskanje po pošiljanju poteče, preglejte lastne dnevnike resolverja, preden se znova dotaknete odjemalca.

Na odjemalcu preverite, kaj je bilo uporabljeno: resolvectl status v Linuxu s systemd-resolved, scutil --dns v macOS, ipconfig /all v Windowsu. Poslan strežnik DNS, ki se nikoli ne pojavi, pomeni, da profil ni bil znova naložen.

Možnost B: vnosi hosts in pogojno posredovanje

Vnos hosts je najmanjši možen popravek in najbolj krhek. Preslika eno ime v en naslov na enem stroju, zato deluje za predstavitev in se pokvari, ko se zasebna končna točka ali njen IP znova zgradi. Skrije tudi resnično vrzel pred preostalo ekipo.

Pogojni posredovalnik se bolje skalira brez pošiljanja DNS vsakemu odjemalcu. dnsmasq lahko pošlje eno cono resolverju VNet in vse drugo pusti pri miru: server=/cluster.internal/10.0.0.4. Windows DNS ima pogojne posredovalnike, odjemalci Windows pa lahko za isto razdelitev uporabijo pravilo NRPT. Posredovalnik še vedno potrebuje pot do resolverja VNet.

Posredovanje ohrani običajno brskanje lokalno, kar je pri split tunelu pomembno. Da vam tudi eno mesto za beleženje poizvedb za zasebno cono in eno mesto, ki se pokvari, ko se gostitelj posredovalnika preseli.

Izberite po odgovornosti, ne po udobju

Pošljite resolver, ko nadzirate profil VPN in želite, da deluje vsako zasebno ime, ne samo API. Izberite posredovalnik, ko morajo odjemalci obdržati lokalni DNS za vse drugo ali ko VPN upravlja druga ekipa kot grozd.

Vnosi hosts so diagnostika, ne uvajanje. Uporabite enega, da dokažete, da je API dosegljiv, nato ga odstranite in popravite pot resolverja; če ga pustite, se vprašanje usmerjanja pozneje spremeni v lov za zakladom. Ne glede na izbrano možnost zapišite cono, naslov resolverja in pot, ki nosi poizvedbo.

Preizkusite končno točko API, ne le imena

Ko iskanje uspe, pridobite končno točko različice API s CA grozda. curl --cacert ca.crt https://api.internal.example:6443/version loči napake TLS in avtorizacije od DNS. 403 pomeni, da ime in povezava delujeta, identiteta pa ne.

Preverite tudi, ali naslovni obseg odjemalca dovoljujejo avtorizirana omrežja ali požarni zid grozda. Zasebni grozdi pogosto sprejemajo promet API le iz VNet ali peered obsegov, zato se tunel, ki dodeljuje naslove iz drugega nabora, poveže na omrežni plasti in je na API zavržen.

Ko eskavirate, zapišite štiri dejstva: resolver, ki ga je uporabil odjemalec, naslov, ki ga je vrnil, URL strežnika v izbranem kontekstu kubeconfig in prvo neuspešno operacijo. Ta zapis pove naslednjemu inženirju, ali spremeniti DNS, usmerjanje ali pravilnik požarnega zidu, in ustavi naslednje urejanje datoteke hosts.

Začnite z iskanjem, izberite pot resolverja, ki ustreza lastniku cone, nato preverite končno točko. Če gredo vse tri skozi, je preostala težava avtorizacija, ne razreševanje imen.