VPN साइडकार के लिए किल स्विच: बाहर निकलने पर ट्रैफ़िक रोकें

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

नेमस्पेस साझा करना किल स्विच क्यों नहीं है

नेमस्पेस साझा करने का अर्थ है कि ऐप VPN कंटेनर के इंटरफ़ेस, पते और रूट तालिका उपयोग करता है। यह साझा नेमस्पेस के सुरक्षित रहने तक ऐप का नेटवर्क तक स्वतंत्र रास्ता हटा देता है, और यह नहीं बताता कि टनल के जाने पर वह नेमस्पेस क्या करेगा।

Compose की निर्भरता शर्तें ऐप के शुरू होने को तब तक टाल सकती हैं जब तक कोई निर्भरता स्वस्थ न हो जाए। यह समय के एक क्षण को कवर करता है और किसी बाद की विफलता को नहीं, इसलिए यह स्टार्टअप क्रम का उपकरण है, निरंतर एग्रेस फ़ायरवॉल नहीं।

कंटेनर के बाहर निकलने पर वास्तव में क्या होता है

तीन घटनाओं में अंतर करें। कंटेनर के अंदर की VPN प्रक्रिया मर सकती है जबकि कंटेनर चलता रहता है। कंटेनर रुक सकता है या हटाया जा सकता है, जो नेमस्पेस को नष्ट कर देता है। कंटेनर फिर से बनाया जा सकता है, जो नया नेमस्पेस और नए नियम बनाता है।

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

स्पष्ट एग्रेस नीति बनाएँ

नीति को साझा नेमस्पेस के अंदर लिखें ताकि वह ऐप के पैकेट पर लागू हो। आकार डिफ़ॉल्ट ड्रॉप है संकीर्ण अपवादों के साथ: loopback, टनल का इंटरफ़ेस, और वह विशिष्ट एंडपॉइंट पता और पोर्ट जिसकी टनल परिवहन को आवश्यकता है।

एंडपॉइंट अपवाद टनल के ऊपर उठने से पहले मौजूद होना चाहिए, वरना VPN क्लाइंट अपने सर्वर तक नहीं पहुँच सकता। इसी कारण नियम समूह भौतिक इंटरफ़ेस को सामान्य रूप से अनुमति देने के बजाय बाहरी परिवहन को स्पष्ट रूप से अनुमति देता है। IPv6 नियम भी जोड़ें अगर नेमस्पेस में IPv6 कनेक्टिविटी है, क्योंकि केवल IPv4 वाली नीति दूसरे परिवार को खुला छोड़ देती है।

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

जीवनचक्र जाँचें, केवल डिस्कनेक्ट नहीं

जब टनल स्वस्थ हो तब एक ताज़ा हानिरहित अनुरोध भेजें, फिर VPN प्रक्रिया को मारें और एक और भेजें। कंटेनर रुकने, पुनःआरंभ और फिर से बनने के बाद दोहराएँ। ताज़ा अनुरोध मायने रखता है क्योंकि मौजूदा कनेक्शन ऐसे नियम परिवर्तन से बच सकता है जो नए को रोकता है।

ब्लॉकिंग तंत्र के रूप में हेल्थ चेक या एग्ज़िट IP खोज पर निर्भर न रहें। जाँच स्थिति देखती है और उसकी रिपोर्ट करती है; नीति ट्रैफ़िक नियंत्रित करती है। दोनों एक ही परिनियोजन के हैं, और वे एक-दूसरे के विकल्प नहीं हैं।

नियम दर्ज करें ताकि जाँच किसी अपडेट से बची रहे

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

VPN एंडपॉइंट के आवश्यक बाहरी पथ को ऐप के अप्रतिबंधित एग्रेस से अलग रखें, और DNS तथा IPv6 को इच्छित कवरेज में रखें। अगर नीति सुविधा के लिए पूरा भौतिक इंटरफ़ेस अनुमति देती है, तो किल स्विच जा चुका है। Docker का नेटवर्क दस्तावेज़ उस साझा नेमस्पेस व्यवस्था का वर्णन करता है जिस पर नीति बनी है, और रनटाइम के व्यवहार पर संदेह होने पर वही देखने योग्य संदर्भ है।