नया UFW नियम, पुराना कनेक्शन: स्थापित स्थिति जीतती है

डिनाई नियम जोड़ना और एक खुला डाउनलोड चलते रहना देखना UFW की गड़बड़ी नहीं है। आपने जो नियम जोड़ा है वह उन नियमों के बाद आता है जो पहले ही इस प्रवाह को स्वीकार कर चुके हैं, और पहले स्थापित हुआ कनेक्शन उनसे मेल खाता रहता है। इसे ठीक करने का अर्थ है सही जगह पर डालना और यह समझना कि पहले के नियम क्या वादा करते हैं। उस बदलाव का संकीर्ण रूप आगे है।

नियम का अस्तित्व नहीं, क्रम निर्णय करता है

UFW एक फ़्रंट एंड है जो netfilter नियम चरणों में लिखता है: उपयोगकर्ता नियमों से पहले चलने वाला ढाँचा खंड, फिर स्वयं उपयोगकर्ता नियम, फिर उनके बाद चलने वाला खंड। मानक पहले वाले नियम स्थापित और संबंधित कनेक्शनों का ट्रैफ़िक स्वीकार करते हैं, और वे नियम आपके द्वारा सामान्य allow या deny से जोड़ी गई किसी भी चीज़ से पहले मूल्यांकित होते हैं। UFW कमांड संदर्भ डालने के सिंटैक्स और उस क्रमांकित स्थिति दृश्य का दस्तावेज़ीकरण करता है जिस पर यह बदलाव निर्भर है।

यही क्रम आश्चर्य की व्याख्या करता है। आपका नया नियम वास्तविक है और सही तालिका में है, पर यह पैकेट के सामने आने वाला पहला निर्णय नहीं है। जो कनेक्शन पहले से स्थापित के रूप में ट्रैक हो रहा है वह कभी वहाँ नहीं पहुँचता।

इस काम के लिए route नियम इस्तेमाल करें, क्योंकि पैकेट गेटवे के भीतर से फ़ॉरवर्ड होता है, गेटवे की अपनी सेवाओं को संबोधित नहीं होता। इनपुट नियम ग़लत ट्रैफ़िक छानता और कुछ न करता दिखाई देता।

व्यापक अनुमति के ऊपर डालें

लागू करने से पहले डालने का पूर्वावलोकन करें और पुष्टि करें कि नियम सूची में कहीं और पहले से नहीं है। समान नीति की नकल करना बाद में हटाने को अस्पष्ट बना देता है, और ग़लत प्रति हटाने वाले को हफ़्तों तक पता नहीं चलेगा।

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

यदि पूर्वावलोकन में अपेक्षित स्थान पर ठीक एक ही नियम दिखे, तो वही कमांड dry-run फ़्लैग के बिना लागू करें। स्थान 1 इसे व्यापक उपयोगकर्ता अनुमतियों के ऊपर रखता है, पहले चर्चा किए गए ढाँचा नियमों के ऊपर नहीं। पुष्टि करें कि इंटरफ़ेस का नाम इस गेटवे पर टनल डिवाइस से मेल खाता है, क्योंकि ऐसे इंटरफ़ेस से बँधा नियम जो अब नहीं है, सूची में बैठकर सही दिखेगा जबकि किसी से मेल नहीं खाएगा। लागू करने से पहले डिवाइस का संदर्भ बदलें, परीक्षण विफल होने के बाद नहीं।

उस नियम में कोई गंतव्य पोर्ट नहीं है, इसलिए वह उस पते पर केवल HTTPS नहीं बल्कि हर TCP पोर्ट को अस्वीकार करता है। यदि इरादा एक ही सेवा है तो पोर्ट का नाम दें; नीति से व्यापक नियम पहले पाठक की प्रतीक्षा करती भावी घटना है।

स्रोत को एक ही पते तक सीमित करें केवल तब जब वह पता इच्छित पहचान से बँधा हो। गतिशील आवंटन वाला VPN पूल कल वही पता किसी दूसरे क्लाइंट को दे सकता है, और डिनाई व्यक्ति के बजाय पते का पीछा करेगी।

स्थापित प्रवाह नए नियम से बचे रहते हैं

कनेक्शन ट्रैकिंग ही मौजूदा सत्र के जारी रहने का कारण है। किसी प्रवाह के स्थापित के रूप में दर्ज हो जाने पर पहले वाले नियम आपकी डिनाई देखे जाने से पहले ही उसके पैकेट स्वीकार कर लेते हैं, और स्थानांतरण ऐसे पूरा होता है जैसे कुछ बदला ही न हो। इसलिए खुले कनेक्शन का पुनः उपयोग करने वाले ब्राउज़र से परीक्षण नई नीति के बारे में कुछ नहीं बताता। डिनाई तैनाती के कुछ मिनट बाद बेकार लग सकती है और अगले जुड़ने वाले उपयोगकर्ता के लिए पूरी तरह प्रभावी हो सकती है।

यदि आवश्यकता में चालू ट्रैफ़िक काटना शामिल है, तो यह उपयोगकर्ता-नियम बदलाव वह नहीं दे सकता। ट्रैक की गई स्थिति को रद्द करना अपने प्रभाव-दायरे वाली अलग कार्रवाई है, और वह नियम जोड़ने वाले की नहीं बल्कि फ़ायरवॉल मालिक की है। एक सत्र ग़ायब करने के लिए गेटवे पर हर कनेक्शन खाली करना ऐसा सुधार है जो दूसरी घटना पैदा करता है।

सीमाएँ भी याद रखें। यह नियम ICMP, UDP या IPv6 के बारे में कुछ नहीं कहता, इसलिए सफल ping डिनाई विफल होने का प्रमाण नहीं है। एक IPv4 पता भी वेबसाइट नहीं है: एक नाम कई पतों में हल हो सकता है, और केवल वही ढका है जिसका आपने नाम लिया।

नए प्रवाह से परीक्षण करें

क्रमांकित उपयोगकर्ता नियम और प्रभावी कच्चा दृश्य पढ़ें, फिर चुने गए क्लाइंट से नया कनेक्शन खोलें:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

कच्चा दृश्य महत्वपूर्ण है क्योंकि status हाथ से लिखे ढाँचा नियम छोड़ देता है, इसलिए यह क्रम को कर्नेल के लागू करने से अलग दिखा सकता है। यह निष्कर्ष निकालने से पहले कि कोई नियम ग़लत जगह है, दोनों की तुलना करें।

फिर वे दो नियंत्रण जाँचें जो साबित करते हैं कि नियम संकीर्ण है, व्यापक नहीं: उसी क्लाइंट से अनुमत गंतव्य अब भी काम करता है, और दूसरा क्लाइंट अब भी अस्वीकृत गंतव्य तक पहुँचता है यदि उसकी नीति अनुमति देती है। जो डिनाई दोनों परीक्षण तोड़ दे वह नीति परिवर्तन है, लक्षित कदम नहीं।

परीक्षण समाप्त होने पर केवल वही नियम हटाएँ जो आपने जोड़ा, उसे ठीक-ठीक दोहराकर। यदि नीति स्थायी है, तो क्लाइंट पहचान, गंतव्य का मालिक और समीक्षा तिथि के साथ उसे फ़ायरवॉल मालिक को सौंपें, ताकि फिर से आवंटित टनल पता पुरानी डिनाई पीछे न छोड़े।