हर 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 उन पैकेटों के लिए मूल्यांकन समाप्त कर देता है जिन्हें वह मिलाता है, इसलिए बाद में जोड़ा गया drop उनके लिए कभी नहीं चलता। यही क्रम-नियम सही दिखने वाले नियम के बेअसर होने का पूरा कारण है।
नियम को अंत में जोड़ने के बजाय 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 से मेल खाता रहता है। इसीलिए नया drop कभी कभी नए कनेक्शन के लिए काम करता दिखता है और जिसका परीक्षण हो रहा है उसके लिए कुछ नहीं करता।
श्रृंखला के शीर्ष पर स्टेट मिलान पढ़ें। अगर वह आपके नियम से पहले 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 पैकेटों के बारे में कुछ नहीं कहती। एप्लिकेशन-स्तर का प्रतिबंध प्रीफ़िक्स मिलान का नहीं, सेवा या प्रमाणित प्रॉक्सी का है। इन ज़रूरतों को अलग रखना ही एक संकीर्ण नियम से चार काम कराने से रोकता है।
यह नियम जो अनुबंध देता है वह सटीक है: स्वीकृत पूल से एक गंतव्य प्रीफ़िक्स तक ट्रैफ़िक अस्वीकार किया जाता है, जबकि असंबंधित गेटवे ट्रैफ़िक अपनी मौजूदा नीति रखता है। वह वाक्य नियम के पास लिखें, और अगला व्यक्ति जान जाएगा कि यह किस लिए था।