Pod OpenVPN f’Kubernetes ma jgħaddix xejn ’il quddiem? Iċċekkja ip_forward
Il-klijenti jpingjaw il-pod tal-VPN u xejn lil hinn minnu. In-namespace għandu l-forwarding mitfi, u s-sewqan irid jiflaħ għall-admission, ir-restarts u l-passaġġ lura.
Il-laptop tiegħek juri tunell aħdar, il-log tal-klijent jgħid li r-rotot ġew imbuttati, u l-uniku indirizz li jwieġeb huwa l-IP tat-tunell tas-server VPN innifsu. Il-ping lil hinn minnu jmutu tkun xi tkun il-mira, kemm jekk hu ClusterIP, indirizz ta’ pod ieħor jew isem ta’ host pubbliku. Din il-kombinazzjoni hija dijanjostika u mhux vaga: id-dekapsulazzjoni taħdem, u t-tieni qabża le.
Iltqajt ma’ dan fuq node Debian li kien qed iħaddem immaġni OpenVPN installata permezz ta’ chart, u t-tunell kien il-parti faċli. Il-klijent ħa kiri 10.8.0.x, 10.8.0.1 wieġeb, u 10.96.0.10, is-servizz DNS tal-kluster, skada fi żmien. Xejn fil-log tas-server ma deher marid, u huwa eżattament għalhekk li n-nies jibdew jiktbu mill-ġdid regoli iptables li qatt ma kellhom bżonn imissu.
Pod VPN huwa router, u jiswa li tgħid dan b’mod ċar. Pakketti kriptati jaslu, jiġu miftuħa fin-namespace tan-netwerk tal-pod stess, u mbagħad iridu joħorġu minn interface ieħor. Linux jirrifjuta dik it-tieni pass sakemm il-forwarding ma tkunx attivata ġewwa dak in-namespace stess.
X’jista’ jilħaq il-klijent u x’ma jistax
L-indirizz li jwieġeb jappartjeni lit-tarf tat-tunell, u l-proċess VPN jippossjedih lokalment, għalhekk il-forwarding m’għandux x’jaqsam xejn. Kollox ieħor, inkluż pod ieħor, VIP ta’ servizz jew l-internet, jeħtieġ li l-kernel iċċaqlaq pakkett minn tun0 għal eth0. Meta dik iċ-ċaqliq tiġi rrifjutata, is-sintomu huwa silenzju uniformi u mhux rifjut, għax xejn ma jiġġenera żball ICMP lura tul it-tunell. Ikollok timeout, mhux messaġġi ta’ mhux aċċessibbli, u dik hija l-ħjiel li ħadd mhu qed jidderieġi xejn.
Żewġ minuti ta’ klassifikazzjoni jidjiequ is-saff. Jekk l-ismijiet DNS ifallu filwaqt li ping mhux maħdum lejn IP ta’ servizz jirnexxi, il-problema hija fil-plaming tad-DNS, mhux fil-forwarding. Jekk kull destinazzjoni lil hinn mill-indirizz tal-peer tiskadi, inkluż IP għarwien, ibda min-namespace.
Aqra s-setting ġewwa n-namespace
Kull pod jieħu n-namespace tan-netwerk tiegħu, u net.ipv4.ip_forward huwa sysctl għal kull namespace. Li tibdlu fuq in-node ma jgħidlek xejn dwar il-container, u din hija mod affidabbli biex tqatta’ wara nofsinhar fuq il-magna ħażina.
kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0
Żero jikkonferma d-dijanjosi. Il-valur lanqas ma jiġi ereditat mill-konfigurazzjoni tal-ħin tal-eżekuzzjoni tan-node: jibda mid-default tal-immaġni kull darba li jinħoloq container. Għalhekk tiswija applikata bl-idejn b’kubectl exec ... sysctl -w tisparixxi fl-restart li jmiss u terġa’ lura bħala ħsara li tidher intermittenti.
Tattivaha sabiex il-manifest iżommha
L-għażla dejjiema hija container init li jaħdem fl-istess pod sandbox u jikteb il-valur qabel ma jibda l-container VPN. Il-containers fi pod jaqsmu namespace tan-netwerk, għalhekk is-setting tgħaddi fil-container prinċipali.
initContainers:
- name: enable-forwarding
image: busybox:1.36
command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
securityContext:
privileged: true
Dak privileged: true huwa l-linja li r-reviżuri jopponu, u għandhom raġun. Li tikteb sysctl jeħtieġ jew privileġġ jew kapaċità mrażżna, u kluster li jħaddem il-Pod Security Standard ristrett jista’ jirrifjuta container init privileġġjat għal kollox. Jekk l-admission tirrifjuta l-pod, issir taf fil-ħin tal-ħolqien, li għall-inqas huwa onest u faċli biex taqra.
L-alternattiva aktar nadifa hija l-lista securityContext.sysctls fil-livell tal-pod, li tħalli lill-kubelet japplika sysctls b’namespace mingħajr ma tagħti privileġġ lil ebda container. Hija tkopri biss ismijiet fuq il-lista permessa tal-kluster. Jekk net.ipv4.ip_forward hijiex fuq dik il-lista jiddependi minn kif ġie kkonfigurat il-kubelet, u pod li jitlob sysctl barra minnha jiġi rrifjutat fl-admission jew jibqa’ mblukkat fi CreateContainerConfigError waqt li s-sandbox jiġi ppruvat mill-ġdid. Iċċekkja l-lista permessa qabel ma tassumi li l-qasam huwa miksi.
Qabel ma tibni xi waħda miż-żewġ approċċi bl-idejn, ara jekk il-chart diġà jesponix is-switch, spiss bħala xi ħaġa bħal ipForwardInitContainer: true. Li tuża l-valur tal-chart iżomm il-fajl override tiegħek żgħir u jiflaħ għall-aġġornament li jmiss, li l-editjar tal-Deployment imtejjeb bl-idejn ma jagħmilx.
It-tieni nofs: passaġġ lura u politika
Il-forwarding mixgħula hija neċessarja, mhux biżżejjed. Jekk il-klijenti jużaw pool privat li n-netwerk tal-kluster m’għandux rotta għalih, it-tweġibiet ma jsibux triqthom lura fit-tunell, u il-pod irid jaħbi dak it-traffiku lejn id-destinazzjoni tiegħu.
Il-politika tpoġġi fuq dan. L-oġġetti NetworkPolicy u r-regoli tal-firewall tal-cloud jiġu evalwati kontra l-indirizz tas-sors li jġorr pakkett wara t-traduzzjoni, għalhekk regola miktuba għall-pool tal-klijenti tista’ tieqaf tqabbel bil-kwiet ladarba l-masking ikun attivat.
Meta l-klijenti jkollhom bżonn biss jilħqu servizzi ġewwa l-kluster, li l-VPN tintemm fil-VIP tas-servizz huwa disinn iżgħar milli tidderieġi fin-netwerk tal-pods. Iżomm ukoll il-pool tal-klijenti għal kollox barra mit-tabella tat-tidwir tal-CNI.
Tiżola l-qabża li tfalli mill-klijent
Aħdem ’il barra u waqaf fl-ewwel pass sieket. Ibda mill-peer VPN, imbagħad ipprova l-indirizz ta’ xi pod, imbagħad VIP ta’ servizz, u wara biss destinazzjoni pubblika. Kull suċċess iċaqlaq il-fruntiera qabża waħda, u kull falliment isemmi s-saff li jiswa li jiġi spezzjonat. Wara kull tnedija, idħol b’exec u aqra s-sysctl mill-ġdid, għax pod sostitwit jibda mid-default tal-immaġni u tiswija li qatt ma kienet fil-manifest diġà marret.
Id-dokumentazzjoni ta’ Kubernetes dwar l-użu ta’ sysctls fi kluster telenka liema ismijiet jistgħu jiġu ssettjati permezz tal-kuntest tas-sigurtà tal-pod, u huwa l-ewwel post li wieħed iħares lejh meta l-admission tirrifjuta l-bidla.