OpenVPN क्लाइंट ब्लॉक नियम FORWARD तक कभी क्यों नहीं पहुँचता

एक ही OpenVPN सर्वर पर दो क्लाइंट अपने पूल के लिए DROP नियम जोड़ने के बाद भी एक-दूसरे तक पहुँच सकते हैं। नियम FORWARD श्रृंखला में बैठा है, ट्रैफ़िक स्पष्ट रूप से बह रहा है, और उस नियम का काउंटर शून्य पर ही रहता है। स्वाभाविक निष्कर्ष यह है कि फ़ायरवॉल टूटा हुआ है। अधिकतर पैकेट श्रृंखला में आया ही नहीं।

OpenVPN सर्वर से होकर पीयर पैकेट दो रास्तों से जा सकता है, और इन्हें कॉन्फ़िगरेशन तय करता है, फ़ायरवॉल नहीं। यह जानना कि कौन-सा रास्ता इस्तेमाल में है, आपको बताता है कि होस्ट नियम ठीक जगह पर है या नहीं।

पीयर पैकेट किन दो रास्तों से जा सकता है

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

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

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

जब काउंटर कभी नहीं हिलता

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

तीसरा स्थान है। श्रृंखला में पहले का नियम आपके DROP के मूल्यांकन से पहले प्रवाह स्वीकार कर सकता है, और बाद का नियम वह हो सकता है जो परिणाम वास्तव में तय करता है। काउंटर दिखाकर श्रृंखला क्रम से पढ़ें, फिर जाँचें कि परीक्षण दोहराने पर किस नियम की गिनती बढ़ती है।

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

ऐसी सीमा चुनना जो फ़िल्टर कर सके

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

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

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

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

नियम पर भरोसा करने के बजाय अलगाव जाँचना

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

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

अलगाव उस सीमा पर देखा गया परिणाम है जो वास्तव में प्रवाह को ले जाती है। होस्ट में कहीं भी DROP नियम साक्ष्य नहीं है; विफल कनेक्शन के साथ उस नियम का खिसका हुआ काउंटर साक्ष्य है।