Pod ɗin OpenVPN a Kubernetes baya turawa? Duba ip_forward

Kwamfutar tafi-da-girgijenka tana nuna koren rami, log ɗin abokin ciniki ya ce an tura hanyoyi, kuma adireshin da ke amsa shi kaɗai shi ne IP ɗin ramin sabar VPN ɗin kanta. Ping ɗin da ya wuce shi yana mutuwa ko me ka nufa, ko ClusterIP ne, adireshin wani pod, ko sunan mai masauki na jama'a. Wannan haɗin ba shi da shubuha, yana da ganewar asali: buɗewa yana aiki, kuma tsallen na biyu ba ya aiki.

Na ci karo da wannan a kan node ɗin Debian da ke gudanar da hoton OpenVPN da aka saka ta chart, kuma ramin shi ne sassauƙa. Abokin ciniki ya karɓi hayar 10.8.0.x, 10.8.0.1 ya amsa, kuma 10.96.0.10, sabis ɗin DNS na cluster, ya ƙare da lokaci. Babu abin da ya yi kama da rashin lafiya a log ɗin sabar, kuma shi ya sa mutane suke fara sake rubuta dokokin iptables da ba su taɓa buƙatar taɓawa ba.

Pod ɗin VPN mai turawa ne, kuma ya dace a faɗi haka sarai. Fakitin da aka ɓoye suna zuwa, ana buɗe su a cikin namespace ɗin cibiyar sadarwar pod ɗin kansa, sannan dole su fita ta wata hanya daban. Linux yana ƙin wannan mataki na biyu sai an kunna turawa a cikin wannan namespace ɗin.

Abin da abokin ciniki zai iya kaiwa da abin da ba zai iya ba

Adireshin da ke amsa na ƙarshen ramin ne, kuma tsarin VPN yana da shi a gida, don haka turawa ba ta shiga ko kaɗan. Duk sauran, ciki har da wani pod, VIP ɗin sabis ko intanet, suna buƙatar kernel ya motsa fakiti daga tun0 zuwa eth0. Idan aka ƙi wannan motsi, alamar ita ce shiru ɗaya maimakon ƙi, domin babu abin da ke haifar da kuskuren ICMP a baya cikin ramin. Kana samun lokacin ƙarewa, ba saƙonnin rashin isa ba, kuma wannan ita ce alamar cewa babu wanda ke yin turawa kwata-kwata.

Mintuna biyu na rarrabawa suna taƙaita Layer ɗin. Idan sunayen DNS sun kasa yayin da ping ɗin danye zuwa IP ɗin sabis ya yi nasara, matsalar tana cikin aikin DNS, ba turawa ba. Idan kowane manufa da ya wuce adireshin peer ya ƙare da lokaci, har da IP tsirara, fara daga namespace ɗin.

Karanta saitin a cikin namespace ɗin

Kowane pod yana samun namespace ɗin cibiyar sadarwarsa, kuma net.ipv4.ip_forward sysctl ne na kowane namespace. Canza shi a node ba ya gaya maka komai game da container, kuma hanya ce abin dogaro don yin la'asar a kan injin da bai dace ba.

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

Sifili yana tabbatar da ganewar asali. Ba a gadon darajar daga tsarin tafiyar da node ba kuma: tana farawa daga tsohon hoton duk lokacin da aka ƙirƙiri container. Don haka gyaran da aka yi da hannu da kubectl exec ... sysctl -w yana ɓacewa a sake kunnawa na gaba kuma yana dawowa a matsayin kuskuren da ke kama da lokaci-lokaci.

Kunna shi don manifest ɗin ya riƙe shi

Zaɓin dawwama shi ne init container da ke gudana a cikin sandbox ɗin pod ɗaya kuma ya rubuta darajar kafin container ɗin VPN ya fara. Containers a cikin pod suna raba namespace ɗin cibiyar sadarwa, don haka saitin yana wucewa cikin babban container.

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

Wancan privileged: true shi ne layin da masu bita ke adawa da shi, kuma suna da gaskiya. Rubuta sysctl yana buƙatar ko dai gata ko wata iyaka ta kusa, kuma cluster da ke gudanar da ƙayyadadden Pod Security Standard na iya ƙin init container mai gata gaba ɗaya. Idan admission ya ƙi pod ɗin, kana sane a lokacin ƙirƙira, wanda aƙalla gaskiya ne kuma mai sauƙin karantawa.

Mafi tsaftataccen madadin shine jerin securityContext.sysctls na matakin pod, wanda ke ba kubelet damar amfani da sysctl ɗin namespace ba tare da ba da gata ga kowane container ba. Yana rufe sunayen da ke cikin jerin izini na cluster kawai. Ko net.ipv4.ip_forward yana cikin wannan jerin ya dogara da yadda aka daidaita kubelet, kuma pod ɗin da ke neman sysctl a wajen ta ana ƙin sa a admission ko ya makale a CreateContainerConfigError yayin da ake sake gwada sandbox. Duba jerin izini kafin ka ɗauka cewa filin ya lalace.

Kafin ka gina ɗaya daga cikin hanyoyin biyu da hannu, duba ko chart ɗin ya riga ya bayyana maɓallin, sau da yawa a matsayin wani abu kamar ipForwardInitContainer: true. Amfani da darajar chart yana barin fayil ɗin override ɗinka ƙarami kuma yana tsira daga haɓakawa na gaba, abin da gyare-gyaren Deployment na hannu ba sa yi.

Rabin na biyu: hanyar dawowa da manufa

Kunna turawa wajibi ne, bai isa ba. Idan abokan ciniki suna amfani da wurin ajiya na sirri wanda cibiyar sadarwar cluster ba ta da hanya zuwa gare shi, amsoshi ba za su iya samun hanyar komawa cikin ramin ba, kuma pod ɗin dole ya rufe wannan zirga-zirgar zuwa inda za a je.

Manufa tana zaune a kan wannan. Ana auna abubuwan NetworkPolicy da dokokin wutar waje na girgije da adireshin tushen da fakiti ke ɗauka bayan fassarar, don haka dokar da aka rubuta domin wurin ajiyar abokan ciniki na iya daina dacewa a shiru da zarar an kunna rufewa.

Lokacin da abokan ciniki kawai suke buƙatar isa ga sabis ɗin cikin cluster, ƙarewar VPN a VIP ɗin sabis ƙaramin tsari ne fiye da turawa cikin cibiyar sadarwar pod. Hakanan yana kiyaye wurin ajiyar abokan ciniki gaba ɗaya a wajen teburin turawa na CNI.

Keɓe tsallen da ya kasa daga abokin ciniki

Yi aiki zuwa waje kuma tsaya a mataki na farko na shiru. Fara da peer ɗin VPN, sannan gwada adireshin wani pod, sannan VIP ɗin sabis, kuma bayan haka kawai manufa ta jama'a. Kowace nasara tana motsa iyaka tsalle ɗaya, kuma kowace gazawa tana ambaton Layer ɗin da ya cancanci dubawa. Bayan kowace turawa, shiga da exec ka sake karanta sysctl ɗin, domin pod ɗin da aka maye gurbinsa yana farawa daga tsohon hoton, kuma gyaran da bai taɓa kasancewa cikin manifest ɗin ya riga ya tafi.

Takardun Kubernetes game da amfani da sysctl a cikin cluster suna lissafa waɗanne sunaye za a iya saita ta hanyar mahallin tsaro na pod, kuma ita ce wuri na farko da za a duba lokacin da admission ya ƙi canjin.