nftables: ड्रप ह्यान्डल अघि VPN अनुमति नियम राख्नुहोस्
nftables मा, insert र add ले नियमलाई ह्यान्डलको विपरीत पक्षमा राख्छन्। ड्रप खोज्नुहोस्, पक्ष छान्नुहोस्, त्यसपछि नियमसङ्ग्रह बदलिनु अघि फाइल जाँच्नुहोस्।
अनुमति नियम गलत ठाउँमा राख्नुभयो भने त्यो नियम नै नभएजस्तै व्यवहार गर्छ। nftables मा insert र add बीचको छनोटले नयाँ कथन सन्दर्भित नियमको कुन पक्षमा बस्ने भन्ने निर्धारण गर्छ, र ह्यान्डलले जीवित नियमसङ्ग्रहमा नियमको नाम दिन्छ, त्यसको पङ्क्ति नम्बरलाई होइन। ठाउँ गलत भए प्याकेट पहिले ड्रपमा पुग्छ।
तलको तुलनाले एउटा स्थिर सहकर्मी र एउटा बाह्य श्रोता आदानप्रदान प्रयोग गर्छ। यो जानाजानी साँघुरो छ; पूरै शृङ्खला बदल्नु फरक जोखिम प्रोफाइल भएको अर्को परिवर्तन हो।
दुई ठाउँ, दुई फरक नतिजा
insert सन्दर्भित नियम अघि नियम राख्छ। add त्यसलाई पछि राख्छ। सन्दर्भित नियम प्रवाहको अन्तिम ड्रप भए, नियमको पाठ एउटै भए पनि यी दुई आदेशले विपरीत नतिजा दिन्छन्।
ठाउँ छोड्नुको आफ्नै पूर्वनिर्धारित व्यवहार हुन्छ, जुन फोरमबाट आदेश केमा एङ्कर गरिएको छ भनी नपढी प्रतिलिपि नगर्नुको अर्को कारण हो। एङ्कर नै सम्पूर्ण निर्णय हो। आदेश टाइप गर्नु अघि इच्छित पक्ष लेख्नुहोस्। फाइलमा insert र add एक शब्दको फरकमा छन्।
स्थान कुनै निश्चित शृङ्खलाको नियमको सापेक्ष हुन्छ। त्यही कथन अर्को शृङ्खला वा अर्को hook प्राथमिकतामा सार्दा त्यसले कुन प्याकेट देख्छ भन्ने बदलिन्छ, नियमको वाक्यरचना सही देखिए पनि।
ह्यान्डलले नियम चिन्छ, पङ्क्ति नम्बर होइन
42 जस्तो ह्यान्डल वर्तमान नियमसङ्ग्रह स्थितिमा एक पहिचानकर्ता हो। त्यो बयालिसौँ नियम होइन, र होस्ट, पुनर्निर्माण वा आफ्नो कन्फिगरेसन पुनः लोड गर्ने प्रबन्धकबीच त्यो स्थिर हुँदैन।
एङ्कर छान्नु अघि शृङ्खला र वास्तविक अन्तिम ड्रप खोज्नुहोस्। त्यसपछि ड्रप देखाउने त्यही सूचीमा त्यो नियमको ह्यान्डल पुष्टि गर्नुहोस्, ताकि नम्बर र नियम सँगै पढियोस्। पुरानो सूचीबाट पढिएको ह्यान्डल पहिले नै अर्को नियमको हुन सक्छ। परिवर्तन लागू गर्ने सत्रमा त्यो फेरि पढ्नुहोस्।
iptables --version
nft -a list ruleset
iptables संस्करणले कुन backend प्रयोगमा छ भनी जनाउँछ। iptables-nft नियमसङ्ग्रह र स्वतन्त्र रूपमा व्यवस्थापित मूल तालिका सँगै रहन सक्छन्, त्यसैले एउटा frontendको सूची स्वतः पूर्ण फिल्टरिङ चित्र हुँदैन। शृङ्खला छान्नु अघि दुवै दृश्य जाँच्नुहोस्।
वास्तवमा ड्रप गर्ने शृङ्खला र नियम खोज्नुहोस्
input hook, शृङ्खलाको प्राथमिकता र यो श्रोता-प्रवाह अस्वीकार गर्ने नियम पढ्नुहोस्। inet तालिकाले दुवै ठेगाना परिवार बोक्न सक्छ, तर एउटा नियमले अझै IPv4 सँग मात्र मिल्न सक्छ।
एउटा स्वीकृत सहकर्मी लिनुहोस्, उदाहरणका रूपमा कागजात दायराबाट 198.51.100.25 प्रयोग गर्दै। समीक्षित मूल फाइलले ह्यान्डल 42 अघि बाह्य अनुमति राख्न सक्छ:
insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept
जाँचपछि परिवार, तालिका, शृङ्खला, ह्यान्डल, प्रवेश इन्टरफेस र सहकर्मी बदल्नुहोस्। उदाहरणले nft 1.0.9 का लागि कागजातीकृत ह्यान्डल-स्थान रूप प्रयोग गर्छ, र त्यो input फाइलमा पर्छ; आदेश अन्तरक्रियात्मक रूपमा लेखिँदा कोष्ठकको उद्धरण छुट्टै विषय हो।
कन्फिगरेसनको मालिक स्पष्ट राख्नुहोस्। आफ्ना नियम पुनर्निर्माण गर्ने प्रबन्धकले रनटाइम सम्पादन माथि लेख्न सक्छ, र पुरानो ह्यान्डल हार्डकोड गर्ने बुट स्क्रिप्ट या त असफल हुन्छ या गलत नियममा जोडिन्छ।
अनुमति सीमित छ, ड्रप अन्तिम हो
अनुमतिको निर्णयले आफ्नो वर्तमान मार्गमा मूल्याङ्कन अन्त्य गर्छ, तर पछि लागू हुने आधार शृङ्खलाले अझै प्याकेट ड्रप गर्न सक्छ। ड्रपको निर्णय अन्तिम हो। त्यसैले बढ्दो अनुमति काउन्टर प्रवाह सफल भएको प्रमाण होइन।
एउटा शृङ्खलालाई अलग्गै जाँच्नुको सट्टा सबै सम्बन्धित hook प्राथमिकता जाँच्नुहोस्। प्याकेट input फिल्टर पार गरेर पनि अर्को तालिकाको hook द्वारा फरक प्राथमिकतामा अस्वीकार हुन सक्छ। प्रवाह देख्न सक्ने हरेक आधार शृङ्खला सूचीबद्ध गर्नुहोस्।
त्यो नियमले बाह्य श्रोता आदानप्रदान मात्र समेट्छ। ट्रान्सपोर्ट-इन्क्याप्सुलेटेड ESP, मूल ESP, IPv6 सहकर्मी र सुरुङभित्रको डिक्रिप्ट भएको ट्राफिक सबैलाई आफ्नै नीति चाहिन्छ। यो पूर्ण साइट VPN फायरवाल होइन।
फाइल जाँच्नुहोस्, त्यसपछि जीवित नतिजा प्रमाणित गर्नुहोस्
लागू गर्नु अघि समीक्षित फाइलमा वाक्यरचना र कारोबार जाँच चलाउनुहोस्। जाँच मोडले nft परिवर्तन पार्स र तयार गर्न सक्छ कि भनी जनाउँछ; यसले त्यो लागू गर्दैन र अर्को hook ले प्याकेटलाई अनुमति दिन्छ भनी प्रमाणित गर्दैन। मालिकले लागू नगरेसम्म फाइल प्रस्ताव रहन्छ:
nft -c -f reviewed-vpn-rule.nft
मालिकको नियन्त्रित प्रक्रियाबाट लागू गर्नुहोस् र पुनःप्राप्ति पहुँच कायम राख्नुहोस्। नियम गलत भए, जुन ड्रप अघि जान खोज्नुभएको थियो त्यसले सुधार्न प्रयोग गर्ने बाटो पनि काट्न सक्छ।
परिवर्तनपछि नयाँ स्वीकृत सहकर्मी प्रयास अवलोकन गर्नुहोस् र स्वीकृत सहकर्मी बाहिरका स्रोत अझै अस्वीकार भइरहेको जाँच्नुहोस्। टिकाउ नियम त्यो प्रबन्धककहाँ सार्नुहोस् जसले नियमसङ्ग्रहको स्वामित्व राख्छ, किनकि रनटाइम ह्यान्डलले वर्तमान वस्तुहरू पत्ता लगाउँछन्, बुटबीच तिनीहरूलाई चिन्दैनन्।