क्यों nftables OpenVPN के क्लाइंट-से-क्लाइंट ट्रैफ़िक को नहीं देख सकता

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

सर्वर से होकर एक पैकेट का पीछा करें

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

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

कौन-सा मार्ग चला, यह तय करने वाला काउंटर परीक्षण

जो नियम लागू होना चाहिए उस पर एक काउंटर लगाएँ, जिन दो क्लाइंट के बीच वह नियम रोकना चाहिए उनके बीच स्थानांतरण चलाएँ, और बाद में काउंटर पढ़ें।

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

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

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

स्विच एक्सेस सूची नहीं है

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

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

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

फ़ॉरवर्डिंग बिंदु चुनना

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

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

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

नियम बदलने से पहले क्या जाँचें

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

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