Kubernetes भित्र VPN क्लाइन्ट IP: यसलाई जोगाउने कि SNAT गर्ने?
Kubernetes भित्र VPN क्लाइन्टको वास्तविक ठेगाना र स्रोत NAT बीच तीन सर्तका आधारमा छान्नुहोस्, त्यसपछि फर्कने बाटो र pod परिवर्तन जाँच्नुहोस्।
कतै टनेल र backend बीच क्लाइन्टको ठेगाना या त बाँच्छ वा प्रतिस्थापित हुन्छ, र दुवै नतिजा रक्षायोग्य छन्। छनोट प्राप्त गर्ने सेवाको मालिकको हो, CNI स्थापना गर्नेको होइन। जब प्रति-क्लाइन्ट अधिकार, कोटा वा अडिट रेकर्ड महत्त्वपूर्ण हुन्छ, ठेगानाले हरेक हप पार गर्नुपर्छ। जब साझा आरोपण स्वीकार्य हुन्छ, स्रोत NAT ले त्यो राउटिङ समस्या हटाउँछ जुन अन्यथा तपाईं सधैं जोगाउनुहुन्थ्यो।
ठेगाना साँच्चै कहाँ हराउँछ
टाढाको क्लाइन्टको प्याकेट VPN pod सम्म टनेल दायराभित्रको आन्तरिक स्रोतसहित पुग्छ, मानौं 10.90.0.42। जब pod ले त्यो प्याकेट ClusterIP वा pod IP तर्फ अगाडि पठाउँछ, तीन फरक संयन्त्रले स्रोत फेरि लेख्न सक्छन्। नोडको CNI masquerade नियमले pod ले क्लस्टर CIDR बाहिर पठाउने ट्राफिक ढाक्छ। गन्तव्य नोडमा kube-proxy को conntrack प्रविष्टिले आफैं Service हप ढाक्छ। जुन प्रोक्सीले जडान अन्त्य गर्छ त्यसले प्याकेट अगाडि पठाउँदैन, त्यसैले अन्तमा देखिने स्रोत त्यही प्रोक्सीको हुन्छ।
यीमध्ये हरेक फरक तहमा बस्छ, त्यसैले एउटा Service फिल्डले लगभग कहिल्यै पूरा बाटो सुधार्दैन।
VPN को सार्वजनिक Service मा externalTrafficPolicy ले बाह्य जडानको मात्र निर्णय गर्छ: Local ले टाढाको ठेगाना त्यो नोडमा राख्छ जसले त्यो प्राप्त गर्यो, जबकि Cluster ले kube-proxy लाई प्याकेट अर्को नोडलाई दिन र त्यहाँ masquerade गर्न अनुमति दिन्छ। त्यो सेटिङले तपाईंका क्लाइन्ट जोडिने लिसनर नियन्त्रण गर्छ। यसले तपाईंको VPN प्रक्रियाले पछि क्लस्टरमा पठाउने डिक्रिप्ट भएको प्याकेटबारे केही भन्दैन।
बहस टुंग्याउने तीन सर्त
यो विषय आउँदा म सधैं त्यही तीन प्रश्न त्यही क्रममा सोध्छु, किनकि पहिलोले प्रायः छलफल अन्त्य गर्छ। तिनीहरूको उत्तर विशेष कार्यभारका लागि दिनुहोस्, पूरै क्लस्टरका लागि होइन। एउटै कम्पनीका दुई क्लस्टर फरक उत्तरमा पुग्न सक्छन् र दुवै सही हुन सक्छन्।
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
यदि backend ले पहिलो प्रश्नमा हो र दोस्रोमा होइन भन्छ भने तपाईंसँग नेटवर्कको काम छ, manifest सम्पादन गर्ने होइन। यदि तेस्रो पङ्क्तिले प्रोक्सी भन्छ भने ठेगाना कहिल्यै बाँच्ने थिएन, र उल्टो दाबी गर्न एक हप्ताको प्याकेट क्याप्चर खर्च हुन्छ।
preserve मोडले नेटवर्कबाट के माग्छ
स्रोत जोगाउनु भन्नाले गन्तव्य नोडले ट्राफिक सक्रिय VPN गेटवेमार्फत 10.90.0.42 मा फर्काउनुपर्छ। VPN पूल क्लस्टर CIDR होइन, त्यसैले कुनै CNI ले यसलाई तपाईंका लागि पूर्वनिर्धारित रूपमा राउट गर्दैन। तपाईं आफैं मार्ग थप्नुहुन्छ र त्यसपछि गेटवेको त्यो अन्त्य बिन्दु जसतर्फ यो सङ्केत गर्छ पुनर्निर्धारणबाट बाँच्छ भन्ने सुनिश्चित गर्नुहुन्छ।
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2त्यो अर्को हप pod को ठेगाना हो, र pod का ठेगाना सर्छन्। मार्गलाई Service VIP वा ठाउँमै रहने नोड ठेगानातर्फ मोड्नुहोस्, वा हरेक निष्कासनपछि तपाईं गेटवेको पछि दौडनुहुनेछ भन्ने स्वीकार गर्नुहोस्। उल्टो बाटोको फिल्टरिङ अर्को जाल हो: कडा मोडले ती प्याकेट फ्याँक्छ जसको फर्कने बाटो आएको इन्टरफेससँग मेल खाँदैन, र यो ठ्याक्कै जोगाइएको VPN प्रवाहको आकार हो।
हलुका प्रमाणीकरण प्रायः काम गर्ने फर्कने बाटो र backend छोडेपछि हराउने उत्तरहरू बीचको फरक हो। VPN नोडका masquerade नियमहरूले पनि टनेल दायरा बाहिर राख्नुपर्छ, नत्र अगाडि पठाइएको प्याकेट pod को ठेगानासहित बाहिर निस्कन्छ, तपाईंले जुनसुकै मार्ग बनाउनुभए पनि। यो अपवाद iptables हातले सम्पादन गर्नुको सट्टा CNI को आफ्नै कन्फिगरेसनमा व्यक्त गर्नुहोस्, किनकि एजेन्टले पुनः सुरु हुँदा आफ्ना शृंखलाहरू फेरि लेख्छ र तपाईंको हातले लेखिएको नियम ठ्याक्कै अर्को अपग्रेडसम्म टिक्छ।
NetworkPolicy पहुँच नियन्त्रण हो, राउटिङ होइन। नीति कडा बनाउँदा masquerade ले पहिले नै बदलेको ठेगाना कहिल्यै पुनर्स्थापित हुँदैन।
SNAT को के खर्च छ, र यसलाई कसरी लेख्ने
क्लस्टरतर्फ स्रोत NAT सस्तो डिजाइन हो, र यो गल्ती होइन। backend ले VPN pod वा नोडको ठेगाना देख्छ, लगहरू एकअर्कासँग मिल्छन्, र कुनै फर्कने मार्ग हुनु आवश्यक छैन। तपाईंले गुमाउने कुरा नेटवर्क तहमा दुई क्लाइन्ट छुट्याउने क्षमता हो, त्यसैले कोटा, प्रतिबन्ध र अडिट चिन्हहरू अन्यत्रबाट आउनुपर्छ।
सामान्यतया त्यो अन्यत्र भनेको अनुप्रयोग हो: सत्र टोकन, हस्ताक्षर गरिएको हेडर, वा PROXY प्रोटोकलको पङ्क्ति जुन तपाईंको नियन्त्रणको प्रोक्सीले लेख्छ। यीले प्राप्तकर्तालाई त्यस्तो पहिचान दिन्छ जसलाई उसले प्रोक्सी बाटोमा हुँदा र हेडर क्लाइन्टतर्फबाट सेट गर्न नसकिँदा मात्र विश्वास गर्न सक्छ। runbook मा कुन लागू हुन्छ स्पष्ट भन्नुहोस्, किनकि अर्को इन्जिनियरले लगमा भएको ठेगाना क्लाइन्ट हो भनी मान्नेछ। त्यस्तो होइन, र एउटा घटना त्यो अनुमान महँगो बनाउन पर्याप्त छ।
साटासाट लेखिएको अवस्थामा मात्र इमानदार रहन्छ।
काम गर्ने बाटोलाई भाग्यमानी बाटोबाट छुट्याउने जाँचहरू
ताजा जडानले जाँच्नुहोस्, क्यास गरिएको जडानले होइन, र दुवै दिशामा जाँच्नुहोस्। धेरै असफलता फेरि लेखिएको बाटो नयाँ प्रवाहले लिने भएकाले मात्र रोकिँदै अटेर जस्तो देखिन्छ।
एउटा अधिकृत अनुरोधका क्रममा tuple तीन बिन्दुमा समात्नुहोस्: डिक्रिप्शनपछि तुरुन्तै, VPN pod को निर्गमन इन्टरफेसमा, र backend मा। यदि स्रोत दोस्रो र तेस्रो समाताइबीच बदलिन्छ भने कारण pod भन्दा तल छ। यदि दोस्रोपछि बदलिन्छ भने pod आफैं अनुवाद गर्दैछ।
त्यसपछि VPN pod मेट्नुहोस् र पुनर्निर्धारणका क्रममा परीक्षण दोहोर्याउनुहोस्। निष्कासनमा टुट्ने जोगाइएको बाटो अपूर्ण हुन्छ, र अब नभएको ठेगानामा बाँधिएको NAT नियम पनि त्यस्तै हुन्छ। अन्तमा अस्वीकार हुने अपेक्षा गरिएको स्रोतबाट एउटा अनुरोध पठाउनुहोस् र अस्वीकार नीतिबाट आउँछ, हराएको मार्गबाट होइन भनी पुष्टि गर्नुहोस्।