नीति राउटिङ सक्रिय नभएसम्म LAN क्लाइन्टहरूले राउटर VPN लाई बेवास्ता गर्छन्

राउटर आफ्नो टनेलबाट इन्टरनेट पुग्छ, तर त्यसको पछाडिको ल्यापटपले अझै 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 मा रहनुपर्ने दोस्रो क्लाइन्ट, र नयाँ जडानको क्रममा टनेल काउन्टरहरू।