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

फ़िल्टर नियम इंटरफ़ेस नहीं चुन सकता

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

नीचे का उदाहरण br-lan पर 192.168.8.0/24 का LAN, एक टनल डिवाइस tun0, और 192.168.8.23 पर एक सेट-टॉप बॉक्स लेता है जिसे टनल से जाना चाहिए।

नियम संपादित करने से पहले लुकअप पढ़ें

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

ip -4 route get 198.51.100.7 from 192.168.8.23

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

जिन क्लाइंट को कवर करना है उनसे तालिका जोड़ें

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

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

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

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

स्थानीय गंतव्यों को टनल से बाहर रखें

नई तालिका केवल वही रूट जानती है जो आप उसमें डालते हैं। LAN प्रीफ़िक्स गायब है, इसलिए प्रिंटर और NAS ट्रैफ़िक टनल के डिफ़ॉल्ट का पालन करते हुए गायब हो जाता। एक throw रूट इस तालिका में लुकअप समाप्त करता है और निर्णय मुख्य तालिका को लौटा देता है।

ip -4 route add throw 192.168.8.0/24 table 200

उस रूट को छोड़ दें तो स्थानीय शेयर टूट जाते हैं, और अगर सेलेक्टर इरादे से अधिक व्यापक है तो राउटर का अपना प्रबंधन सत्र भी गायब हो सकता है। फिर स्रोत का सवाल तय करें: जो टनल पैकेट अब भी LAN पते ले जाते हैं, उन्हें दूसरी तरफ़ वापसी रास्ता पता होना चाहिए, जबकि टनल पर masquerading उस शर्त को हटा देता है और दूसरी तरफ़ जो क्लाइंट पहचान दिखेगी उसे भी हटा देता है।

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

संबंधित लेख