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 ले परिवर्तन अस्वीकार गर्दा सबैभन्दा पहिले त्यहीँ हेर्नुपर्छ।