kubectl-ek ezin du cluster pribatuaren APIa OpenVPN bidez ebatzi

kubectl-ek huts egiten du izena bilatzean, tunela martxan dagoen eta APIaren helbide pribatuak oraindik ping-ari erantzuten dion bitartean. Ibilbidea ondo dago; bezeroak clusterraren zona pribatuaz inoiz entzun ez duen ebazle bati galdetzen dio. Bi konponketa erabiltzen dira gehien: sare birtualaren ebazlea VPN bezero bakoitzari bidaltzea, edo izena bertan finkatzea hosts sarrera edo birbidaltzaile baldintzatu batekin. Sintoma bera konpontzen dute jabetza ezberdinarekin, eta biak nahastea da taldeek amaiera-puntu bat berreraikitzen den bakoitzean hosts fitxategiak editatzera iristeko modua.

Ebazpenak eta irisgarritasunak geruza ezberdinetan huts egiten dute

Egin bilaketa zeuk, ezer aldatu aurretik. getent hosts Linux-en edo nslookup Windows-en esaten dizu bezeroak erantzunik jasotzen duen; denbora-muga edo NXDOMAIN ebazlera bideratzen du, eta helbide okerreko erantzunak erregistro zaharkitu edo ihes publiko batera.

Ondoren baieztatu zein zerbitzarira konektatzen den kubectl benetan. kubeconfig testuinguru batek URL bat gordetzen du, eta VPN ibilbide batek ez du berridazten: testuinguruak amaiera-puntu publiko bat izendatzen badu, DNS ezin hobea izan daiteke eta komandoak huts egiten jarraitzen du.

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

Hirugarren seinalea bilaketaren ondorengo hutsegitearen forma da. Helbide pribatura ebazten den izenari TCP denbora-muga jarraitzen badio, suebaki edo sare baimenduko arazoa da. Helbide publiko batera ebazten den izenak esan nahi du kontsultak zona pribatutik ihes egin duela. Eutsi hiru emaitza horiei bereizita; bakoitzak jabe ezberdin batera bidaltzen zaitu.

A aukera: bidali sare birtualaren ebazlea tunelera

VPN zerbitzaria sare birtualaren barruan exekutatzen denean, bezeroek zerbitzariaren ostalariak erabiltzen duen ebazle bera erabil dezakete. OpenVPN Community-n zerbitzariak DNS aukera bat bidaltzen du; Access Serverrek ezarpen bera erakusten du administrazio interfazean, eta bezeroek profila berriro deskargatu behar dute, DNS direktiba haren barruan bidaiatzen duelako.

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

Ibilbide-lerroa garrantzitsua da split tunnel profiletan. Ebazlearen helbide bat bidaltzea ez da hura irisgarri egitea: tunelatik clusterraren azpisarea soilik pasatzen bada, 10.0.0.4-rako kontsultak LAN lokala utzi eta hiltzen da. Bidali ostalari-ibilbide bat ebazlearentzat, edo sartu haren azpisarea tunelera.

Harrera aldeak ere badu politika. Bezeroaren helbide-tartetik irisgarri den ebazle batek hala ere uko egin diezaioke hortik datozen kontsultei, eta sare birtualari lotutako zona pribatu batek sare horren DNS bidean iristen diren bezeroei bakarrik erantzuten die. Bidaltzearen ondoren bilaketak denbora-muga gainditzen badu, begiratu ebazlearen beraren erregistroak, bezeroa berriro ukitu aurretik.

Bezeroan, egiaztatu zer aplikatu zen: resolvectl status systemd-resolved Linux-en, scutil --dns macOS-en, ipconfig /all Windows-en. Inoiz agertzen ez den bidalitako DNS zerbitzari batek profila berriro kargatu ez zela esan nahi du.

B aukera: hosts sarrerak eta birbidalketa baldintzatua

hosts sarrera bat egin daitekeen konponketa txikiena eta hauskorrena da. Izen bat helbide batekin mapatzen du makina batean, beraz demo baterako balio du eta amaiera-puntu pribatua edo haren IPa berreraikitzen denean apurtzen da. Gainera, benetako hutsunea taldekideengandik ezkutatzen du.

Birbidaltzaile baldintzatu batek hobeto eskalatzen du DNS bezero bakoitzari bidali gabe. dnsmasq-ek zona bat VNeteko ebazlera bidal dezake eta gainerako guztia bakean utzi: server=/cluster.internal/10.0.0.4. Windows DNSek birbidaltzaile baldintzatuak ditu, eta Windows bezeroek NRPT araua erabil dezakete banaketa bererako. Birbidaltzaileak oraindik VNeteko ebazlera iristeko ibilbidea behar du.

Birbidaltzeak nabigazio arrunta bertan mantentzen du, eta hori garrantzitsua da split tunelean. Gainera, leku bakarra ematen dizu zona pribatuaren kontsultak erregistratzeko, eta leku bakarra apurtzeko birbidaltzailearen ostalaria lekuz aldatzen denean.

Aukeratu jabetzaren arabera, ez erosotasunaren arabera

Bidali ebazlea VPN profila kontrolatzen duzunean eta izen pribatu guztiek funtziona dezatela nahi duzunean, ez APIak bakarrik. Aukeratu birbidaltzaile bat bezeroek beren DNS lokala gainerako guztirako mantendu behar dutenean, edo VPNa clusterretik ezberdina den talde batek kudeatzen duenean.

hosts sarrerak diagnostikoa dira, ez inplementazioa. Erabili bat APIa irisgarria dela frogatzeko, gero kendu eta konpondu ebazlearen bidea; bertan uzteak ibilbide-kontu bat altxor-bilaketa bihurtzen du geroago. Aukera edozein dela ere, idatzi zona, ebazlearen helbidea eta kontsulta garraiatzen duen ibilbidea.

Probatu APIaren amaiera-puntua, ez izena bakarrik

Bilaketak arrakasta duenean, eskuratu APIaren bertsio amaiera-puntua clusterraren CArekin. curl --cacert ca.crt https://api.internal.example:6443/version DNSetik bereizten ditu TLS eta baimen hutsegiteak. 403 batek esan nahi du izenak eta konexioak funtzionatzen dutela eta identitateak ez.

Egiaztatu ere bezeroaren helbide-tartea clusterraren sare baimenduek edo suebakiak onartzen duen. Cluster pribatuek askotan API trafikoa VNetetik edo parekatutako tarteetatik soilik onartzen dute, beraz beste pool batetik helbideak esleitzen dituen tunel bat sare geruzan konektatzen da eta APIan baztertzen da.

Eskalatzen duzunean, idatzi lau datu: bezeroak erabilitako ebazlea, itzuli zuen helbidea, hautatutako kubeconfig testuinguruko zerbitzariaren URLa eta huts egin zuen lehen eragiketa. Erregistro horrek hurrengo ingeniariari esaten dio DNS, ibilbide edo suebaki politika aldatu behar den, eta hurrengo hosts fitxategi edizioa gelditzen du.

Hasi bilaketarekin, aukeratu zonaren jabearekin bat datorren ebazle bidea, eta gero egiaztatu amaiera-puntua. Hirurak pasatzen badira, gainerako arazoa baimena da, ez izen-ebazpena.