Kubernetes માં OpenVPN પોડ કંઈપણ ફોરવર્ડ કરતું નથી? ip_forward તપાસો

તમારો લેપટોપ લીલો ટનલ બતાવે છે, ક્લાયન્ટ લોગ કહે છે કે રૂટ પુશ થયા છે, અને જવાબ આપતું એકમાત્ર સરનામું VPN સર્વરનું પોતાનું ટનલ IP છે. તેની આગળના પિંગ તમે ગમે તેને નિશાન બનાવો તો પણ મરી જાય છે, પછી તે ClusterIP હોય, બીજા પોડનું સરનામું હોય કે જાહેર હોસ્ટનામ હોય. આ સંયોજન અસ્પષ્ટ નથી, નિદાનાત્મક છે: ડિકેપ્સ્યુલેશન કામ કરે છે, અને બીજી હોપ કરતું નથી.

મને આ Debian નોડ પર મળ્યું, જે chart દ્વારા ઇન્સ્ટોલ કરેલી OpenVPN ઇમેજ ચલાવતું હતું, અને ટનલ સહેલો ભાગ હતો. ક્લાયન્ટે 10.8.0.x લીઝ લીધી, 10.8.0.1 એ જવાબ આપ્યો, અને 10.96.0.10, ક્લસ્ટર DNS સેવા, ટાઇમઆઉટ થઈ ગઈ. સર્વર લોગમાં કંઈપણ બીમાર લાગતું ન હતું, અને તેથી જ લોકો iptables નિયમો ફરીથી લખવા લાગે છે જેમને તેમને ક્યારેય સ્પર્શવાની જરૂર ન હતી.

VPN પોડ એ રાઉટર છે, અને તે સ્પષ્ટ કહેવા જેવું છે. એન્ક્રિપ્ટેડ પેકેટ આવે છે, પોડના પોતાના નેટવર્ક નેમસ્પેસમાં ખોલવામાં આવે છે, અને પછી બીજા ઇન્ટરફેસ દ્વારા બહાર જવું પડે છે. Linux આ બીજા પગલાને નકારે છે જ્યાં સુધી તે જ નેમસ્પેસની અંદર ફોરવર્ડિંગ ચાલુ ન હોય.

ક્લાયન્ટ શું પહોંચી શકે છે અને શું નહીં

જે સરનામું જવાબ આપે છે તે ટનલ એન્ડપોઇન્ટનું છે, અને VPN પ્રોસેસ તેને સ્થાનિક રીતે ધરાવે છે, તેથી ફોરવર્ડિંગ બિલકુલ સંડોવાયેલું નથી. બાકીનું બધું, બીજો પોડ, સેવા VIP કે ઇન્ટરનેટ સહિત, કર્નલને tun0 થી eth0 સુધી પેકેટ ખસેડવાની જરૂર છે. જ્યારે તે હલચલ નકારવામાં આવે છે, ત્યારે લક્ષણ નકાર નહીં પણ સમાન સન્નાટો છે, કારણ કે ટનલ નીચે પાછું કોઈ ICMP ભૂલ ઉત્પન્ન થતી નથી. તમને ટાઇમઆઉટ મળે છે, અપ્રાપ્ય સંદેશા નહીં, અને એ જ સંકેત છે કે કોઈ પણ રાઉટ કરતું નથી.

બે મિનિટનું વર્ગીકરણ સ્તરને સાંકડું કરે છે. જો DNS નામ નિષ્ફળ જાય જ્યારે સેવા IP પરના કાચા પિંગ સફળ થાય, તો સમસ્યા ફોરવર્ડિંગમાં નહીં, DNS પ્લમ્બિંગમાં છે. જો પીઅર સરનામા પછીનું દરેક લક્ષ્ય ટાઇમઆઉટ થાય, નક્કર IP સહિત, તો નેમસ્પેસથી શરૂ કરો.

નેમસ્પેસની અંદરનું સેટિંગ વાંચો

દરેક પોડને પોતાનું નેટવર્ક નેમસ્પેસ મળે છે, અને net.ipv4.ip_forward એ દરેક નેમસ્પેસ માટે sysctl છે. નોડ પર તેને બદલવાથી કન્ટેનર વિશે કંઈ ખબર પડતી નથી, અને તે ખોટી મશીન પર બપોર પસાર કરવાની ભરોસાપાત્ર રીત છે.

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

શૂન્ય નિદાનની પુષ્ટિ કરે છે. મૂલ્ય નોડના રનટાઇમ કન્ફિગરેશનથી પણ વારસામાં મળતું નથી: દર વખતે કન્ટેનર બને ત્યારે તે ઇમેજના ડિફોલ્ટથી શરૂ થાય છે. તેથી kubectl exec ... sysctl -w વડે હાથે લગાવેલો સુધારો આગલા રીસ્ટાર્ટમાં અદૃશ્ય થાય છે અને અસ્થિર લાગતા ખામી તરીકે પાછો આવે છે.

તેને ચાલુ કરવું જેથી મેનિફેસ્ટ તેને રાખે

ટકાઉ વિકલ્પ એ init કન્ટેનર છે જે એ જ પોડ સેન્ડબોક્સમાં ચાલે છે અને VPN કન્ટેનર શરૂ થાય તે પહેલાં મૂલ્ય લખે છે. પોડમાંના કન્ટેનર એક નેટવર્ક નેમસ્પેસ વહેંચે છે, તેથી સેટિંગ મુખ્ય કન્ટેનરમાં પસાર થાય છે.

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

તે privileged: true એ જ લાઇન છે જેની સામે સમીક્ષકો દલીલ કરે છે, અને તેઓ સાચા છે. sysctl લખવા માટે કાં તો વિશેષાધિકાર જોઈએ કાં તો સાંકડી ક્ષમતા, અને પ્રતિબંધિત Pod Security Standard ચલાવતું ક્લસ્ટર વિશેષાધિકારવાળા init કન્ટેનરને સીધું નકારી શકે છે. જો admission પોડને નકારે, તો તમે બનાવટ સમયે જાણી શકો છો, જે ઓછામાં ઓછું પ્રામાણિક અને વાંચવામાં સહેલું છે.

વધુ સ્વચ્છ વિકલ્પ પોડ-સ્તરીય securityContext.sysctls યાદી છે, જે kubelet ને કોઈ પણ કન્ટેનરને વિશેષાધિકાર આપ્યા વિના નેમસ્પેસ્ડ sysctl લાગુ કરવા દે છે. તે ફક્ત ક્લસ્ટરની મંજૂર યાદીના નામોને આવરી લે છે. net.ipv4.ip_forward તે યાદીમાં છે કે નહીં તે kubelet કેવી રીતે ગોઠવાયું તેના પર આધાર રાખે છે, અને તેની બહાર sysctl માંગતું પોડ admission માં નકારાય છે અથવા સેન્ડબોક્સ ફરી પ્રયાસ કરતી વખતે CreateContainerConfigError માં અટકી જાય છે. ફીલ્ડ તૂટેલું છે એમ માનતા પહેલાં મંજૂર યાદી તપાસો.

બંનેમાંથી કોઈપણ અભિગમ હાથે બનાવતા પહેલાં, જુઓ કે chart પહેલેથી સ્વિચ બહાર ધરાવે છે કે નહીં, ઘણી વાર ipForwardInitContainer: true જેવું કંઈક તરીકે. chart નું મૂલ્ય વાપરવાથી તમારી override ફાઇલ નાની રહે છે અને આગલા અપગ્રેડ સુધી ટકે છે, જે હાથે પેચ કરેલા Deployment ફેરફારો કરતા નથી.

બીજો અર્ધ: પરત માર્ગ અને નીતિ

ફોરવર્ડિંગ ચાલુ હોવું જરૂરી છે, પૂરતું નહીં. જો ક્લાયન્ટ્સ એવો ખાનગી પૂલ વાપરે જેના માટે ક્લસ્ટર નેટવર્ક પાસે કોઈ રૂટ ન હોય, તો જવાબો ટનલમાં પાછા રસ્તો શોધી શકતા નથી, અને પોડે એ ટ્રાફિકને તેના લક્ષ્ય તરફ માસ્ક કરવો પડે છે.

નીતિ તેની ઉપર બેસે છે. NetworkPolicy ઑબ્જેક્ટ્સ અને ક્લાઉડ ફાયરવૉલ નિયમો અનુવાદ પછી પેકેટ વહન કરતા સ્રોત સરનામા સામે મૂલ્યાંકન પામે છે, તેથી ક્લાયન્ટ પૂલ માટે લખાયેલો નિયમ માસ્કિંગ ચાલુ થાય ત્યારે ચૂપચાપ મેળ ખાવાનું બંધ કરી શકે છે.

જ્યારે ક્લાયન્ટ્સને ફક્ત ક્લસ્ટરની અંદરની સેવાઓ સુધી પહોંચવાનું હોય, ત્યારે VPN ને સેવા VIP પર સમાપ્ત કરવું પોડ નેટવર્કમાં રાઉટ કરવા કરતાં નાનું ડિઝાઇન છે. તે ક્લાયન્ટ પૂલને CNI ના રાઉટિંગ ટેબલની બહાર પણ રાખે છે.

નિષ્ફળ હોપને ક્લાયન્ટથી અલગ કરવી

બહાર તરફ કામ કરો અને પહેલા શાંત પગલે થોભો. VPN પીઅરથી શરૂ કરો, પછી કોઈ પોડનું સરનામું પ્રયત્ન કરો, પછી સેવા VIP, અને તે પછી જ જાહેર લક્ષ્ય. દરેક સફળતા સીમાને એક હોપ આગળ ખસેડે છે, અને દરેક નિષ્ફળતા જે સ્તર તપાસવા લાયક છે તેનું નામ આપે છે. કોઈપણ રોલઆઉટ પછી, exec કરીને અંદર જાઓ અને sysctl ફરી વાંચો, કારણ કે બદલાયેલો પોડ ઇમેજના ડિફોલ્ટથી શરૂ થાય છે અને મેનિફેસ્ટમાં ક્યારેય નહોતો તેવો સુધારો પહેલેથી જ ગયો છે.

Kubernetes નું દસ્તાવેજીકરણ ક્લસ્ટરમાં sysctl ના ઉપયોગ પર યાદી આપે છે કે કયા નામ પોડ સિક્યુરિટી કોન્ટેક્સ્ટ દ્વારા સેટ કરી શકાય, અને admission ફેરફાર નકારે ત્યારે ત્યાં જ પહેલાં જોવું જોઈએ.