खाली 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 तालिका तक पहुँचता है। उस क्रम में कुछ भी यह नहीं बताता कि अंतिम उत्तर किस नियम ने दिया, इसलिए काम करता कनेक्शन काम करती नीति जैसा दिखता है।

253 तालिका, जिसे परंपरागत रूप से default कहा जाता है, एक साधारण राउटिंग तालिका है और सामान्यतः खाली होती है। इसका नाम पैकेट गिराने का निर्देश नहीं है, और यह तालिका के भीतर डिफ़ॉल्ट गंतव्य मार्ग जैसा नहीं है।

टर्मिनल क्रियाएँ खोज समाप्त करती हैं

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

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

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

दो विफलता अवस्थाएँ, एक नहीं

एक विफलता अवस्था यह है कि VPN मार्ग गायब हो जाए और ट्रैफ़िक uplink पर गिर जाए। जिस मृत टनल का मार्ग स्थापित रहता है वह दूसरी है: पैकेट गिरने के बजाय अनुपयोगी पथ में निर्देशित रहते हैं, और लक्षण दिखाई देने वाला सीधा कनेक्शन नहीं बल्कि मौन हानि है। दोनों जाँचें, और स्टार्टअप, पुनःकनेक्शन तथा सेवा-रोक व्यवहार भी।

ऐसा नियम केवल तब तक मदद करता है जब तक वह मौजूद है और पैकेट अभी भी उसे चुनने वाला चिह्न लिए हैं। जो शटडाउन स्क्रिप्ट नियम हटा देती है, या जो पथ चिह्न हटा देता है, वह खुला व्यवहार लौटा देता है। उन संक्रमणों का अभ्यास करना उचित है।

नीति को IPv6 पर अलग से लागू करें, और स्वीकृत एंडपॉइंट अपवादों को अंतर्निहित नहीं बल्कि स्पष्ट रखें।