प्रत्येक 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 पॅकेटबद्दल काहीही सांगत नाही. अनुप्रयोग-स्तरावरील निर्बंध उपसर्ग जुळणीचा नाही, सेवेचा किंवा प्रमाणित प्रॉक्सीचा असतो. ह्या गरजा वेगळ्या ठेवणे हेच एका अरुंद नियमाकडून चार कामे मागण्यापासून रोखते.
हा नियम देतो तो करार नेमका आहे: मंजूर पूलाकडून एका गंतव्य उपसर्गाकडे जाणारी रहदारी नाकारली जाते, तर असंबंधित गेटवे रहदारी आपले सध्याचे धोरण राखते. ते वाक्य नियमाच्या शेजारी लिहा, आणि पुढच्या व्यक्तीला तो कशासाठी होता ते कळेल.