Pod ya OpenVPN katika Kubernetes haisambazii chochote? Angalia ip_forward

Laptop yako inaonyesha handaki la kijani, kumbukumbu ya mteja inasema njia zilisukumwa, na anwani pekee inayojibu ni IP ya handaki ya seva ya VPN yenyewe. Ping zaidi ya hapo hufa bila kujali unalenga nini, iwe ClusterIP, anwani ya pod nyingine au jina la mwenyeji la umma. Mchanganyiko huo ni wa utambuzi, si wa kutatanisha: ufunguzi unafanya kazi, na kuruka kwa pili hakufanyi kazi.

Nilikutana na hili kwenye node ya Debian iliyokuwa ikiendesha taswira ya OpenVPN iliyosakinishwa kwa chart, na handaki lilikuwa sehemu rahisi. Mteja alipata ukodishaji wa 10.8.0.x, 10.8.0.1 ilijibu, na 10.96.0.10, huduma ya DNS ya nguzo, ilimaliza muda. Hakuna kilichoonekana kuwa mgonjwa kwenye kumbukumbu ya seva, na ndiyo sababu watu huanza kuandika upya sheria za iptables ambazo hawakuhitaji kuzigusa kamwe.

Pod ya VPN ni kipanga njia, na inafaa kusema hivyo wazi. Pakiti zilizosimbwa hufika, hufunguliwa katika namespace ya mtandao ya pod yenyewe, kisha lazima zitoke kupitia kiolesura kingine. Linux inakataa hatua hiyo ya pili isipokuwa usambazaji umewezeshwa ndani ya namespace hiyo hiyo.

Mteja anaweza kufikia nini na hawezi kufikia nini

Anwani inayojibu ni ya mwisho wa handaki, na mchakato wa VPN unaimiliki kienyeji, kwa hiyo usambazaji hauhusiki kabisa. Kila kingine, ikiwa ni pamoja na pod nyingine, VIP ya huduma au intaneti, kinahitaji kerneli kuhamisha pakiti kutoka tun0 hadi eth0. Uhamisho huo unapokataliwa, dalili ni ukimya unaofanana badala ya kukataliwa, kwa sababu hakuna kinachozalisha hitilafu ya ICMP kurudi chini ya handaki. Unapata muda kuisha, si ujumbe wa kutofikika, na hiyo ndiyo dalili kwamba hakuna mtu anayepanga njia kabisa.

Dakika mbili za uainishaji hupunguza safu. Ikiwa majina ya DNS yanashindwa wakati ping ghafi kwa IP ya huduma yanafanikiwa, tatizo liko kwenye mabomba ya DNS, si kwenye usambazaji. Ikiwa kila lengwa zaidi ya anwani ya peer linamaliza muda, ikiwa ni pamoja na IP tupu, anza na namespace.

Soma mpangilio ndani ya namespace

Kila pod inapata namespace yake ya mtandao, na net.ipv4.ip_forward ni sysctl kwa kila namespace. Kuibadilisha kwenye node hakikuambii chochote kuhusu kontena, na ni njia ya kuaminika ya kutumia mchana kwenye mashine isiyofaa.

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

Sifuri inathibitisha utambuzi. Thamani pia hairithi kutoka kwa usanidi wa wakati wa utekelezaji wa node: huanza kutoka chaguo-msingi la taswira kila mara kontena linapoundwa. Kwa hiyo marekebisho yaliyotumika kwa mkono kwa kubectl exec ... sysctl -w hupotea kwenye uanzishaji upya unaofuata na hurudi kama hitilafu inayoonekana ya vipindi.

Kuiwezesha ili manifest iihifadhi

Chaguo la kudumu ni kontena la init linaloendesha katika pod sandbox hiyo hiyo na kuandika thamani kabla kontena la VPN halijaanza. Kontena zilizo ndani ya pod hushiriki namespace ya mtandao, kwa hiyo mpangilio huhamia kwenye kontena kuu.

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

Hiyo privileged: true ndiyo mstari ambao wakaguzi wanapinga, na wana haki. Kuandika sysctl kunahitaji ama upendeleo au uwezo uliowekewa mipaka nyembamba, na nguzo inayoendesha Pod Security Standard yenye vikwazo inaweza kukataa kabisa kontena la init lenye upendeleo. Ikiwa admission inakataa pod, unajua wakati wa uundaji, jambo ambalo angalau ni la uaminifu na rahisi kusoma.

Mbadala safi zaidi ni orodha ya securityContext.sysctls katika ngazi ya pod, ambayo inaruhusu kubelet kutumia sysctl zenye namespace bila kumpa upendeleo kontena yoyote. Inashughulikia tu majina yaliyo kwenye orodha ya ruhusa ya nguzo. Ikiwa net.ipv4.ip_forward iko kwenye orodha hiyo inategemea jinsi kubelet iliwekwa, na pod inayoomba sysctl nje ya orodha hiyo inakataliwa kwenye admission au inakwama katika CreateContainerConfigError wakati sandbox inajaribiwa tena. Angalia orodha ya ruhusa kabla ya kudhani sehemu imevunjika.

Kabla ya kujenga mojawapo ya mbinu hizo kwa mkono, angalia kama chart tayari inaonyesha swichi, mara nyingi kama kitu kama ipForwardInitContainer: true. Kutumia thamani ya chart huweka faili yako ya override ndogo na kustahimili sasisho linalofuata, jambo ambalo marekebisho ya Deployment yaliyobanwa kwa mkono hayafanyi.

Nusu ya pili: njia ya kurudi na sera

Usambazaji umewashwa ni muhimu, hautoshi. Ikiwa wateja wanatumia bwawa la kibinafsi ambalo mtandao wa nguzo hauna njia kuelekea, majibu hayapati njia ya kurudi ndani ya handaki, na pod inapaswa kufunika trafiki hiyo kuelekea lengwa lake.

Sera inakaa juu ya hayo. Vitu vya NetworkPolicy na sheria za ngome za wingu hutathminiwa dhidi ya anwani ya chanzo ambayo pakiti hubeba baada ya tafsiri, kwa hiyo sheria iliyoandikwa kwa ajili ya bwawa la wateja inaweza kuacha kufanana kwa utulivu mara ufunikaji unapowezeshwa.

Wakati wateja wanahitaji kufikia huduma za ndani ya nguzo pekee, kumaliza VPN kwenye VIP ya huduma ni muundo mdogo kuliko kupanga njia kwenye mtandao wa pod. Pia huweka bwawa la wateja nje ya jedwali la njia la CNI kabisa.

Kutenga hatua inayoshindwa kutoka kwa mteja

Fanya kazi kuelekea nje na simama katika hatua ya kwanza ya ukimya. Anza na peer ya VPN, kisha jaribu anwani ya pod fulani, kisha VIP ya huduma, na baada ya hapo tu lengwa la umma. Kila mafanikio huhamisha mpaka hatua moja, na kila kushindwa hutaja safu inayostahili kuchunguzwa. Baada ya usambazaji wowote, ingia kwa exec na usome sysctl tena, kwa sababu pod iliyobadilishwa huanza kutoka chaguo-msingi la taswira na marekebisho ambayo hayakuwa kamwe kwenye manifest tayari yameondoka.

Nyaraka za Kubernetes kuhusu matumizi ya sysctl katika nguzo zinaorodhesha majina yapi yanaweza kuwekwa kupitia muktadha wa usalama wa pod, na ndiyo mahali pa kwanza pa kuangalia admission inapokataa mabadiliko.