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 नियमही तसाच आहे. शेवटी अशा स्रोताकडून एक विनंती पाठवा जिचा नकार अपेक्षित आहे आणि नकार धोरणातून येतो, गायब मार्गातून नाही याची पुष्टी करा.