फ़ायरवॉल नियम में बदलाव काम नहीं कर रहा: नियमों का क्रम और कनेक्शन की स्थिति

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

नियमों का क्रम और कनेक्शन की स्थिति अलग-अलग खराबियाँ हैं

क्रमबद्ध श्रृंखलाएँ ऊपर से नीचे मूल्यांकित होती हैं, और अंतिम निर्णय तक पहुँचने वाला पहला नियम उस श्रृंखला से गुज़रना समाप्त कर देता है। किसी सावधानी से लिखे गए लॉकडाउन नियम के ऊपर व्यापक अनुमति रखें, और वह लॉकडाउन नियम केवल दस्तावेज़ बन जाता है: वह नियम-समूह में है, उसका काउंटर शून्य है, और कोई पैकेट कभी उस तक नहीं पहुँचेगा। वही पाठ किसी दूसरी श्रृंखला पर लागू करने से भी कुछ सिद्ध नहीं होता। nftables में आधार श्रृंखलाएँ प्राथमिकताओं पर हुक से जुड़ती हैं, इसलिए एक श्रृंखला में दी गई अनुमति किसी दूसरे हुक या प्राथमिकता की दूसरी श्रृंखला को वही पैकेट देखने से नहीं रोकती।

कनेक्शन ट्रैकिंग दूसरा लक्षण पैदा करती है, और बाहर से वह बिल्कुल वैसा ही दिखता है। जैसे ही कोई प्रवाह स्टेट टेबल में आता है, श्रृंखला के ऊपर के पास की established-or-related अनुमति आपके नए नियम पर विचार होने से पहले ही लौट जाती है। NAT मैपिंग का भी यही गुण है: अनुवाद तब तय हुआ था जब प्रवाह शुरू हुआ, इसलिए संपादित postrouting नियम पहले से चल रहे सत्र को फिर से नहीं लिखता। यही कारण है कि बदलाव 09:00 बजे नए कनेक्शन के लिए काम करता दिखता है और 08:55 बजे किसी के खोले सत्र के लिए कुछ नहीं करता दिखता है।

क्लाउड सुरक्षा समूह तीसरा मॉडल जोड़ते हैं जो iptables पर सीखने वालों को पकड़ता है। उनके इनबाउंड नियम अनुमतियों की सूची हैं जिन्हें पहले-मेल के चलने की बजाय समुच्चय के रूप में मूल्यांकित किया जाता है, वे स्टेटफुल हैं, और किसी अनुमति नियम को हटाने से पहले से ट्रैक हो रहे प्रवाह समाप्त नहीं होते। जिस प्लेटफ़ॉर्म में पहले-मेल की अर्थ-व्यवस्था नहीं है वहाँ उसे मान लेना आत्मविश्वासी पर ग़लत निष्कर्षों तक ले जाता है।

सक्रिय नियम-समूह पढ़ें, वह फ़ाइल नहीं जिसे आपने संपादित किया

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

nft list ruleset
iptables-save

फिर पूछें कि क्या आपके नियम तक पहुँचा ही जाता है। पैकेट काउंटर सीधे इसका उत्तर देते हैं, और मंशा पर किसी भी तर्क से बेहतर उत्तर देते हैं:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

वास्तविक परीक्षण प्रयास के बाद शून्य पैकेट वाला लॉकडाउन नियम नीति की समस्या नहीं, स्थान की समस्या है। उसे हटाना एक पंक्ति का बदलाव है, और सिंटैक्स ठीक वही है जिसने मूल बग पैदा किया। iptables के साथ -I शुरू में जोड़ता है और -A अंत में जोड़ता है; nftables के साथ insert नियम को श्रृंखला के आरंभ में रखता है जबकि add अंत में जोड़ता है। जब किसी नियम को जीतना ही हो, तो संयोग से लोड हुए क्रम पर भरोसा करने के बजाय स्पष्ट कहें।

साबित करें कि प्रवाह ट्रैक हो रहा है या नहीं

नियम को दोष देने से पहले जाँचें कि ट्रैफ़िक क्या वाकई ट्रैक किया गया कनेक्शन है। पूरा स्टेट टेबल उँडेलने के बजाय उस विशेष प्रवाह के बारे में पूछें:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

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

उत्पादन गेटवे पर पूरा टेबल फ़्लश करने के शॉर्टकट का विरोध करें। conntrack -F उपलब्ध है, और यह मशीन पर हर ट्रैक किए गए प्रवाह को भी नष्ट करता है, जिसमें वह प्रबंधन सत्र भी शामिल है जिससे आप काम कर रहे हैं और वह टनल जो आपका शेल ढोती है। व्यक्तिगत प्रविष्टियाँ तब मिटाई जा सकती हैं जब सचमुच ज़रूरत हो, पर नए स्रोत पोर्ट से नया प्रवाह आमतौर पर अधिक साफ़ प्रयोग होता है।

कुछ रास्ते ट्रैक नहीं होते, और वे उलटा व्यवहार करते हैं। raw टेबल में notrack के रूप में चिह्नित ट्रैफ़िक, सामान्य हुक से बचने वाली कुछ टनलें, और वह असममित रूटिंग जो प्रवाह को दो गेटवे के बीच बाँटती है—ये सब एक-एक करके मूल्यांकित होने वाले पैकेट पैदा करते हैं, या ऐसी स्थिति जो दोनों सिरों पर कभी बनती ही नहीं। यदि हर पैकेट पर काउंटर हिलते हैं, तो क्रम पर संदेह करने से पहले उस तरह के रास्ते पर संदेह करें।

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

ऐसे नियम का परीक्षण करने से पहले जो दूरस्थ पहुँच काट सकता है, रिकवरी का रास्ता बनाएँ: प्रदाता का कंसोल, सीरियल कंसोल, आउट-ऑफ़-बैंड प्रबंधन पता, या दूसरा इंटरफ़ेस जिसे नियम मैच न कर सके। रोलबैक टाइमर एक उचित साथी है, क्योंकि परीक्षण के बीच आपका सत्र मर जाने पर भी वह पिछला नियम-समूह बहाल कर देगा।

फिर ऐसी अदला-बदली से परीक्षण करें जिसे स्थिति पहले ही ढक न सकती हो। क्लाइंट को डिस्कनेक्ट करके फिर जोड़ें ताकि नया पाँचका बने, और ऐसा होते समय दोनों सिरे देखें:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

परीक्षण दोनों दिशाओं में चलाएँ। नए इनबाउंड हैंडशेक को रोकने वाला नियम उत्तर के रास्ते को फिर भी अनुमति दे सकता है, या उलटा, और एकतरफ़ा परिणाम ही लॉकडाउन के आधा काम करने का सामान्य कारण है। परीक्षण के बाद स्थिर स्थिति की पुष्टि के लिए एक बार फिर जुड़ें, और जाँचें कि वैध प्रबंधन पहुँच बची रही; एक पोर्ट के लिए लिखा नियम अक्सर इरादे से अधिक चौड़ी श्रेणी से मेल खा जाता है।

नियम के साथ उद्देश्य और स्थान दर्ज करें

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

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