A Kubernetes OpenVPN-podja nem továbbít semmit? Ellenőrizze az ip_forward beállítást

Az ügyfelek pingelik a VPN-podot, és azon túl semmi. A namespace-ben a továbbítás ki van kapcsolva, és a javításnak túl kell élnie az admissiont, az újraindításokat és a visszautat.

A laptopja zöld alagutat mutat, az ügyféllog szerint az útvonalak ki lettek tolva, és az egyetlen válaszoló cím a VPN-kiszolgáló saját alagút-IP-je. A pingek azon túl meghalnak, bármire céloz, legyen az ClusterIP, egy másik pod címe vagy nyilvános hosztnév. Ez a kombináció diagnosztikus, nem homályos: a dekapszuláció működik, a második ugrás nem.

Egy Debian csomóponton találkoztam ezzel, amely charttal telepített OpenVPN-imázst futtatott, és az alagút volt a könnyű rész. Az ügyfél 10.8.0.x bérletet kapott, a 10.8.0.1 válaszolt, a 10.96.0.10 pedig, a klaszter DNS-szolgáltatása, időtúllépéssel lejárt. A kiszolgáló naplójában semmi sem tűnt betegnek, és éppen ezért kezdik az emberek átírni azokat az iptables-szabályokat, amelyekhez soha nem kellett volna nyúlniuk.

A VPN-pod egy router, és ezt érdemes kerek perec kimondani. A titkosított csomagok megérkeznek, a pod saját hálózati namespace-ében kicsomagolódnak, majd egy másik interfészen kell távozniuk. A Linux elutasítja ezt a második lépést, hacsak a továbbítás nincs engedélyezve éppen abban a namespace-ben.

Mit érhet el az ügyfél és mit nem

A válaszoló cím az alagút végpontjához tartozik, és a VPN-folyamat helyben birtokolja, tehát a továbbítás egyáltalán nem játszik szerepet. Minden más, köztük egy másik pod, egy szolgáltatás-VIP vagy az internet, a kerneltől kéri, hogy mozgasson egy csomagot tun0-ról eth0-re. Amikor ezt a mozgatást elutasítják, a tünet egyenletes csend, nem elutasítás, mert semmi sem generál ICMP-hibát visszafelé az alagútban. Időtúllépéseket kap, nem elérhetetlenségi üzeneteket, és ez a nyom arra, hogy senki sem forgalomirányít egyáltalán.

Két perc osztályozás szűkíti a réteget. Ha a DNS-nevek meghiúsulnak, miközben a nyers pingek egy szolgáltatás IP-jére sikerülnek, a probléma a DNS-vezetékezés, nem a továbbítás. Ha a peer-címen túli minden cél időtúllépéssel lejár, beleértve egy csupasz IP-t is, kezdje a namespace-nél.

Olvassa ki a beállítást a namespace-en belül

Minden pod saját hálózati namespace-t kap, és a net.ipv4.ip_forward namespace-enkénti sysctl. A csomóponton módosítani semmit sem mond a konténerről, és megbízható módja annak, hogy egy délutánt a rossz gépen töltsön.

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

A nulla megerősíti a diagnózist. Az érték a csomópont futásidejű konfigurációjából sem öröklődik: minden konténer létrehozásakor az imázs alapértékéről indul. Ezért eltűnik a kubectl exec ... sysctl -w-gyel kézzel alkalmazott javítás a következő újraindításkor, és időszakosnak tűnő hibaként tér vissza.

Engedélyezni úgy, hogy a manifest megtartsa

A tartós megoldás egy init-konténer, amely ugyanabban a pod sandboxban fut, és még a VPN-konténer indulása előtt beírja az értéket. Egy pod konténerei közös hálózati namespace-t használnak, így a beállítás átkerül a fő konténerbe.

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

Pontosan a privileged: true az a sor, amely ellen a bírálók tiltakoznak, és igazuk van. A sysctl írásához vagy privilégium, vagy szűken korlátozott képesség kell, és a korlátozott Pod Security Standardot futtató klaszter egyáltalán elutasíthatja a privilegizált init-konténert. Ha az admission elutasítja a podot, ezt létrehozáskor megtudja, ami legalább őszinte és könnyen olvasható.

A tisztább alternatíva a pod szintű securityContext.sysctls lista, amely lehetővé teszi a kubelet számára a namespace-es sysctlek alkalmazását anélkül, hogy bármely konténernek privilégiumot adna. Csak a klaszter engedélyezett listáján szereplő neveket fedi le. Az, hogy a net.ipv4.ip_forward szerepel-e ezen a listán, attól függ, hogyan konfigurálták a kubeletet, és az azon kívüli sysctlt kérő podot az admission elutasítja, vagy beragad a CreateContainerConfigError-be, miközben a sandboxot újra próbálják. Ellenőrizze az engedélyezett listát, mielőtt feltételezné, hogy a mező hibás.

Mielőtt bármelyik megközelítést kézzel felépítené, nézze meg, hogy a chart már kitettsé teszi-e a kapcsolót, gyakran valami ilyesmit: ipForwardInitContainer: true. A chart értékének használata kicsiben tartja a felülíró fájlt, és túléli a következő frissítést, amit a kézzel foltozott Deployment-módosítások nem tesznek meg.

A második fél: visszaút és házirend

A bekapcsolt továbbítás szükséges, de nem elégséges. Ha az ügyfelek olyan privát készletet használnak, amelyhez a klaszterhálózatnak nincs útvonala, a válaszok nem találnak vissza az alagútba, és a podnak maszkolnia kell ezt a forgalmat a célja felé.

A házirend ezen ül. A NetworkPolicy-objektumokat és a felhő tűzfalszabályait a csomag fordítás után hordozott forrás címéhez mérik, így az ügyfélkészletre írt szabály csendben megszűnhet illeszkedni, amint a maszkolás bekapcsol.

Amikor az ügyfeleknek csak a klaszteren belüli szolgáltatásokra kell eljutniuk, a VPN szolgáltatás-VIP-nél való lezárása kisebb tervezés, mint a podhálózatba irányítás. Ez a teljes ügyfélkészletet a CNI útvonaltábláján kívül is tartja.

A hibás ugrás elkülönítése az ügyféltől

Dolgozzon kifelé, és álljon meg az első csendes lépésnél. Kezdje a VPN-peerrel, aztán próbálja valamelyik pod címét, majd egy szolgáltatás-VIP-et, és csak utána egy nyilvános célt. Minden siker egy ugrással mozgatja a határt, és minden hiba megnevezi a vizsgálatra érdemes réteget. Bármilyen bevezetés után lépjen be, és olvassa újra a sysctlt, mert a lecserélt pod az imázs alapértékéről indul, és a manifestben soha nem szerepelt javítás már eltűnt.

A Kubernetes dokumentációja a sysctlek klaszterbeli használatáról felsorolja, mely nevek állíthatók be a pod biztonsági kontextusán keresztül, és ez az első hely, ahol érdemes megnézni, amikor az admission elutasítja a változtatást.

Kapcsolódó cikkek