फक्त NEW साठी असलेले फायरवॉल नियम प्रत्येक WAN मार्ग बंद करत नाहीत
NEW कनेक्शन नाकारल्याने स्थापित प्रवाह आणि उत्तरे अभंग राहतात। धोरण बंद म्हणण्यापूर्वी conntrack स्थिती, नियमांचा क्रम आणि अपवाद वाचा।
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
मग जुना प्रवाह नव्याच्या शेजारी तपासा। नवीन कनेक्शनचा प्रयत्न आणि आधीच सक्रिय द्वि-दिशात्मक हस्तांतरण या नियमाखाली वेगळे वागतात, आणि दोन्ही तपासल्यावरच प्रत्यक्षात कोणते धोरण आहे ते दिसते।