नवीन 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 हाताने लिहिलेले फ्रेमवर्क नियम वगळते, म्हणून क्रम कर्नेल लागू करते त्यापेक्षा वेगळा दिसू शकतो। नियम चुकीच्या जागी आहे असा निष्कर्ष काढण्यापूर्वी दोन्ही तुलना करा।

नंतर नियम विस्तृत नाही तर संकुचित आहे हे सिद्ध करणारे दोन नियंत्रण तपासा: त्याच क्लायंटकडून परवानगी असलेले गंतव्य अजूनही कार्य करते, आणि दुसरा क्लायंट त्याच्या धोरणाने परवानगी दिल्यास नाकारलेल्या गंतव्यापर्यंत अजूनही पोहोचतो। दोन्ही चाचण्या मोडणारा नकार म्हणजे धोरण बदल, लक्ष्यित उपाय नाही।

चाचणी संपल्यावर तुम्ही जोडलेला नियमच काढा, तो नेमका पुन्हा लिहून। धोरण कायमस्वरूपी असेल तर क्लायंट ओळख, गंतव्यचा मालक आणि पुनरावलोकन तारखेसह ते फायरवॉल मालकाकडे सोपवा, जेणेकरून पुन्हा नेमलेला टनेल पत्ता जुना नकार मागे ठेवणार नाही।