Kuberneteseko OpenVPN pod batek ez du ezer birbidaltzen? Egiaztatu ip_forward

Zure eramangarriak tunel berde bat erakusten du, bezeroaren erregistroak bideak bultzatu zirela dio, eta erantzuten duen helbide bakarra VPN zerbitzariaren bere tunel IPa da. Haren ondoko ping-ak hiltzen dira edozein helburu izanik ere, ClusterIP bat, beste pod baten helbidea edo ostalari-izen publiko bat. Konbinazio hori diagnostikoa da, ez lausoa: deskapsulatzeak funtzionatzen du, eta bigarren jauziak ez.

Debian nodo batean topatu nuen hau, chart bidez instalatutako OpenVPN irudi batekin, eta tunela zati erraza zen. Bezeroak 10.8.0.x errenta hartu zuen, 10.8.0.1ek erantzun zuen, eta 10.96.0.10ek, klusterreko DNS zerbitzuak, denbora agortu zuen. Zerbitzariaren erregistroan ezerk ez zirudien gaixorik, eta horregatik hasten dira jendea inoiz ukitu behar ez zituzten iptables arauak berridazten.

VPN pod bat bideratzailea da, eta merezi du hori argi esatea. Pakete zifratuak iristen dira, podaren beraren sare-namespacean deskapsulatzen dira, eta gero beste interfaze batetik irten behar dute. Linuxek bigarren urrats hori ukatzen du namespace horretan bertan birbidalketa gaituta ez badago.

Zer irits dezakeen bezeroak eta zer ez

Erantzuten duen helbidea tunelaren muturrekoa da, eta VPN prozesuak tokian bertan dauka, beraz birbidalketak ez du parte hartzen. Gainerako guztiak, beste pod bat, zerbitzu VIP bat edo internet barne, kernelak pakete bat tun0(e)tik eth0(e)ra mugitzea behar du. Mugimendu hori ukatzen denean, sintoma isiltasun uniformea da, ez ukapena, ezerk ez duelako ICMP errore bat sortzen tunelaren behera. Denbora-mugak jasotzen dituzu, ez helbideraezin mezuak, eta hori da inor batere bideratzen ari ez den arrastoa.

Bi minutuko sailkapenak geruza estutzen du. DNS izenek huts egiten badute zerbitzu IP baterako ping gordinek funtzionatzen duten bitartean, arazoa DNS iturgintzan dago, ez birbidalketan. Peer helbideaz haraindiko helmuga guztiek denbora agortzen badute, IP soil bat barne, hasi namespacean.

Irakurri ezarpena namespacearen barruan

Pod bakoitzak bere sare-namespacea lortzen du, eta net.ipv4.ip_forward namespace bakoitzeko sysctl bat da. Nodoan aldatzeak ez dizu ezer esaten edukiontziari buruz, eta modu fidagarria da arratsalde bat makina okerrean igarotzeko.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

Zero batek diagnosia berresten du. Balioa ez da nodoaren exekuzio-konfiguraziotik heredatzen ere: irudiaren lehenetsitik hasten da edukiontzi bat sortzen den bakoitzean. Beraz, kubectl exec ... sysctl -w erabiliz eskuz aplikatutako konponketa hurrengo berrabiaraztean desagertzen da eta noizean behin agertzen den akats gisa itzultzen da.

Hori gaitzea manifestuak mantendu dezan

Aukera iraunkorra pod sandbox berean exekutatzen den init edukiontzi bat da, balioa VPN edukiontzia hasi aurretik idazten duena. Pod bateko edukiontziek sare-namespace bat partekatzen dute, beraz ezarpena edukiontzi nagusira pasatzen da.

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

privileged: true hori da berrikusleek aurka egiten duten lerroa, eta arrazoi dute. Sysctl bat idazteko pribilegioa edo irismen estu bat duen gaitasun bat behar da, eta Pod Security Standard murriztua exekutatzen duen kluster batek init edukiontzi pribilegiatu bat erabat uka dezake. Admissionek poda ukatzen badu, sorrera unean jakingo duzu, hau da, gutxienez zintzoa eta erraz irakurtzeko modukoa.

Alternatiba garbiagoa pod mailako securityContext.sysctls zerrenda da, kubelet-ari namespaced sysctl-ak aplikatzeko aukera ematen diona edukiontziren bati pribilegiorik eman gabe. Klusterraren baimendutako zerrendako izenak soilik estaltzen ditu. net.ipv4.ip_forward zerrenda horretan ote dagoen kubelet nola konfiguratu zen mende dago, eta hortik kanpoko sysctl bat eskatzen duen poda admissionen ukatzen da edo CreateContainerConfigError egoeran geratzen da sandboxa berriro saiatzen den bitartean. Egiaztatu baimendutako zerrenda eremua hondatuta dagoela pentsatu aurretik.

Bi ikuspegiak eskuz eraiki aurretik, begiratu chart-ak etengailua jada erakusten duen, sarritan ipForwardInitContainer: true bezalako zerbait gisa. Chart-aren balioa erabiltzeak zure override fitxategia txiki mantentzen du eta hurrengo bertsio-berritzea gainditzen du, eskuz adabakitako Deployment aldaketek egiten ez dutena.

Bigarren erdia: itzulera-bidea eta politika

Birbidalketa gaituta beharrezkoa da, ez nahikoa. Bezeroek kluster sareak biderik ez duen pool pribatu bat erabiltzen badute, erantzunek ezin dute tunelera itzultzeko bidea aurkitu, eta podak trafiko hori bere helmugarantz maskaratu behar du.

Politika horren gainean esertzen da. NetworkPolicy objektuak eta hodeiko suebaki arauak paketeak itzulpenaren ondoren daraman iturri helbidearen arabera ebaluatzen dira, beraz bezeroen poolerako idatzitako arau bat isilka uztartzen utz dezake maskaratzea gaitzen denean.

Bezeroek kluster barruko zerbitzuak soilik iritsi behar dituztenean, VPNa zerbitzuaren VIPean amaitzea pod sarean bideratzea baino diseinu txikiagoa da. Bezeroen pool-a CNIren bideratze-taulatik erabat kanpo ere uzten du.

Huts egiten duen jauzia bezeroarengandik isolatzea

Lan egin kanporantz eta gelditu lehen urrats isilean. Hasi VPN peer-arekin, gero saiatu podren baten helbidea, gero zerbitzu VIP bat, eta horren ondoren bakarrik helmuga publiko bat. Arrakasta bakoitzak muga jauzi bat mugitzen du, eta hutsegite bakoitzak aztertzea merezi duen geruza izendatzen du. Edozein hedapenaren ondoren, sartu exec bidez eta irakurri sysctl berriro, ordezkatutako pod bat irudiaren lehenetsitik hasten delako eta manifestuan inoiz egon ez zen konponketa bat dagoeneko joan delako.

Kubernetes dokumentazioak kluster batean sysctl-ak erabiltzeari buruz zerrendatzen du zein izen ezar daitezkeen podaren segurtasun-testuinguruaren bidez, eta hara jo behar da lehenik admissionek aldaketa ukatzen duenean.