केवल NEW वाले फ़ायरवॉल नियम हर WAN मार्ग नहीं बंद करते

WAN पर नए आउटबाउंड कनेक्शन अस्वीकार करना विफलता पर बंद होने वाली नीति जैसा दिखता है, पर यह दिखने से कहीं संकरा वादा है। पहले से मौजूद फ़्लो के पैकेट इससे मेल नहीं खाते, और बहुत से उत्तर भी नहीं। यह अंतराल चूक जाना आसान है, क्योंकि नियम ऐसे पढ़ा जाता है मानो वह इंटरफ़ेस को ढकता है, उस पर की एक कनेक्शन स्थिति को नहीं। और स्थिति-मिलान को फ़ैसला मानकर पढ़ना ही झूठा बंद होने का भाव पैदा करता है।

स्थिति एक मिलान-शर्त है, फ़ैसला नहीं

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

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

नियम को उसके परिवेश में पढ़ें

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

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

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

निषेध को स्थिति से स्वतंत्र रूप में व्यक्त करें

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

drop के बजाय reject चुनना यह बदलता है कि मेल खाता ट्रैफ़िक कैसे विफल होता है, और यह उन पैकेटों का समुच्चय नहीं बढ़ाता जिन्हें नियम चुनता है। अस्वीकृत कनेक्शन और शांत समयसमाप्ति अलग लक्षण हैं जो एक ही चयन की ओर संकेत करते हैं।

ऐसी नीति जो WAN पर दूर से शुरू हुई पहुँच के उत्तरों को जानबूझकर अनुमति देती है, उचित है। बस उसे पूर्ण सुरंग-मात्र पृथक्करण के रूप में प्रस्तुत करने के बजाय वैसे ही वर्णित करना चाहिए।

जाँचें कि समूह में वास्तव में कौन है

उदाहरण एक इंटरफ़ेस से एक प्रीफ़िक्स के फ़ॉरवर्ड किए गए IPv4 ट्रैफ़िक को कवर करता है। यह IPv6, दूसरे अपलिंक, या राउटर स्वयं जो ट्रैफ़िक बनाता है, उसके बारे में कुछ नहीं कहता। DNS रिज़ॉल्वर की तरह काम करने वाला राउटर अपनी अपस्ट्रीम क्वेरी भेजता है, और वे forward श्रृंखला से बिल्कुल नहीं गुज़रतीं।

पुष्टि करें कि संरक्षित क्लाइंटों के पास अब भी चुने गए प्रीफ़िक्स के भीतर पते हैं, क्योंकि उससे बाहर जाने वाला उपकरण नीति से नहीं, संयोग से सीधा है। अपवादों की रचना की समीक्षा किए बिना अवरोध को पूरे LAN तक बढ़ाना भी आपका अपना प्रशासनिक मार्ग हटा देता है।

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

फिर एक पुराने फ़्लो को नए के साथ परखें। नया कनेक्शन प्रयास और पहले से सक्रिय दो-तरफ़ा स्थानांतरण इस नियम के अंतर्गत अलग व्यवहार करते हैं, और केवल दोनों की जाँच बताती है कि वास्तव में कौन सी नीति है।