nftables मार्क और VPN राउटिंग: कौन-सा नियम वास्तव में जीतता है

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

जाँच 1: वह नियम पढ़ें जिससे कर्नेल मेल खाता है

फ़ायरवॉल से नहीं, नीति-नियम से शुरू करें। कर्नेल नियमों को प्राथमिकता क्रम में देखता है और पहला मेल तालिका तय करता है। fwmark मान और मास्क स्वयं नियम से पढ़ें, फिर पुष्टि करें कि आपके लगाए मार्क वाला पैकेट वास्तव में उससे मेल खाता है। पूर्ण 32-बिट मान की अपेक्षा करने वाला नियम केवल एक बिट वाले पैकेट से मेल नहीं खाएगा।

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

दो कमांड इसे तय करते हैं: नियमों की सूची, और उस तालिका में गंतव्य के लिए रूट खोज।

जाँच 2: पैकेट मार्क या कनेक्शन मार्क

nftables पैकेट पर मार्क और कनेक्शन-ट्रैकिंग प्रविष्टि पर मार्क लगा सकता है, और ये अलग ऑब्जेक्ट हैं। पैकेट मार्क पैकेट के प्रसंस्करण-चक्र के दौरान रहता है, जबकि कनेक्शन मार्क प्रवाह के लिए बना रहता है और उसे जानबूझकर कॉपी करना पड़ता है। एक लगाकर दूसरे की अपेक्षा करना आम आधा-उपाय है।

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

तय करें कि राउटिंग संकेत किस ऑब्जेक्ट का है, फिर उसे उस बिंदु पर लगाएँ जहाँ राउटिंग निर्णय लिया जाता है।

जाँच 3: यह मार्क और कौन लिखता है

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

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

एक और जोड़ने से पहले लेखकों की सूची बनाएँ।

जाँच 4: मास्क तय करता है कि आप क्या रखते हैं

मार्क 32-बिट फ़ील्ड है, और मास्क यह बताते हैं कि कई मालिक इसे कैसे साझा करते हैं। मास्क के साथ मान लगाने से वे बिट सुरक्षित रहते हैं जो आपके नहीं हैं; पूरा फ़ील्ड लगाने से बाकी सब के बिट नष्ट हो जाते हैं। फ़ील्ड को छूने वाले हर नियम में मास्क पढ़ें, उनमें भी जो आपने नहीं लिखे।

नियम-समुच्चय के पास बिट आवंटन का दस्तावेज़ीकरण करें।

वरना अगला व्यक्ति ऐसा मान फिर इस्तेमाल करेगा जिसका पहले से मालिक है, और यहाँ का संघर्ष राउटिंग बग जैसा दिखता है जबकि वह पता-निर्धारण का बग है। पैकेट मेटाडेटा पर nftables का दस्तावेज़ स्वयं मार्क संक्रियाओं का वर्णन करता है।

जाँच 5: खोज से नहीं, वास्तविक प्रवाह से सत्यापित करें

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

जीवंत सत्र के दौरान रीफ़्रेश थोपने के लिए कनेक्शन स्थिति फ़्लश करने से बचें, क्योंकि नए और मौजूदा प्रवाह वैध रूप से अलग पथ ले सकते हैं।

मार्क, मास्क और तालिका एक ही जगह दर्ज करें, फिर अगला संपादन समीक्षा-योग्य हो जाता है।