Një pod OpenVPN në Kubernetes nuk përcjell asgjë? Kontrolloni ip_forward

Laptopi juaj shfaq një tunel të gjelbër, regjistri i klientit raporton se rrugët u shtynë, dhe adresa e vetme që përgjigjet është IP-ja e tunelit të vetë serverit VPN. Ping-et përtej saj vdesin pa marrë parasysh se çfarë synoni, qoftë ClusterIP, adresa e një pod-i tjetër apo një emër hosti publik. Ai kombinim është diagnostik, jo i paqartë: dekapsulimi funksionon, dhe kërcimi i dytë jo.

Këtë e hasa në një nyje Debian që ekzekutonte një imazh OpenVPN të instaluar përmes chart, dhe tuneli ishte pjesa e lehtë. Klienti mori një qira 10.8.0.x, 10.8.0.1 u përgjigj, dhe 10.96.0.10, shërbimi DNS i grupit, skadoi. Asgjë në regjistrin e serverit nuk dukej e sëmurë, dhe pikërisht për këtë njerëzit fillojnë të rishkruajnë rregulla iptables që nuk u duhej t’i preknin kurrë.

Një pod VPN është ruter, dhe ia vlen të thuhet troç. Paketat e kriptuara mbërrijnë, shpaketohen në namespace-in e rrjetit të vetë pod-it, dhe më pas duhet të dalin përmes një ndërfaqeje tjetër. Linux e refuzon atë hap të dytë nëse përcjellja nuk është e aktivizuar brenda pikërisht atij namespace.

Çfarë klienti mund dhe nuk mund të arrijë

Adresa që përgjigjet i përket pikës fundore të tunelit, dhe procesi VPN e zotëron lokalisht, kështu që përcjellja nuk përfshihet fare. Çdo gjë tjetër, përfshirë një pod tjetër, një VIP shërbimi ose internetin, kërkon që kerneli të lëvizë një paketë nga tun0 në eth0. Kur ajo lëvizje refuzohet, simptomi është heshtje uniforme dhe jo refuzim, sepse asgjë nuk gjeneron një gabim ICMP përsëri poshtë tunelit. Ju merrni skadime kohe, jo mesazhe të paarritshmërisë, dhe ky është indici që askush nuk po rrugëton fare.

Dy minuta klasifikim e ngushtojnë shtresën. Nëse emrat DNS dështojnë ndërsa ping-et e papërpunuara në një IP shërbimi kalojnë, problemi është në hidraulikun e DNS, jo në përcjellje. Nëse çdo destinacion përtej adresës së peer skadon, përfshirë një IP të zhveshur, filloni nga namespace.

Lexoni cilësimin brenda namespace

Çdo pod merr namespace-in e vet të rrjetit, dhe net.ipv4.ip_forward është një sysctl për çdo namespace. Ndryshimi i tij në nyje nuk ju thotë asgjë për kontejnerin, dhe është një mënyrë e besueshme për të kaluar një pasdite në makinën e gabuar.

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

Zeroja e konfirmon diagnozën. Vlera gjithashtu nuk trashëgohet nga konfigurimi i kohës së ekzekutimit të nyjes: fillon nga parazgjedhja e imazhit sa herë krijohet një kontejner. Prandaj një rregullim i aplikuar me dorë me kubectl exec ... sysctl -w zhduket në rinisjen tjetër dhe kthehet si një defekt që duket i ndërprerë.

Ta aktivizosh në mënyrë që manifesti ta mbajë

Opsioni i qëndrueshëm është një kontejner init që ekzekutohet në të njëjtin pod sandbox dhe shkruan vlerën përpara se kontejneri VPN të nisë. Kontejnerët në një pod ndajnë një namespace rrjeti, kështu që cilësimi kalon në kontejnerin kryesor.

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

Pikërisht privileged: true është rreshti që recensentët kundërshtojnë, dhe kanë të drejtë. Të shkruash një sysctl kërkon ose privilegj ose një aftësi të kufizuar ngushtë, dhe një grup që ekzekuton Pod Security Standard të kufizuar mund të refuzojë plotësisht një kontejner init të privilegjuar. Nëse admission e refuzon pod-in, e mëson në kohën e krijimit, gjë që të paktën është e sinqertë dhe e lehtë për t’u lexuar.

Alternativa më e pastër është lista securityContext.sysctls në nivel pod-i, e cila i lejon kubelet-it të aplikojë sysctl me namespace pa i dhënë privilegje asnjë kontejneri. Mbulon vetëm emrat në listën e lejuar të grupit. Nëse net.ipv4.ip_forward është në atë listë varet nga mënyra se si u konfigurua kubelet-i, dhe një pod që kërkon një sysctl jashtë saj refuzohet në admission ose ngec në CreateContainerConfigError ndërsa sandbox-i riprovohet. Kontrolloni listën e lejuar përpara se të supozoni që fusha është e prishur.

Përpara se të ndërtoni me dorë ndonjë nga dy qasjet, shikoni nëse chart-i e ekspozon tashmë ndërprerësin, shpesh si diçka si ipForwardInitContainer: true. Përdorimi i vlerës së chart-it e mban skedarin tuaj override të vogël dhe i mbijeton përditësimit të radhës, gjë që redaktimet e Deployment-it të rregulluara me dorë nuk e bëjnë.

Gjysma e dytë: rruga e kthimit dhe politika

Përcjellja e ndezur është e nevojshme, jo e mjaftueshme. Nëse klientët përdorin një pishinë private për të cilën rrjeti i grupit nuk ka rrugë, përgjigjet nuk e gjejnë rrugën përsëri në tunel, dhe pod-i duhet ta maskojë atë trafik drejt destinacionit të tij.

Politika qëndron sipër. Objektet NetworkPolicy dhe rregullat e murit të zjarrit të resë vlerësohen kundrejt adresës burimore që një paketë mbart pas përkthimit, kështu që një rregull i shkruar për pishinën e klientëve mund të ndalojë së përputhuri në heshtje sapo maskimi të aktivizohet.

Kur klientët duhet të arrijnë vetëm shërbime brenda grupit, përfundimi i VPN-së në VIP-në e shërbimit është një dizajn më i vogël sesa rrugëtimi në rrjetin e pod-eve. Ai gjithashtu e mban pishinën e klientëve plotësisht jashtë tabelës së rrugëtimit të CNI-së.

Izolimi i kërcimit që dështon nga klienti

Punoni nga jashtë dhe ndaloni në hapin e parë të heshtur. Filloni me peer-in VPN, më pas provoni adresën e ndonjë pod-i, pastaj një VIP shërbimi, dhe vetëm pas kësaj një destinacion publik. Çdo sukses e zhvendos kufirin një kërcim, dhe çdo dështim emërton shtresën që ia vlen të inspektohet. Pas çdo publikimi, hyni me exec dhe lexoni sysctl-in përsëri, sepse një pod i zëvendësuar niset nga parazgjedhja e imazhit dhe një rregullim që nuk ishte kurrë në manifest tashmë ka ikur.

Dokumentacioni i Kubernetes për përdorimin e sysctl-ve në një grup rendit cilat emra mund të vendosen përmes kontekstit të sigurisë së pod-it, dhe është vendi i parë ku duhet shikuar kur admission refuzon ndryshimin.