प्रत्येक VPN ग्राहक पूलका लागि एउटा गन्तव्य दायरा ब्लक गर्नुहोस्
एउटा nftables नियमले गेटवेको आफ्नै ट्राफिकलाई नछुईकन स्वीकृत VPN पूलका लागि गन्तव्य प्रिफिक्स अस्वीकार गर्न सक्छ। हुक र स्थान मिलाउनुहोस्।
एउटा नियमले स्वीकृत VPN पूललाई गन्तव्य दायराबाट टाढा राख्न सक्छ, गेटवेले गर्ने अरू कुनै काममा बाधा नपुर्याई। नियम आफैं छोटो छ; यो काम गर्छ कि गर्दैन भन्ने निर्धारण गर्ने भागहरू यो बस्ने हुक र शृंखलामा यसको स्थान हुन्। यी दुईमा गल्ती गरे सही देखिने तर असंगत व्यवहार गर्ने फायरवाल पाइन्छ। नियमले प्याकेट देख्दा प्याकेट के गर्दैछ भन्नेबाट सुरु गर्नुहोस्।
नियमले वास्तवमा के मिलाउँछ
नियमले एकैचोटि तीनवटा कुरा मिलाउँछ: इनपुट इन्टरफेस, स्रोत प्रिफिक्स र गन्तव्य प्रिफिक्स। ड्रप लागू हुनुअघि तीनै सत्य हुनुपर्छ, र यसैले यसलाई साँघुरो राख्छ। यसलाई तीन अलग नीतिका रूपमा पढ्नुभन्दा एउटा अभिव्यक्तिका रूपमा पढ्न सजिलो हुन्छ।
इन्टरफेस मिलानले नै फर्वार्ड गरिएको ग्राहक ट्राफिकलाई गेटवेका आफ्नै जडानहरूबाट छुट्याउँछ। त्यो नभए, केवल स्रोत पूलको नाम लिने नियमले गेटवे आफैंले त्यो ठेगानाबाट बनाउने प्याकेटलाई पनि प्रभाव पार्थ्यो, यदि कहिल्यै त्यस्तो हुन्छ भने। स्रोत प्रिफिक्सले नीतिलाई स्वीकृत ग्राहकमा सीमित गर्छ, र गन्तव्य प्रिफिक्सले त्यसलाई एउटा दायरामा। नियमलाई सूची होइन, प्रतिच्छेदनका रूपमा पढ्नुहोस्।
केही सम्पादन गर्नुअघि तीन मान लेख्नुहोस्: टनेल इन्टरफेसको नाम, सर्भरले बाँड्ने पूल, र तपाईं अस्वीकार गर्न चाहनुभएको प्रिफिक्स। यीमध्ये कुनैमा टाइपो भए सफा पार्स हुने तर केही पनि सुरक्षित नगर्ने नियम बन्छ। ती तीन मान नियमको छेउमा रहेको परिवर्तन अभिलेखमा राख्नुहोस्।
हुकले नियम कसलाई लागू हुन्छ भन्ने निर्धारण गर्छ
netfilter शृंखला एउटा हुकमा जोडिन्छ, र कुन प्याकेट शृंखलाले देख्छ भन्ने हुकले नै तय गर्छ। forward हुकले गेटवेबाट रुट हुने ट्राफिक देख्छ, र ग्राहकबाट गन्तव्यतर्फको ट्राफिक ठ्याक्कै त्यही हो। शृंखलामा बाँकी सबै अर्कै श्रोतातर्फ लक्षित छ।
input हुकले गेटवे आफैंलाई सम्बोधित ट्राफिक देख्छ, त्यसैले त्यहाँ राखिएको नियमले ट्रान्जिट होइन, त्यसका आफ्नै सेवाहरूमा पहुँच नियन्त्रण गर्छ। output हुकले गेटवे आफैंले उत्पन्न गर्ने ट्राफिक देख्छ, जो ग्राहक पूल नीतिलाई चाहिने कुराको उल्टो हो। शृंखलाका नामहरू नियमसंग्रह लेख्नेले छानेका स्वेच्छाचारी लेबल हुन्, त्यसैले नामबाट हुक अनुमान नगर्नुहोस्। शृंखला कहाँ जोडिएको छ जाँच्नुहोस्, त्यसपछि यसले के मिलाउन सक्छ अनुमान गर्नुहोस्।
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
जडान पढ्नु एक लाइनको जाँच हो, जसले नियमलाई प्याकेट कहिल्यै नदेख्ने शृंखलामा पर्नबाट रोक्छ।
फराकिलो accept अघि नियम राख्नुहोस्
नियमहरू क्रममा मूल्याङ्कन गरिन्छ, र पहिलो फैसला जित्छ। शृंखलामा अगाडि रहेको फराकिलो accept ले आफूसँग मिल्ने प्याकेटका लागि मूल्याङ्कन अन्त्य गर्छ, त्यसैले पछि थपिएको ड्रप तिनीहरूका लागि कहिल्यै चल्दैन। यही क्रम-नियम सही देखिने नियमको कुनै प्रभाव नहुनुको पूरा कारण हो।
नियमलाई अन्त्यमा थप्नुको सट्टा accept अघि घुसाउनुहोस्। शृंखलामा टनेल इन्टरफेसका लागि पहिलेदेखि सामान्य accept छ भने, नयाँ नियम त्यसअघि हुनुपर्छ, नत्र त्यो केवल सजावट हो। तपाईंले सम्पादन गरेको फाइल होइन, परिणामस्वरूप बनेको क्रम जाँच्नुहोस्, किनकि धेरै फाइलबाट जोडिएको नियमसंग्रह कुनै एकसँग पनि नमिल्न सक्छ। त्यसपछि पूलबाट आएको परीक्षण प्याकेटले पुष्टि गर्नुहोस्।
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confतेस्रो आदेशले फाइल लागू नगरी पार्स गर्छ, जसले सिन्ट्याक्स त्रुटि अवरोध बन्नुअघि समात्छ। रोलब्याक योजनासहित लागू गर्नुहोस्, किनकि forward शृंखलामा गलत नियमले तपाईं काम गरिरहनुभएको टनेल काट्न सक्छ।
अवस्थित प्रवाहहरूले तपाईंको नयाँ नियमको वास्ता गर्दैनन्
नियम अस्तित्वमा आउनुअघि बनेको conntrack प्रविष्टि अघिल्लो acceptसँग मिल्दै रहन्छ। यसैले नयाँ ड्रप कहिलेकाहीँ नयाँ जडानका लागि काम गरेको देखिन्छ र परीक्षण भइरहेको जडानका लागि केही गर्दैन।
शृंखलाको शीर्षमा रहेको स्थिति मिलान पढ्नुहोस्। यदि यसले तपाईंको नियमअघि established र related ट्राफिक स्वीकार गर्छ भने, पहिलेदेखि चलिरहेको हरेक प्रवाह बन्द नहुँदासम्म बगिरहन्छ। आपत्कालीन नियमका लागि सामान्यतया यही व्यवहार चाहिन्छ, र तत्काल कटौती अपेक्षा गर्दा यो भ्रमित पार्छ। तैनाथ गर्नुअघि कुन प्रभाव चाहिन्छ निर्णय गर्नुहोस्। खुला जडान पुनः प्रयोग गर्ने परीक्षणले तपाईंलाई गलत कथा सुनाउँछ।
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'पहिलो आदेशले प्रवाह छ कि छैन देखाउँछ, र दोस्रोले अघिल्लो स्थिति नियमले त्यसलाई स्वीकार गरिरहेको छ कि छैन देखाउँछ। दुवै पढ्ने-मात्र हुन् र घटनाको समयमा चलाउन सुरक्षित छन्।
यो नियम के होइन
यो नियम डोमेन कालोसूची, IPv6 नीति वा कुनै एउटै अनुप्रयोग खातामाथिको प्रतिबन्ध होइन।
तीमध्ये प्रत्येकलाई आफ्नै कार्यविधि चाहिन्छ। डोमेन ब्लकले नामहरू समाधान गर्नुपर्छ, जुन प्याकेट फिल्टरले गर्दैन। IPv6 ट्राफिकलाई आफ्नै मिलान चाहिन्छ, किनकि ip अभिव्यक्तिले ip6 प्याकेटबारे केही भन्दैन। अनुप्रयोग-स्तरको प्रतिबन्ध प्रिफिक्स मिलानको होइन, सेवा वा प्रमाणित प्रोक्सीको हो। यी आवश्यकताहरू अलग राख्नु नै एउटा साँघुरो नियमलाई चार काम गर्न भनिनबाट रोक्छ।
यो नियमले दिने सम्झौता ठ्याक्कै छ: स्वीकृत पूलबाट एउटा गन्तव्य प्रिफिक्सतर्फको ट्राफिक अस्वीकार गरिन्छ, जबकि असम्बन्धित गेटवे ट्राफिकले आफ्नो वर्तमान नीति कायम राख्छ। त्यो वाक्य नियमको छेउमा लेख्नुहोस्, र अर्को व्यक्तिले यो केका लागि थियो थाहा पाउनेछ।