Kubernetes मधील OpenVPN पॉड काहीही फॉर्वर्ड करत नाही? ip_forward तपासा

तुमचा लॅपटॉप हिरवा बोगदा दाखवतो, क्लायंट लॉग सांगतो की मार्ग पुश झाले, आणि उत्तर देणारा एकमेव पत्ता VPN सर्व्हरचाच बोगदा IP आहे. त्यापुढील पिंग तुम्ही काहीही लक्ष्य करा, मरतात, तो ClusterIP असो, दुसऱ्या पॉडचा पत्ता असो किंवा सार्वजनिक होस्टनाव असो. हे संयोजन अस्पष्ट नाही, निदानात्मक आहे: डीकॅप्स्युलेशन काम करते, आणि दुसरी हॉप करत नाही.

मला हे chart ने इन्स्टॉल केलेली OpenVPN इमेज चालवणाऱ्या Debian नोडवर आढळले, आणि बोगदा सोपा भाग होता. क्लायंटने 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 ने हाताने लावलेली दुरुस्ती पुढच्या रिस्टार्टला नाहीशी होते आणि अधूनमधून दिसणारी बिघाड म्हणून परत येते.

मॅनिफेस्ट ती ठेवेल अशा प्रकारे सुरू करणे

टिकाऊ पर्याय म्हणजे त्याच पॉड सँडबॉक्समध्ये चालणारा आणि VPN कंटेनर सुरू होण्यापूर्वी मूल्य लिहिणारा init कंटेनर. पॉडमधील कंटेनर एकच नेटवर्क नेमस्पेस वाटून घेतात, त्यामुळे सेटिंग मुख्य कंटेनरमध्ये जाते.

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 ने बदल नाकारल्यावर सर्वप्रथम तिथेच पाहावे.