OpenVPN pods Kubernetes vidē neko nepārsūta? Pārbaudiet ip_forward

Klienti pingē VPN podu, un tālāk nekas neatbild. Namespace ir izslēgta pārsūtīšana, un labojumam jāiztur admission, restartus un atgriešanās ceļš.

Jūsu klēpjdators rāda zaļu tuneli, klienta žurnāls ziņo, ka maršruti tika iespiesti, un vienīgā atbildošā adrese ir paša VPN servera tuneļa IP. Pingi aiz tā mirst neatkarīgi no tā, uz ko mērķējat, vai tas būtu ClusterIP, cita poda adrese vai publisks resursdatora nosaukums. Šī kombinācija ir diagnostiska, nevis neskaidra: dekapsulēšana darbojas, un otrais lēciens ne.

Es ar to saskāros Debian mezglā, kurā darbojās ar chart instalēts OpenVPN attēls, un tunelis bija vieglā daļa. Klients ieguva 10.8.0.x nomu, 10.8.0.1 atbildēja, un 10.96.0.10, klastera DNS pakalpojums, beidzās ar taimautu. Servera žurnālā nekas neizskatījās slims, un tieši tāpēc cilvēki sāk pārrakstīt iptables noteikumus, kuriem viņiem nekad nevajadzēja pieskarties.

VPN pods ir maršrutētājs, un to ir vērts pateikt tieši. Šifrēti paketes ierodas, tiek iztinātas paša poda tīkla namespace, un pēc tam tām jāiziet pa citu saskarni. Linux atsakās no šī otrā soļa, ja vien pārsūtīšana nav iespējota tieši tajā namespace.

Ko klients var un ko nevar sasniegt

Atbildošā adrese pieder tuneļa galapunktam, un VPN process to pārvalda lokāli, tāpēc pārsūtīšana vispār nepiedalās. Visam pārējam, tostarp citam podam, pakalpojuma VIP vai internetam, ir vajadzīgs kodols, lai pārvietotu pakešu no tun0 uz eth0. Kad šī pārvietošana tiek atteikta, simptoms ir vienmērīgs klusums, nevis atteikums, jo nekas neģenerē ICMP kļūdu atpakaļ pa tuneli. Jūs saņemat taimautus, nevis nesasniedzamības ziņojumus, un tas ir mājiens, ka neviens vispār nemaršrutē.

Divas minūtes klasifikācijas sašaurina slāni. Ja DNS nosaukumi neizdodas, bet neapstrādāti pingi uz pakalpojuma IP izdodas, problēma ir DNS santehnikā, nevis pārsūtīšanā. Ja katrs galamērķis aiz peer adreses beidzas ar taimautu, tostarp kaila IP, sāciet ar namespace.

Izlasiet iestatījumu namespace iekšpusē

Katrs pods iegūst savu tīkla namespace, un net.ipv4.ip_forward ir sysctl katram namespace. Tā maiņa mezglā neko nepasaka par konteineru, un tas ir uzticams veids, kā pavadīt pēcpusdienu nepareizajā mašīnā.

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

Nulle apstiprina diagnozi. Vērtība arī netiek mantota no mezgla izpildlaika konfigurācijas: tā sākas no attēla noklusējuma katru reizi, kad tiek izveidots konteiners. Tāpēc ar kubectl exec ... sysctl -w manuāli piemērots labojums pazūd nākamajā restartā un atgriežas kā defekts, kas izskatās periodisks.

Iespējot to tā, lai manifests to saglabātu

Noturīgais variants ir init konteiners, kas darbojas tajā pašā pod sandbox un ieraksta vērtību pirms VPN konteinera starta. Konteineri podā koplieto tīkla namespace, tāpēc iestatījums pāriet uz galveno konteineru.

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

Tieši privileged: true ir rinda, pret ko iebilst recenzenti, un viņiem ir taisnība. Sysctl rakstīšanai vajadzīga vai nu privilēģija, vai šauri ierobežota spēja, un klasteris ar ierobežoto Pod Security Standard var pilnībā atteikt privileģētu init konteineru. Ja admission noraida podu, jūs to uzzināt izveides laikā, kas vismaz ir godīgi un viegli lasāms.

Tīrāka alternatīva ir poda līmeņa securityContext.sysctls saraksts, kas ļauj kubelet piemērot namespace sysctl, nepiešķirot privilēģijas nevienam konteineram. Tas aptver tikai klastera atļauto sarakstā esošos nosaukumus. Vai net.ipv4.ip_forward ir šajā sarakstā, ir atkarīgs no tā, kā tika konfigurēts kubelet, un pods, kas pieprasa sysctl ārpus tā, tiek noraidīts admission laikā vai iestrēgst CreateContainerConfigError, kamēr sandbox tiek mēģināts vēlreiz. Pārbaudiet atļauto sarakstu, pirms pieņemat, ka lauks ir salauzts.

Pirms veidojat manuāli kādu no abām pieejām, apskatiet, vai chart jau nepiedāvā slēdzi, bieži kā kaut ko līdzīgu ipForwardInitContainer: true. Chart vērtības izmantošana saglabā jūsu override failu mazu un iztur nākamo atjauninājumu, ko manuāli laboti Deployment grozījumi nedara.

Otrā puse: atgriešanās ceļš un politika

Ieslēgta pārsūtīšana ir nepieciešama, nevis pietiekama. Ja klienti izmanto privātu baseinu, kuram klastera tīklam nav maršruta, atbildes nevar atrast ceļu atpakaļ tunelī, un podam ir jāmaskē šī plūsma uz savu galamērķi.

Politika atrodas virs tā. NetworkPolicy objekti un mākoņa ugunsmūra noteikumi tiek vērtēti pret avota adresi, ko pakete nes pēc tulkošanas, tāpēc klientu baseinam rakstīts noteikums var klusi pārstāt atbilst, tiklīdz maskēšana ir iespējota.

Kad klientiem jāsasniedz tikai pakalpojumi klastera iekšienē, VPN pabeigšana pakalpojuma VIP ir mazāks dizains nekā maršrutēšana podu tīklā. Tas arī pilnībā tur klientu baseinu ārpus CNI maršrutēšanas tabulas.

Atdalīt neizdevušos lēcienu no klienta

Strādājiet uz āru un apstājieties pie pirmā klusā soļa. Sāciet ar VPN peer, pēc tam izmēģiniet kāda poda adresi, tad pakalpojuma VIP, un tikai pēc tam publisku galamērķi. Katrs panākums pārvieto robežu par vienu lēcienu, un katra neveiksme nosauc slāni, kuru ir vērts pārbaudīt. Pēc jebkuras izvietošanas iesim ar exec un vēlreiz izlasiet sysctl, jo aizvietotais pods sākas no attēla noklusējuma, un labojums, kas nekad nebija manifestā, jau ir pazudis.

Kubernetes dokumentācija par sysctl lietošanu klasterī uzskaita, kurus nosaukumus var iestatīt ar poda drošības kontekstu, un tā ir pirmā vieta, kur skatīties, kad admission noraida izmaiņas.

Saistītie raksti