Pod OpenVPN v Kubernetesu ne posreduje ničesar? Preverite ip_forward

Vaš prenosnik prikazuje zelen tunel, dnevnik odjemalca poroča, da so bile poti potisnjene, in edini naslov, ki se odziva, je lastni tunelski IP strežnika VPN. Pingi naprej umrejo ne glede na to, kam ciljate, naj bo to ClusterIP, naslov drugega poda ali javno ime gostitelja. Ta kombinacija je diagnostična in ne nejasna: dekapsulacija deluje, drugi skok pa ne.

Na to sem naletel na vozlišču Debian z sliko OpenVPN, nameščeno prek charta, in tunel je bil lažji del. Odjemalec je dobil zakup 10.8.0.x, 10.8.0.1 je odgovoril, 10.96.0.10, storitev DNS v gruči, pa je potekla. V dnevniku strežnika ni bilo videti nič bolnega, in prav zato ljudje začnejo prepisovati pravila iptables, ki se jih nikoli niso morali dotakniti.

Pod VPN je usmerjevalnik, in to velja povedati naravnost. Šifrirani paketi prispejo, se razpakirajo v lastnem omrežnem namespace poda in nato morajo oditi skozi drug vmesnik. Linux ta drugi korak zavrne, razen če je posredovanje omogočeno znotraj prav tega namespace.

Kaj odjemalec lahko in česa ne more doseči

Naslov, ki se odziva, pripada končni točki tunela, in proces VPN ga ima v lokalni lasti, zato posredovanje sploh ni vključeno. Vse ostalo, vključno z drugim podom, VIP storitve ali internetom, potrebuje jedro, da premakne paket z tun0 na eth0. Ko je ta premik zavrnjen, je simptom enakomerna tišina in ne zavrnitev, ker nič ne ustvari napake ICMP nazaj po tunelu. Dobite časovne omejitve, ne sporočil o nedosegljivosti, in to je namig, da nihče sploh ne usmerja.

Dve minuti razvrščanja zožita plast. Če imena DNS odpovedo, medtem ko surovi pingi na IP storitve uspejo, je težava v vodovodni napeljavi DNS, ne v posredovanju. Če vsak cilj za naslovom peerja poteče, vključno z golo IP, začnite pri namespace.

Preberite nastavitev znotraj namespace

Vsak pod dobi svoj omrežni namespace, in net.ipv4.ip_forward je sysctl na namespace. Spreminjanje na vozlišču vam ne pove ničesar o vsebniku, in to je zanesljiv način, da popoldne preživite na napačnem stroju.

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

Nič potrdi diagnozo. Vrednost se tudi ne podeduje iz izvajalne konfiguracije vozlišča: začne se pri privzeti vrednosti slike vsakič, ko je ustvarjen vsebnik. Zato popravek, uporabljen ročno z kubectl exec ... sysctl -w, izgine ob naslednjem restartu in se vrne kot napaka, ki se zdi občasna.

Omogočiti tako, da manifest to obdrži

Trajna možnost je init vsebnik, ki teče v istem pod sandboxu in zapiše vrednost, preden se vsebnik VPN zažene. Vsebniki v podu si delijo omrežni namespace, zato se nastavitev prenese v glavni vsebnik.

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

Prav privileged: true je vrstica, ki ji recenzenti nasprotujejo, in imajo prav. Pisanje sysctl zahteva bodisi privilegij bodisi ozko omejeno zmožnost, in gruča z omejenim Pod Security Standard lahko privilegiran init vsebnik povsem zavrne. Če admission pod zavrne, to izveste ob ustvarjanju, kar je vsaj pošteno in lahko berljivo.

Čistejša alternativa je seznam securityContext.sysctls na ravni poda, ki omogoča kubeletu uporabo sysctls z namespace, ne da bi kateremu koli vsebniku podelil privilegije. Pokriva le imena na seznamu dovoljenih gruče. Ali je net.ipv4.ip_forward na tem seznamu, je odvisno od konfiguracije kubeleta, in pod, ki zahteva sysctl zunaj njega, je zavrnjen pri admissionu ali obtiči v CreateContainerConfigError, medtem ko se sandbox znova poskuša. Preverite seznam dovoljenih, preden domnevate, da je polje pokvarjeno.

Preden kateri koli pristop zgradite ročno, poglejte, ali chart že izpostavlja stikalo, pogosto kot nekaj takega kot ipForwardInitContainer: true. Uporaba vrednosti iz charta ohrani vašo datoteko s prepisi majhno in preživi naslednjo nadgradnjo, česar ročno popravljene spremembe Deploymenta ne storijo.

Druga polovica: povratna pot in politika

Vklopljeno posredovanje je nujno, ne zadostuje. Če odjemalci uporabljajo zasebni nabor, za katerega omrežje gruče nima poti, odgovori ne najdejo poti nazaj v tunel, in pod mora ta promet maskirati proti svojemu cilju.

Politika sedi na tem. Predmeti NetworkPolicy in pravila požarnega zidu v oblaku se ocenjujejo glede na izvorni naslov, ki ga paket nosi po prevodu, zato lahko pravilo, napisano za nabor odjemalcev, tiho preneha ustrezati, ko je maskiranje omogočeno.

Ko morajo odjemalci doseči le storitve znotraj gruče, je zaključek VPN na VIP storitve manjša zasnova kot usmerjanje v omrežje podov. Ohranja tudi nabor odjemalcev popolnoma zunaj usmerjevalne tabele CNI.

Izolirati neuspešni skok od odjemalca

Delajte navzven in ustavite se pri prvem tihim koraku. Začnite pri peerju VPN, nato poskusite naslov kakšnega poda, nato VIP storitve in šele nato javni cilj. Vsak uspeh premakne mejo za en skok, in vsak neuspeh poimenuje plast, ki si jo velja ogledati. Po vsaki uvedbi vstopite z exec in znova preberite sysctl, ker se zamenjani pod začne pri privzeti vrednosti slike, in popravek, ki ga nikoli ni bilo v manifestu, je že izginil.

Dokumentacija Kubernetes o uporabi sysctl v gruči navaja, katera imena je mogoče nastaviti prek varnostnega konteksta poda, in to je prvo mesto, kam pogledati, ko admission spremembo zavrne.