खाली VPN तालिका आफैंमा केही पनि रोक्दैन

नीति नियमले चिन्ह लगाइएका प्याकेटलाई समर्पित तालिकामा पठाउँछ, र सामान्य अपेक्षा यो हुन्छ कि VPN मार्ग गुम्दा ती रोकिन्छन्। तर संयन्त्रले अरू नै कुरा गर्छ। तालिकामा मिल्ने मार्ग नभएको बेला, खोजी अर्को नियमतिर अगाडि बढ्छ रोकिनुको सट्टा, र main तालिकामा अझै पनि uplink का लागि साधारण पूर्वनिर्धारित मार्ग छ। नतिजा यस्तो कन्फिगरेसन हो जुन fail-closed देखिन्छ तर fail-open जस्तो व्यवहार गर्छ।

केही पनि बिग्रिएको छैन; नीति-आधारित राउटिङ यसरी नै निर्धारित छ।

तालिकामा केही नभएपछि खोजी जारी रहन्छ

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

त्यो नियम-समूह लिनुहोस्: चिन्ह लगाइएको खोजी तालिका 42 मा जान्छ, र पछिल्लो नियमले त्यही चिन्ह default नामको तालिकामा पठाउँछ। तालिका 42 मा उपयोगी पूर्वनिर्धारित मार्ग रहेसम्म, पहिलो खोजीले बाटो दिन्छ। त्यो मार्ग हराउँदा र तालिका 42 मा अरू केही नमिल्दा, खोजी अस्वीकृतिमा परिणत हुँदैन; प्रशोधन अर्को नियमतिर जान्छ, र त्यसले पनि केही नभेट्दा main तालिकासम्म पुग्छ। त्यो क्रममा केहीले पनि कुन नियमले अन्तिम उत्तर दियो भनेर जानकारी दिँदैन, त्यसैले काम गर्ने जडान काम गर्ने नीतिजस्तो देखिन्छ।

परम्परागत रूपमा default भनिने तालिका 253 साधारण राउटिङ तालिका हो र सामान्यतया खाली हुन्छ। यसको नाम प्याकेट फाल्ने आदेश होइन, र यो तालिकाभित्रको पूर्वनिर्धारित गन्तव्य मार्गसँग एउटै कुरा होइन।

टर्मिनल कार्यहरूले खोजी अन्त्य गर्छन्

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

खाली तालिकाको खोजीको सट्टा VPN खोजीपछि टर्मिनल नियम आउन सक्छ। त्यही चिन्हसँग, तालिका 42 को नियमपछि राखिएको prohibit कार्यले त्यो तालिकाले केही नदिएपछि खोजी अन्त्य गर्छ र main तालिकालाई अर्को मौका दिनुको सट्टा प्रशासनिक अस्वीकृति फर्काउँछ। Unreachable र blackhole पनि टर्मिनल हुन्, पठाउनेका लागि फरक त्रुटि व्यवहारसहित।

throw प्रकारको मार्ग फरक छ: त्यो तालिकाभित्र यो केही पनि मिलेन जस्तो व्यवहार गर्छ, त्यसैले पछिल्ला नियमहरूले अझै आफ्नो पालो पाउँछन्। यसले throw लाई जानाजानी पछाडि फर्कन उपयोगी र अन्तिम ब्लकका रूपमा गलत बनाउँछ।

वास्तविक चिन्ह र इन्टरफेससँग प्रमाणित गर्नुहोस्

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

चित्रको सट्टा वास्तविक नियम र तालिका हेर्नुहोस्, त्यसपछि प्रवाहलाई यसको साँच्चैको स्रोत, चिन्ह र प्रवेश सन्दर्भसँग सोध्नुहोस्। गन्तव्यतिर लक्षित, स्रोत ठेगाना, इन्टरफेस र चिन्ह दिइएको पढ्ने-मात्र खोजीले प्याकेट नबाहिरिई कर्नेलले छान्ने मार्ग जानकारी दिन्छ। क्वेरीमा चिन्ह दिनुले firewall ले वास्तविक ट्राफिकमा चिन्ह लगाउँछ भन्ने प्रमाण दिँदैन; त्यो चिन्ह लगाउने नियमहरूको छुट्टै जाँच हो। क्वेरीबाट निष्कर्ष निकाल्नुअघि काउन्टर वा लगले मान पुष्टि गर्नुहोस्।

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

दुई असफलता अवस्था, एउटा होइन

एउटा असफलता अवस्था VPN मार्ग हराउनु र ट्राफिक uplink मा खस्नु हो। मार्ग स्थापित रहेको मृत सुरुङ अर्को अवस्था हो: प्याकेट खस्नुको सट्टा अप्रयोग्य बाटोमा निर्देशित रहन्छन्, र लक्षण देखिने सिधा जडान होइन, मौन हानि हो। दुवै जाँच्नुहोस्, र स्टार्टअप, पुनःजडान तथा सेवा-रोक व्यवहार पनि।

यस्तो नियमले त्यो अवस्थित रहेसम्म र प्याकेटले त्यसलाई छान्ने चिन्ह अझै बोकेसम्म मात्र मद्दत गर्छ। नियम मेट्ने शटडाउन स्क्रिप्ट, वा चिन्ह हटाउने बाटोले खुला व्यवहार पुनःस्थापित गर्छ। ती संक्रमणको अभ्यास गर्न लायक छ।

नीति IPv6 मा छुट्टै लागू गर्नुहोस्, र स्वीकृत अन्त्य बिन्दु अपवादहरू अन्तर्निहित नभई स्पष्ट राख्नुहोस्।