OpenVPN-Pod a Kubernetes leet näischt weider? Kontrolléiert ip_forward

Clienten pingen de VPN-Pod an duerno näischt. Den Namespace huet d’Weiderleedung aus, an de Fix muss Admission, Neistarts an de Réckwee iwwerstoen.

Ären Laptop weist en grénge Tunnel, de Client-Log mellt, datt Route gepusht goufen, an déi eenzeg Adress, déi äntwert, ass dem VPN-Server seng eege Tunnel-IP. Pings duerno stierwen, egal wat Dir uviséiert, sief et eng ClusterIP, d’Adress vun engem anere Pod oder en ëffentlechen Hostnumm. Dës Kombinatioun ass diagnostesch an net vag: d’Dekapsuléierung funktionéiert, an den zweeten Hopp net.

Ech sinn deem op engem Debian-Node begéint, deen en OpenVPN-Image aus engem Chart lafe gelooss huet, an den Tunnel war den einfachen Deel. De Client krut eng 10.8.0.x-Lease, 10.8.0.1 huet geäntwert, an 10.96.0.10, den DNS-Service vum Cluster, ass an en Timeout gelaf. Am Server-Log huet näischt krank ausgesinn, an dat ass genau de Grond, firwat d’Leit ufänken, iptables-Regelen ëmzeschreiwen, déi se ni brauchen unzepaken.

En VPN-Pod ass en Router, an et ass derwäert, dat kloer ze soen. Verschlësselt Pakete kommen un, ginn am eegene Netzwierk-Namespace vum Pod ausgemaach, an da mussen se duerch eng aner Interface eraus. Linux refuséiert deen zweeten Schrëtt, ausser d’Weiderleedung ass bannen an där selwechter Namespace aktivéiert.

Wat de Client erreeche kann an wat net

D’Adress, déi äntwert, gehéiert zum Tunnel-Endpunkt, an de VPN-Prozess besëtzt se lokal, also ass keng Weiderleedung am Spill. Alles anescht, dorënner en anere Pod, eng Service-VIP oder den Internet, brauch de Kernel, fir e Pak vun tun0 op eth0 ze beweegen. Wann déi Beweegung refuséiert gëtt, ass de Symptom gläichméisseg Stëllt an net eng Refus, well näischt en ICMP-Fehler de Tunnel erof generéiert. Dir kritt Timeouts, net Onereechbarkeet-Meldungen, an dat ass den Hiweis, datt iwwerhaapt kee routet.

Zwee Minutten Klassifikatioun verengt d’Schicht. Wa DNS-Nimm versoen, während rau Pings op eng Service-IP geléngen, ass de Problem an der DNS-Plomberie, net an der Weiderleedung. Wa jiddwer Destinatioun hannert der Peer-Adress an en Timeout leeft, och eng plakeg IP, fänkt beim Namespace un.

Liest d’Astellung bannen am Namespace

Jiddwereen Pod kritt säin eegene Netzwierk-Namespace, an net.ipv4.ip_forward ass e Sysctl pro Namespace. En um Node z’änneren sagt Iech näischt iwwer de Container, an et ass e zouverlässege Wee, en Nomëtteg op der falscher Maschinn ze verbréngen.

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

Eng Null bestätegt d’Diagnos. De Wäert gëtt och net aus der Runtime-Konfiguratioun vum Node geierft: en ufänkt bei all Container-Erstellung mam Image-Default. En handwierklech mat kubectl exec ... sysctl -w ugewannte Fix verschwënnt dofir beim nächsten Neistart a kënnt als Feeler zeréck, dee sporadesch schéngt.

Et aktivéieren, sou datt de Manifest et behält

Déi dauerhaft Optioun ass en Init-Container, deen an der selwechter Pod-Sandbox leeft an de Wäert schreift, ier de VPN-Container ufänkt. Containeren an engem Pod deelen en Netzwierk-Namespace, also dréit d’Astellung an den Haaptcontainer.

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

Genau privileged: true ass d’Linn, géint déi d’Reviewer protestéieren, a si hunn Recht. En Sysctl ze schreiwen brauch entweder e Privileg oder eng enk gefaasst Capacitéit, an e Cluster mat dem ageschränkten Pod Security Standard kann en privilegiéierten Init-Container einfach ofleenen. Wann d’Admission de Pod ofleent, wësst Dir et bei der Erstellung, wat op d’mannst éierlech an einfach ze liesen ass.

Déi méi propper Alternativ ass d’securityContext.sysctls-Lëscht op Pod-Niveau, déi dem Kubelet erlaabt, namespace-Sysctlen unzewennen, ouni engem Container Privilegien ze ginn. Si deckt nëmmen Nimm op der Allowlist vum Cluster of. Ob net.ipv4.ip_forward op där Lëscht steet, hänkt dovun of, wéi de Kubelet konfiguréiert gouf, an e Pod, deen e Sysctl dobausse freet, gëtt bei der Admission ofgeleent oder hänkt an CreateContainerConfigError, während d’Sandbox nei versicht gëtt. Kontrolléiert d’Allowlist, ier Dir unhëlt, datt d’Feld futti ass.

Ier Dir ee vun deenen zwee Approche vun Hand baut, kuckt, ob de Chart de Schalter schonn ubitt, dacks als eppes wéi ipForwardInitContainer: true. Den Chart-Wäert ze benotzen hält Är Override-Datei kleng an iwwerlieft den nächsten Upgrade, wat handgepatchte Deployment-Ännerungen net maachen.

Déi zweet Hallschent: Réckwee a Politik

Weiderleedung un ass noutwendeg, net genuch. Wa Clienten e private Pool benotzen, fir deen d’Clusternetzwierk keng Route huet, fanne Réckäntwerten de Wee net zeréck an den Tunnel, an de Pod muss deen Traffic Richtung seng Destinatioun maskéieren.

D’Politik sëtzt drop. NetworkPolicy-Objekter a Cloud-Firewall-Regelen ginn géint d’Quelladress evaluéiert, déi e Pak no der Iwwersetzung dréit, also kann eng Regel, déi fir de Client-Pool geschriwwe gouf, stëll ophale mat ze passen, soubal d’Maskéierung aktiv ass.

Wa Clienten nëmme Servicer bannen am Cluster mussen erreechen, ass et e klengere Design, d’VPN um Service-VIP ophalen ze loossen, wéi an d’Pod-Netzwierk ze routen. Et hält och de Client-Pool komplett aus der Routing-Tabelle vum CNI.

Den ausfalende Hopp vum Client isoléieren

Schafft no baussen a stoppt beim éischte stille Schrëtt. Fänkt mam VPN-Peer un, probéiert dann d’Adress vun engem Pod, dann eng Service-VIP, an erscht duerno eng ëffentlech Destinatioun. All Erfolleg verréckelt d’Grenz en Hopp, an all Feelschlag nennt d’Schicht, déi et wäert ass z’ënnersichen. No all Rollout gitt erbanne mat exec a liest de Sysctl nach eng Kéier, well en ersaten Pod mam Image-Default ufänkt an e Fix, deen ni am Manifest war, schonn fort ass.

D’Kubernetes-Dokumentatioun iwwer d’Benotze vu Sysctlen an engem Cluster lëscht, wéi eng Nimm iwwer de Sécherheetskontext vum Pod gesat kënne ginn, an et ass déi éischt Plaz, wou een nokuckt, wann d’Admission d’Ännerung ofleent.

Ähnlech Artikelen