VPN गिरने पर कुछ भी लीक न हो, इसके लिए Linux का इग्रेस कैसे लॉक करें

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

लोकल आउटपुट फ़ॉरवर्डिंग से अलग हुक है

मशीन पर किसी ऐप्लिकेशन से निकलने वाला पैकेट आउटपुट हुक से गुज़रता है; मशीन जिस पैकेट को किसी दूसरे होस्ट के लिए रूट करती है वह फ़ॉरवर्ड से गुज़रता है। जो नीति सिर्फ़ forward का ज़िक्र करती है वह दूसरे को सीमित करती है और पहले को पूरी तरह खुला छोड़ देती है, इसीलिए इतने इग्रेस लॉक सही दिखते हैं और कुछ नहीं करते। इंटरफ़ेस मिलान उसी नियम में आता है: oifname "tun0" accept उस ट्रैफ़िक को पास करता है जो पहले ही टनल से रूट हो चुका है। राउटिंग और फ़िल्टरिंग भी अलग फ़ैसले रहते हैं, इसलिए फ़िल्टर के पैकेट ठुकराने पर भी अपलिंक रूट मौजूद हो सकता है। आप इसी अलगाव पर भरोसा कर रहे हैं।

दूसरे डिवाइसों के लिए फ़ॉरवर्ड करने वाले गेटवे को दोनों हुक चाहिए। सिर्फ़ आउटपुट लॉक करना मशीन की हिफ़ाज़त करता है और नीचे के हर क्लाइंट को लीक करने की छूट दे देता है।

अपवादों की सूची एंडपॉइंट से बाहर की ओर लिखें

टनल के एंडपॉइंट से शुरू करें: एक गंतव्य पता या छोटा मंज़ूर सेट, ट्रांसपोर्ट प्रोटोकॉल और गंतव्य पोर्ट, जैसे udp dport 1194 ip daddr 203.0.113.7 accept। अगर क्लाइंट होस्टनाम हल करता है तो बूटस्ट्रैप DNS अदला-बदली को अपना नियम चाहिए, जो रिज़ॉल्वर और पोर्ट 53 तक सीमित हो, उस रिज़ॉल्वर के पते को खुली छूट नहीं। हर अपवाद को वह कारण बताना चाहिए जिसके लिए वह मौजूद है। VPN पोर्ट पर सारे UDP ट्रैफ़िक की इजाज़त उस एक प्रमाणित सेवा से कहीं ज़्यादा कवर करती है जो आपके मन में थी।

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

लोकल प्रशासन को भी वही व्यवहार चाहिए। मैनेजमेंट सबनेट सिर्फ़ इसलिए भरोसेमंद नहीं होता कि उसके पते निजी हैं, और उस पर भरोसा करने वाला नियम लॉक के चारों ओर दूसरा रास्ता बुलाता है।

इंटरफ़ेस मिलान स्वस्थ टनल का सबूत नहीं है

जो नियम tun0 से निकलने वाली हर चीज़ स्वीकार करते हैं वे मान लेते हैं कि उस इंटरफ़ेस पर पैकेट टनल से आया है। इंटरफ़ेस के नाम फिर से बनते हैं, और नाम कोई क्रिप्टोग्राफ़िक पहचान नहीं है। पीयर भी जा सकता है जबकि इंटरफ़ेस ऊपर बना रहता है, जो नियम को बहुत भरोसेमंद निष्क्रियता बना देता है।

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

डेमन क्रैश के बाद क्या बचता है

टनल ऊपर आने के बाद चलने वाली स्क्रिप्ट जो फ़िल्टर लगाती है वह टनल के साथ ही ग़ायब हो जाता है, ठीक उसी पल जब उसकी ज़रूरत थी। लॉक को बूट पर लोड करें और डेमन को सिर्फ़ उसके अपवाद संभालने दें।

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

तैनाती से पहले वसूली का रास्ता

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

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