Pod OpenVPN yn Kubernetes yn anfon dim ymlaen? Gwiriwch ip_forward

Mae eich gliniadur yn dangos twnnel gwyrdd, mae log y cleient yn dweud bod llwybrau wedi'u gwthio, a'r unig gyfeiriad sy'n ateb yw IP twnnel y gweinydd VPN ei hun. Mae pingiau y tu hwnt iddo'n marw waeth i ba gyfeiriad yr anelwch, boed yn ClusterIP, yn gyfeiriad pod arall neu'n enw gwesteiwr cyhoeddus. Mae'r cyfuniad hwnnw'n ddiagnostig yn hytrach nag yn annelwig: mae dadgapsiwleiddio'n gweithio, ac nid yw'r naid ail.

Fe wnes i ddod ar draws hyn ar nod Debian yn rhedeg delwedd OpenVPN a osodwyd trwy chart, a'r twnnel oedd y rhan hawdd. Cymerodd y cleient brydles 10.8.0.x, atebodd 10.8.0.1, a chwalodd 10.96.0.10, gwasanaeth DNS y clwstwr, ar amser. Nid oedd dim yn log y gweinydd yn edrych yn afiach, a dyna'n union pam mae pobl yn dechrau ailysgrifennu rheolau iptables nad oedd ganddynt erioed angen cyffwrdd â nhw.

Mae pod VPN yn llwybrydd, ac mae'n werth dweud hynny'n blaen. Mae pecynnau wedi'u hamgryptio'n cyrraedd, yn cael eu dadlapio yn namespace rhwydwaith y pod ei hun, ac yna'n gorfod gadael trwy ryngwyneb gwahanol. Mae Linux yn gwrthod yr ail gam hwnnw oni bai bod anfon ymlaen wedi'i alluogi y tu mewn i'r union namespace hwnnw.

Beth all y cleient ei gyrraedd a beth na all

Mae'r cyfeiriad sy'n ateb yn perthyn i ben draw'r twnnel, ac mae proses y VPN yn berchen arno'n lleol, felly nid oes angen anfon ymlaen o gwbl. Mae popeth arall, gan gynnwys pod arall, VIP gwasanaeth neu'r rhyngrwyd, angen i'r cnewyllyn symud pecyn o tun0 i eth0. Pan wrthodir y symudiad hwnnw, y symptom yw distawrwydd unffurf yn hytrach na gwrthodiad, oherwydd nid oes dim yn cynhyrchu gwall ICMP yn ôl i lawr y twnnel. Rydych chi'n cael terfynau amser, nid negeseuon anghyraeddadwy, a dyna'r cliw nad oes neb yn llwybro o gwbl.

Mae dwy funud o ddosbarthu'n culhau'r haen. Os yw enwau DNS yn methu tra bod pingiau crai i IP gwasanaeth yn llwyddo, problem yw plymio DNS, nid anfon ymlaen. Os yw pob cyrchfan y tu hwnt i gyfeiriad y cymar yn dod i ben, gan gynnwys IP noeth, dechreuwch yn y namespace.

Darllenwch y gosodiad y tu mewn i'r namespace

Mae pob pod yn cael ei namespace rhwydwaith ei hun, ac mae net.ipv4.ip_forward yn sysctl fesul namespace. Nid yw newid ar y nod yn dweud dim wrthych am y cynhwysydd, ac mae'n ffordd ddibynadwy o dreulio prynhawn ar y peiriant anghywir.

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

Mae sero yn cadarnhau'r diagnosis. Nid yw'r gwerth yn cael ei etifeddu o ffurfweddiad amser rhedeg y nod chwaith: mae'n dechrau o ragosodiad y ddelwedd bob tro y crëir cynhwysydd. Felly mae atgyweiriad a gymhwyswyd â llaw gyda kubectl exec ... sysctl -w yn diflannu ar yr ailgychwyn nesaf ac yn dod yn ôl fel nam sy'n edrych yn ysbeidiol.

Ei alluogi fel bod y maniffest yn ei gadw

Yr opsiwn parhaol yw cynhwysydd init sy'n rhedeg yn yr un pod sandbox ac yn ysgrifennu'r gwerth cyn i gynhwysydd y VPN ddechrau. Mae cynwysyddion mewn pod yn rhannu namespace rhwydwaith, felly mae'r gosodiad yn cario i'r prif gynhwysydd.

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

Y privileged: true hwnnw yw'r llinell y mae adolygwyr yn gwthio yn ei herbyn, ac maent yn iawn. Mae ysgrifennu sysctl angen naill ai braint neu allu cyfyng ei gwmpas, a gall clwstwr sy'n rhedeg y Pod Security Standard cyfyngedig wrthod cynhwysydd init breintiedig yn gyfan gwbl. Os yw admission yn gwrthod y pod, byddwch yn dysgu ar amser creu, sy'n o leiaf yn onest ac yn hawdd ei ddarllen.

Y dewis glanach yw'r rhestr securityContext.sysctls ar lefel pod, sy'n gadael i'r kubelet gymhwyso sysctls namespace heb roi braint i unrhyw gynhwysydd. Dim ond enwau ar restr ganiatâd y clwstwr y mae'n ei chwmpasu. Mae p'un a yw net.ipv4.ip_forward ar y rhestr honno yn dibynnu ar sut y ffurfweddwyd y kubelet, ac mae pod sy'n gofyn am sysctl y tu allan iddi yn cael ei wrthod yn admission neu'n sownd mewn CreateContainerConfigError tra bod y sandbox yn cael ei ailgynnig. Gwiriwch y rhestr ganiatâd cyn tybio bod y maes wedi torri.

Cyn llunio'r naill ddull na'r llall â llaw, edrychwch a yw'r chart eisoes yn dangos y switsh, yn aml fel rhywbeth fel ipForwardInitContainer: true. Mae defnyddio gwerth y chart yn cadw eich ffeil override yn fach ac yn goroesi'r uwchraddiad nesaf, nad yw golygiadau Deployment wedi'u clytio â llaw yn ei wneud.

Yr ail hanner: llwybr dychwelyd a pholisi

Mae anfon ymlaen wedi'i alluogi yn angenrheidiol, nid yn ddigonol. Os yw cleientiaid yn defnyddio cronfa breifat nad oes gan rwydwaith y clwstwr lwybr iddi, ni all atebion ddod o hyd i'w ffordd yn ôl i'r twnnel, ac mae angen i'r pod guddio'r traffig hwnnw tuag at ei gyrchfan.

Mae polisi'n eistedd ar ben hynny. Mae gwrthrychau NetworkPolicy a rheolau tân mur y cwmwl yn cael eu gwerthuso yn erbyn y cyfeiriad ffynhonnell y mae pecyn yn ei gario ar ôl cyfieithu, felly gall rheol a ysgrifennwyd ar gyfer cronfa'r cleientiaid roi'r gorau i gydweddu'n dawel unwaith y bydd cuddio wedi'i alluogi.

Pan nad oes angen ar gleientiaid ond cyrraedd gwasanaethau y tu mewn i'r clwstwr, mae terfynu'r VPN yn VIP y gwasanaeth yn gynllun llai na llwybro i rwydwaith y podau. Mae hefyd yn cadw cronfa'r cleientiaid y tu allan i dabl llwybro'r CNI yn gyfan gwbl.

Ynysu'r naid sy'n methu oddi wrth y cleient

Gweithiwch allan a stopiwch ar y cam tawel cyntaf. Dechreuwch gyda chymar y VPN, yna rhowch gynnig ar gyfeiriad pod rhywun, yna VIP gwasanaeth, a dim ond ar ôl hynny gyrchfan gyhoeddus. Mae pob llwyddiant yn symud y ffin un naid, ac mae pob methiant yn enwi'r haen sy'n werth ei harchwilio. Ar ôl unrhyw gyflwyniad, ewch i mewn a darllenwch y sysctl eto, oherwydd mae pod a ddisodlwyd yn dechrau o ragosodiad y ddelwedd ac mae atgyweiriad nad oedd erioed yn y maniffest eisoes wedi mynd.

Mae dogfennaeth Kubernetes ar ddefnyddio sysctls mewn clwstwr yn rhestru pa enwau y gellir eu gosod trwy gyd-destun diogelwch y pod, a dyna'r lle cyntaf i edrych pan fydd admission yn gwrthod y newid.