Pod OpenVPN v Kubernetese nič nepreposiela? Skontrolujte ip_forward

Klienti pingujú VPN pod a za ním nič. Namespace má vypnuté preposielanie, a oprava musí prežiť admission, restarty aj spiatočnú cestu.

Váš notebook ukazuje zelený tunel, klientský log hlási, že trasy boli pushnuté, a jediná adresa, ktorá odpovedá, je vlastná tunelová IP VPN servera. Pingy za ňou zomierajú bez ohľadu na to, na čo mierite, či už je to ClusterIP, adresa iného podu alebo verejné meno hostiteľa. Táto kombinácia je diagnostická, nie vágna: dekapsulácia funguje a druhý skok nie.

Narazil som na to na Debian uzle s OpenVPN imageom nainštalovaným cez chart, a tunel bol tá ľahká časť. Klient dostal lease 10.8.0.x, 10.8.0.1 odpovedal a 10.96.0.10, clusterová DNS služba, vypršala. V logu servera nič nevyzeralo chorobne, a práve preto ľudia začínajú prepisovať iptables pravidlá, ktoré nikdy nemuseli mať.

VPN pod je router a stojí za to to povedať priamo. Zašifrované pakety prichádzajú, rozbalia sa vo vlastnom sieťovom namespace podu a potom musia odísť iným rozhraním. Linux tento druhý krok odmieta, kým nie je preposielanie zapnuté vnútri práve toho namespace.

Čo klient dosiahne a čo nie

Adresa, ktorá odpovedá, patrí koncovému bodu tunela a VPN proces ju vlastní lokálne, takže preposielanie sa vôbec nezúčastňuje. Všetko ostatné, vrátane iného podu, VIP služby alebo internetu, potrebuje, aby jadro presunulo paket z tun0 na eth0. Keď je tento presun odmietnutý, príznakom je rovnomerné ticho, nie odmietnutie, pretože nič negeneruje ICMP chybu späť tunelom. Dostávate timeouty, nie správy o nedostupnosti, a to je stopa, že nikto vôbec neroutuje.

Dve minúty klasifikácie zúžia vrstvu. Ak DNS mená zlyhávajú, zatiaľ čo surové pingy na IP služby prechádzajú, problém je v DNS inštalatérstve, nie v preposielaní. Ak každý cieľ za adresou peeru vyprší, vrátane holej IP, začnite pri namespace.

Prečítajte nastavenie vnútri namespace

Každý pod dostane vlastný sieťový namespace a net.ipv4.ip_forward je sysctl pre každý namespace. Zmena na uzle vám o kontajneri nepovie nič a je to spoľahlivý spôsob, ako stráviť popoludnie na nesprávnom stroji.

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

Nula diagnózu potvrdzuje. Hodnota sa tiež nededia z runtime konfigurácie uzla: začína na predvolenej hodnote image pri každom vytvorení kontajnera. Oprava vykonaná ručne pomocou kubectl exec ... sysctl -w preto zmizne pri ďalšom restarte a vráti sa ako závada, ktorá vyzerá občasne.

Zapnúť to tak, aby si to manifest udržal

Trvanlivou možnosťou je init kontajner, ktorý beží v rovnakom pod sandboxe a zapíše hodnotu pred štartom VPN kontajnera. Kontajnery v pode zdieľajú sieťový namespace, takže nastavenie sa prenesie do hlavného kontajnera.

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

Práve privileged: true je riadok, proti ktorému recenzenti protestujú, a majú pravdu. Zápis sysctl potrebuje buď privilégium, alebo úzko vymedzenú schopnosť, a cluster s reštriktívnym Pod Security Standard môže privilegovaný init kontajner rovno odmietnuť. Ak admission pod odmietne, dozviete sa to pri vytváraní, čo je aspoň poctivé a ľahko čitateľné.

Čistejšou alternatívou je zoznam securityContext.sysctls na úrovni podu, ktorý umožňuje kubeletu aplikovať namespaced sysctls bez udelenia privilégia ktorémukoľvek kontajneru. Pokrýva len mená na allowliste clusteru. Či je net.ipv4.ip_forward na tomto zozname, závisí od konfigurácie kubeletu, a pod, ktorý žiada sysctl mimo neho, je odmietnutý pri admission alebo uviazne v CreateContainerConfigError, kým sa sandbox opakuje. Skontrolujte allowlist, než budete predpokladať, že pole je rozbité.

Než oba prístupy začnete stavať ručne, pozrite sa, či chart už prepínač neexponuje, často ako niečo ako ipForwardInitContainer: true. Použitie hodnoty z chartu udrží váš override súbor malý a prežije ďalší upgrade, čo ručne záplatované úpravy Deploymentu nerobia.

Druhá polovica: spiatočná cesta a politika

Zapnuté preposielanie je nutné, nie dostačujúce. Ak klienti používajú privátny pool, pre ktorý clusterová sieť nemá trasu, odpovede si nenájdu cestu späť do tunela a pod musí ten provoz maskovať smerom k svojmu cieľu.

Politika sedí navrchu. Objekty NetworkPolicy a pravidlá cloudového firewallu sa vyhodnocujú proti zdrojovej adrese, ktorú paket nesie po preklade, takže pravidlo napísané pre klientsky pool môže ticho prestať zodpovedať, hneď ako je maskovanie zapnuté.

Keď klienti potrebujú dosiahnuť len služby vnútri clusteru, ukončenie VPN na VIP služby je menší návrh ako routovanie do siete podov. Takisto drží klientsky pool úplne mimo routovacej tabuľky CNI.

Izolácia zlyhávajúceho skoku od klienta

Pracujte smerom von a zastavte sa pri prvom tichom kroku. Začnite pri VPN peere, potom skúste adresu nejakého podu, potom VIP služby a až potom verejný cieľ. Každý úspech posunie hranicu o jeden skok a každé zlyhanie pomenuje vrstvu, ktorú stojí za to preskúmať. Po každom rolloute sa prihláste a prečítajte sysctl znova, pretože nahradený pod začína na predvolenej hodnote image a oprava, ktorá nikdy nebola v manifeste, je už preč.

Dokumentácia Kubernetes o používaní sysctls v clustere uvádza, ktoré mená možno nastaviť cez bezpečnostný kontext podu, a je to prvé miesto, kam sa pozrieť, keď admission zmenu odmietne.

Súvisiace články