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 नियम भी जो ऐसे पते से बँधा हो जो अब मौजूद नहीं। अंत में ऐसे स्रोत से एक अनुरोध भेजें जिसके अस्वीकार होने की अपेक्षा है और पुष्टि करें कि अस्वीकृति नीति से आती है, किसी गायब रूट से नहीं।