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

नाम की बैठक इंटरफ़ेस से अधिक टिकती है

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

नाम बैठक की कुंजी है, यह प्रमाण नहीं कि दूसरे छोर पर कौन है। साथी का प्रमाणीकरण VPN का ही काम रहता है।

नियम जोड़ने से पहले श्रृंखला पढ़ें

देखें कि नियम-समुच्चय में अभी क्या है और नया नियम कहाँ बैठेगा, क्योंकि क्रम ही परिणाम तय करता है।

nft list ruleset
nft -c -f /etc/nftables.conf

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

मार्ग, अनुवाद और प्रवाह के दूसरे मालिक हैं

इंटरफ़ेस की उपस्थिति कोई मार्ग नहीं बनाती और साथी का प्रमाणीकरण नहीं करती। वे VPN प्रबंधक के हैं, जबकि अनुवाद का तीसरा जीवनचक्र है।

conntrack -L -s 10.20.0.0/24 | head
ip route show dev vpn0

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

ठंडी शुरुआत, हानि और पुनर्प्राप्ति स्वीकारें

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

पुनः कनेक्शन में टिकने वाली नीति वही है जिसके मालिक नामित हैं और जिसके नियम टनल के बंद और चालू दोनों हाल में जाँचे गए हैं। सफलता बताने वाला हुक केवल यह सिद्ध करता है कि हुक चला।

संबंधित लेख