फायरवॉल नियम बदल काम करत नाही: नियमांचा क्रम आणि कनेक्शनची स्थिती

तुम्ही नियम संपादित केला, नियमसंच पुन्हा लोड केला, आणि तरीही बोगदा पूर्वीप्रमाणेच वागतो. या निकालाची दोन सामान्य कारणे आहेत, आणि त्यांना वेगळ्या चाचण्या लागतात. एकतर नवीन नियम आधीच पॅकेट स्वीकारलेल्या पूर्वीच्या नियमानंतर आहे, किंवा तुम्ही पाहत असलेली देवघेव बदल कधीही पुन्हा मूल्यांकन न करणारे ट्रॅक केलेले कनेक्शन आहे. फाइलमधील नियम हेतू व्यक्त करतो; पॅकेटचे नशीब ठरवते तो सक्रिय मार्ग जो त्याला भेटतो. खालील तपासण्या क्रमाने करा आणि तसे करताना परतीचा मार्ग खुला ठेवा.

नियमांचा क्रम आणि कनेक्शनची स्थिती वेगवेगळ्या बिघाड्या आहेत

क्रमबद्ध साखळ्या वरून खाली मूल्यांकन केल्या जातात, आणि अंतिम निर्णयापर्यंत पोहोचणारा पहिला नियम त्या साखळीतील प्रवास संपवतो. काळजीपूर्वक लिहिलेल्या लॉकडाउन नियमाच्या वर रुंद परवानगी ठेवा, आणि लॉकडाउन नियम केवळ दस्तऐवज बनतो: तो नियमसंचात आहे, त्याचा काउंटर शून्य आहे, आणि कोणतेही पॅकेट कधीही त्याला पोहोचणार नाही. तोच मजकूर दुसऱ्या साखळीवर लागू केल्यानेही काही सिद्ध होत नाही. 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

चाचणी दोन्ही दिशांनी करा. नवीन इनबाउंड हस्तांदोलन अडवणारा नियम उत्तरेचा मार्ग अजूनही परवानगी देऊ शकतो, किंवा उलटही, आणि एकदिशाने मिळणारा निकाल हेच लॉकडाउन अर्धवट काम करण्याचे नेहमीचे कारण. चाचणीनंतर स्थिर स्थितीची खात्री करण्यासाठी अजून एकदा जोडा, आणि कायदेशीर व्यवस्थापन प्रवेश टिकून आहे का पहा; एका पोर्टसाठी लिहिलेला नियम हेतूपेक्षा रुंद श्रेणीशी जुळण्याची सवय बाळगतो.

नियमासोबत उद्देश आणि स्थान नोंदवा

नोंदवलेल्या उद्देशाशिवाय नियम हा असा नियम आहे जो कोणीही काढण्याची हिंमत करत नाही. प्रत्येक लॉकडाउन नोंदीजवळ तो ज्या प्रवाहाचे रक्षण करतो, तो राहत असलेली साखळी आणि हुक, रुंद परवानग्यांच्या तुलनेत त्याला राखावे लागणारे स्थान, आणि हे सिद्ध करणारी चाचणी ठेवा. सहा महिन्यांनंतर कोणी आसपासचा नियमसंच संपादित केला, तर ती नोंदच स्थान हेतुपूर्वक होते याची एकमेव चेतावणी ठरेल.

बदल बंद करण्यापूर्वी चार गोष्टी खात्री करा: चालू असलेला नियमसंच फाइलशी जुळतो, नवीन प्रयत्नानंतर नवीन नियमाचे काउंटर शून्य नसतात, उलटी दिशा आणि व्यवस्थापन प्रवेश अजूनही काम करतात, आणि बदलापूर्वीच्या सत्राची स्थिती नव्हे तर स्थिर स्थिती सिद्ध करण्यासाठी तुम्ही एकदा पुन्हा जोडले. यापैकी काहीही असत्यापित असेल, तर बोगदा काहीही करो, बदल पूर्ण झालेला नाही.