firewalld श्रोता नियम विरुद्ध फॉर्वर्डिंग धोरण: प्रत्येक काय करते

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

दोन धोरणे, एक टनेल

बाह्य धोरण एका सोप्या प्रश्नाचे उत्तर देते: या स्रोतातून येणारा पॅकेट या होस्टवरील UDP 1194 पर्यंत पोहोचू शकतो का? अंतर्गत धोरण दुसऱ्या प्रश्नाचे उत्तर देते: त्या टनेलमागील प्रमाणित क्लायंट या गंतव्यापर्यंत, या प्रोटोकॉलने, या पोर्टवर पोहोचू शकतो का? पहिले सॉकेटबद्दल आहे, दुसरे मार्गाबद्दल, आणि firewalld त्यांना वेगवेगळ्या ऑब्जेक्टने मॉडेल करते कारण ती वेगवेगळ्या बिंदूंवर ठरवली जातात. एक या होस्टवरील सॉकेटचा गुणधर्म आहे, दुसरे त्यातून जाणाऱ्या मार्गाचा.

व्यावहारिक परिणाम असा आहे की काम करणारे टनेल दुसऱ्या धोरणाबद्दल काहीही सांगत नाही, आणि योग्य दुसरे धोरण पहिल्याला अनावश्यक करत नाही.

प्रत्यक्ष बाह्य श्रोत्याला परवानगी द्या

गृहीत धरण्याऐवजी आधीच काय नेमले आहे ते तपासून सुरुवात करा. सक्रिय झोन वाचा, प्रत्यक्षात इनग्रेस वाहणारा झोन सूचीबद्ध करा आणि स्थापित सेवा व्याख्या तपासा, कारण सेवेचे नाव पोर्टचा संच वर्णन करते आणि या सर्व्हरचा श्रोता त्याला जुळतो का याबद्दल काहीही सांगत नाही.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

श्रोता खरोखर त्या झोनवर UDP 1194 असल्यास, नेमका तो पोर्ट आणि वाहतूक उघडा, नंतर चाचणी केल्यानंतर तोच विशिष्ट नियम कायमस्वरूपी करा. स्रोत-आधारित नेमणुकाही तपासा, कारण स्रोत श्रेणीशी बांधलेला झोन इंटरफेस झोनला दिसण्यापूर्वीच रहदारी पकडू शकतो.

डिक्रिप्ट केलेले गंतव्य स्वतंत्रपणे अधिकृत करा

VPN सर्व्हरवरच चालणाऱ्या सेवेशी जोडणी हे स्थानिक-इनपुट धोरण आहे. LAN वरील दुसऱ्या होस्टकडे फॉर्वर्ड केलेल्या जोडणीला फॉर्वर्डिंग धोरण आवश्यक आहे, कर्नेलमध्ये सक्षम केलेले फॉर्वर्डिंग आणि परतीचा मार्ग — या तीन वेगळ्या आवश्यकता आहेत ज्या लोक सहसा एकात विलीन करतात. आधुनिक firewalld धोरण ऑब्जेक्ट इनग्रेस झोन आणि एग्रेस झोनमधील दिशानिर्देशित रहदारी वर्णन करतात, आणि कोणते VPN स्रोत कोणत्या खाजगी सेवांपर्यंत पोहोचू शकतात हे व्यक्त करण्याची योग्य जागा तीच आहे.

परवानगी असलेले स्रोत स्पष्टपणे परिभाषित करा आणि बाकी सर्व नकारात पडू द्या. बाह्य सेवेसाठीची परवानगी ते धोरण नाही, झोनची मांडणी कशीही दिसली तरी.

इंटरफेसवर विश्वास ठेवणे हा चुकीचा छोटा मार्ग का आहे

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

टनेलची झोन नेमणूक त्या कॉन्फिगरेशनच्या मालकीच्या कोणत्याही घटकाद्वारे स्थिर ठेवा. पुनर्प्रारंभात नेमणूक गमावल्यास फायरवॉल नियमाची समस्या वाटणारी पण प्रत्यक्षात टिकाऊपणाची समस्या असलेली अयशस्वीता निर्माण होते.

तीन गोष्टी सत्यापित करा, त्यात एक नकारही

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

सर्व्हरच्या नोंदींमध्ये झोन, पोर्ट, वाहतूक आणि धोरण ऑब्जेक्ट नोंदवा. अन्यथा या होस्टवरील पुढील बदल त्याच गृहीतकापासून सुरू होईल.