1.14 के बाद GKE पॉड्स ने VPN पहुँच खो दी: स्रोत ठीक करने के दो तरीके

1.14 के बाद पॉड्स अपने पते के साथ VPN तक पहुँचते हैं, इसलिए पीयर जवाब छोड़ देते हैं। स्रोत अनुबंध चुनें, फिर nonMasqueradeCIDRs उसके अनुसार सेट करें।

एक अपग्रेड आता है, और सुरंग के दूसरी ओर की प्रणालियाँ उस पॉड ट्रैफ़िक को अस्वीकार करने लगती हैं जो पिछले सप्ताह काम कर रहा था। सुरंग चालू है, फ़ायरवॉल नियम अछूते हैं, और किसी ने पीयर नीति संपादित नहीं की। जो बदला है वह क्लस्टर लॉग में अदृश्य है: वह स्रोत पता जो ये प्रणालियाँ अब देखती हैं। यही अंतर उस विफलता को समझाता है जो नेटवर्क बाधा जैसी दिखती है और अनुमति की समस्या जैसा व्यवहार करती है।

दो वैध उत्तर हैं, और वे अलग-अलग जगह ले जाते हैं। ConfigMap संपादित करने से पहले स्रोत अनुबंध चुनें।

वह डिफ़ॉल्ट नियम जो अब स्थापित नहीं होता

GKE के पुराने संस्करण एक masquerade नियम स्थापित करते थे जो गंतव्य 10.0.0.0/8 से बाहर होने पर पॉड स्रोतों को नोड पते से बदल देता था। उस श्रेणी के भीतर का VPN गेटवे पॉड पता देखता था, जबकि और दूर की कोई भी चीज़ नोड से आती दिखती थी। पीयर ने नोड पतों के आसपास अनुमति सूचियाँ और वापसी मार्ग बनाए क्योंकि उन्होंने यही देखा था।

बाद के संस्करणों ने वह डिफ़ॉल्ट नियम स्थापित करना बंद कर दिया। पॉड ट्रैफ़िक अब गंतव्य जो भी हो, पॉड पतों के साथ गेटवे पर पहुँचता है। जो पीयर केवल नोड पते रूट करता है वह जवाब छोड़ देता है, और कोई भी पक्ष उपयोगी लॉग प्रविष्टि नहीं लिखता। अनुरोध दूर के सिरे पर सफल भी हो सकता है, और यही विफलता का पीछा करना भ्रमित करने वाला बनाता है।

मृत घटक के अर्थ में कुछ टूटा नहीं है। दोनों पक्ष बस इस पर सहमत नहीं हैं कि कौन सा स्रोत वैध है।

वह स्रोत चुनें जो पीयर को दिखना चाहिए

पॉड पते रखना अधिक सटीक अनुबंध है। दूर का पक्ष वह कार्यभार देखता है जिसने ट्रैफ़िक उत्पन्न किया, लॉग ईमानदार रहते हैं, और प्रति-पॉड नीति संभव हो जाती है। कीमत यह है कि पीयर को पॉड उपसर्ग ढोना पड़ता है।

नोड पते रखना सस्ता अनुबंध है। उस गंतव्य के लिए masquerade फिर चालू करें और पीयर वही पता देखता रहेगा जिस पर उसे पहले से भरोसा है।

एक सवाल इनके बीच फ़ैसला करता है: पीयर स्रोत के साथ क्या करता है? अगर वह लॉग करता है, प्रति-स्रोत नीति लागू करता है या संकीर्ण वापसी मार्ग लागू करता है, तो पॉड पते अतिरिक्त कॉन्फ़िगरेशन को उचित ठहराते हैं। अगर उसे केवल जवाब भेजने हैं, तो masquerade कम खर्च करता है और दूसरे पक्ष से कुछ नहीं माँगता। जब तक दोनों टीमें इसे लिख कर रखती हैं, कोई भी विकल्प तर्कसंगत है।

तीसरा विकल्प आमतौर पर गलती है: सब कुछ masquerade करना और ट्रैफ़िक को निर्दिष्ट करने की क्षमता खो देना। इससे बचें जब तक कि पीयर वास्तव में नोड पतों के अलावा कुछ रूट न कर सके।

nonMasqueradeCIDRs को वास्तविक श्रेणियों पर इंगित करें

GKE kube-system में ip-masq-agent चलाता है, और उसका ConfigMap उन गंतव्यों को सूचीबद्ध करता है जो masquerade छोड़ देते हैं। सुरंग की ओर पॉड स्रोतों को सुरक्षित रखने के लिए पॉड श्रेणी, नोड सबनेट और स्थानीय उपसर्ग सभी उस सूची में आते हैं।

नमूना मानों को अपने क्लस्टर की श्रेणियों से बदलें। सूची को आवश्यकता से अधिक चौड़ा न करें, क्योंकि हर अतिरिक्त प्रविष्टि बदल देती है कि कोई दूसरा गंतव्य क्या देखता है। नीचे की तीन प्रविष्टियाँ पॉड नेटवर्क, नोड सबनेट और सुरंग के पीछे के उपसर्ग को दर्शाती हैं:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

0.0.0.0/0 प्रविष्टि सभी गंतव्यों के लिए masquerade बंद कर देती है, जो बदल देता है कि असंबंधित कार्यभार बाहरी सेवाओं को कैसे दिखते हैं और शायद ही कभी जानबूझकर होता है। एजेंट resyncInterval पर अपना कॉन्फ़िगरेशन फिर पढ़ता है, इसलिए फिर से शुरू करना आमतौर पर ज़रूरी नहीं है। जाँचें कि एजेंट पॉड चल रहा है, फिर उसके अंदर माउंट की गई फ़ाइल खोलें। उस फ़ाइल को पढ़ना ही साबित करता है कि बदलाव पहुँच गया।

जवाब का मार्ग दूसरा आधा है

masquerade केवल अनुरोध का स्रोत बदलता है और कुछ नहीं। पीयर को जो भी स्रोत मिले, उसे अब भी उस तक वापसी मार्ग चाहिए, और क्लस्टर को अब भी पीयर की ओर मार्ग चाहिए।

VPN गेटवे पर कैप्चर दोनों विफलताओं को जल्दी अलग करता है। पॉड पतों के साथ आने वाले और कभी जवाब न पाने वाले पैकेट का अर्थ है कि पीयर के पास पॉड उपसर्ग के लिए मार्ग नहीं है। गेटवे पर दिखने वाला पर क्लस्टर तक कभी न पहुँचने वाला जवाब का अर्थ है कि स्थानीय मार्ग गायब है। किसी भी स्थिति में अनुबंध टिकट में लिखें: पीयर कौन सा स्रोत देखता है, और किस उपसर्ग की ओर वापस रूट करता है।

हर अपग्रेड के बाद फिर जाँचें

masquerade का डिफ़ॉल्ट व्यवहार एक बार बदल चुका है, और नोड पूल का प्रतिस्थापन क्लस्टर नेटवर्किंग रीसेट कर सकता है। स्रोत अनुबंध को मान लेने वाली चीज़ नहीं, जाँचने वाली चीज़ मानें।

अपग्रेड के बाद एक पॉड से स्थानीय सेवा पर एक अनुरोध भेजें और वह स्रोत पढ़ें जो पीयर लॉग करता है। वही एक अवलोकन ऐसी रिग्रेशन पकड़ता है जिसे सुरंग स्थिति पृष्ठ खुशी से स्वस्थ बताएगा। इसे दोहराने में एक मिनट लगता है और अगले व्यक्ति की एक शाम बचती है।

संबंधित लेख