टनेलहरू क्षणिक हुन्छन्; नीति त्यस्तो हुनु हुँदैन। 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 प्रविष्टि मेट्नु हुँदैन, किनकि अरू सेवाहरूले तिनलाई साझा गर्छन्। स्टार्ट हुक शून्यसहित निस्कियो भन्ने मात्र होइन, कुन घटकले इन्टरफेस, मार्ग र नीति बदल्यो त्यो पनि लेख्नुहोस्।

पुनः जडानमा टिक्ने नीति त्यही हो जसका मालिकहरू नामित छन् र जसका नियमहरू टनेल बन्द र चालु दुवै अवस्थामा जाँचिएका छन्। सफलताको रिपोर्ट दिने हुकले हुक चल्यो भन्ने मात्र प्रमाणित गर्छ।

सम्बन्धित लेखहरू