UFW नियमांनी OpenVPN गेटवे एका LAN पर्यंत मर्यादित करा

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

आधी टोपोलॉजी आणि परवानगी लिहा

उदाहरण वापरते वापरकर्ता जागेतील TUN उपकरण ज्याचे नाव असे आहे असे Community OpenVPNtun0 सर्व्हर, क्लायंट पूल 10.77.0.0/24, आणि एक जोडलेले सबनेट 192.168.60.0/24 lan0 वर. IPv4 फॉर्वर्डिंग आधीच काम करते आणि LAN ला पूलकडे परतीचा मार्ग आधीच आहे, म्हणून येथे काहीही त्यांच्यातील भाषांतरावर अवलंबून नाही.

या होस्टवरील फायरवॉल UFW च्या मालकीचा आहे, आणि कोणताही कंटेनर नियमसंच किंवा वेगळा nftables तक्ता आधीचा स्वीकृती मार्ग बसवू शकत नाही. फिल्टर वगळणारा फ्लो-ऑफलोड शॉर्टकट गार्ड साखळ्यांना केवळ सजावट बनवेल, म्हणून कोणताही सक्रिय नाही याची खात्री करा. OpenVPN चे स्वतःचे client-to-client फॉर्वर्डिंग बंद ठेवा, कारण ऑपरेटिंग सिस्टमचा फिल्टर कधीही ओलांडत नाही अशी समवयस्कांमधील रहदारी त्याने मर्यादित करता येत नाही. बाह्य श्रोता आणि प्रशासकीय नियम जसे आहेत तसेच राहतात, कारण हा बदल फायरवॉल बदलण्याऐवजी डिक्रिप्ट केलेली टनेल रहदारी नियंत्रित करतो.

गार्डना UFW च्या सुरुवातीच्या स्वीकृतींआधी ठेवा

मार्ग परवानगी आणि त्यानंतर नकार कडक सीमेसाठी पुरेसा नाही. स्टॉक before नियम कोणताही वापरकर्ता नियम पाहण्यापूर्वीच स्थापित रहदारी आणि काही ICMP स्वीकारतात, म्हणून गेल्या आठवड्यात परवानगी दिलेला प्रवाह नव्या गंतव्य निर्बंधाबाहेर राहू शकतो, केवळ त्याची स्थिती अजून असल्यामुळे. UFW फाइलींचा बॅकअप घ्या आणि संपादनापूर्वी बँडबाह्य कन्सोल उघडे ठेवा.

फाइलच्या *filter विभागात /etc/ufw/before.rules, विद्यमान घोषणांच्या शेजारी आणि कोणत्याही नियम ओळीपूर्वी दोन साखळ्या घोषित करा.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

घोषणांनंतर लगेच, आणि इनपुट व फॉर्वर्डिंग परवानग्यांपूर्वी, त्यांच्यात उडी मारा आणि त्या काय स्वीकारतात ते ठरवा.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

विभागाचा उर्वरित भाग आणि त्याची COMMIT ओळ ठेवा. दुसरा फिल्टर तक्ता पेस्ट करणे किंवा असंबंधित नियम हटवणे हा फायरवॉल बदल बंद पडण्याचा मार्ग आहे, आणि फाइल महत्त्वाची असलेली एकमेव प्रत होण्यापासून एक रीबूट दूर आहे.

प्रत्येक गार्ड काय स्वीकारतो आणि काय नाकारतो ते वाचा

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

समवयस्क पॅकेट tun0 मध्ये प्रवेश करते आणि त्यातून बाहेर पडते, म्हणून गंतव्य तपासणीपर्यंत पोहोचण्यापूर्वीच ते LAN इंटरफेस चाचणीत अपयशी होते. LAN वरून क्लायंटकडे जाणारी नवी कनेक्शनही उत्तर दिशा चाचणीत अपयशी होतात, ज्यामुळे उलटा कॉलबॅक मार्ग डीफॉल्टने बंद होतो.

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

सबनेटला अधिकृत करा आणि बाजूचे दरवाजे बंद करा

आधी मार्ग परवानगीचे पूर्वावलोकन करा, नंतर लागू करण्यासाठी पूर्वावलोकन ध्वज काढा: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. त्यानंतर वापरकर्ता नियमांचा क्रम तपासा, कारण आधीचा नकार नंतरच्या परवानगीवर अजूनही जिंकतो. संपूर्ण सबनेटसाठी परवानगीही चुकीचा आकार आहे जेव्हा फक्त एका होस्टचा HTTPS पोर्ट पोहोचण्यायोग्य असावा.

इनपुट टाकणे काय करते ते पहा: टनेल क्लायंट गेटवेवरील कोणत्याही सेवेपर्यंत पोहोचू शकत नाहीत, त्याच्या LAN पत्त्याला बांधलेला DNS श्रोता यासह. तिथे DNS होस्ट करण्यासाठी टाकण्यापूर्वी मुद्दाम केलेला अपवाद आणि सुधारित परवानगी करार लागतो. जर UFW IPv6 व्यवस्थापित करत असेल, तर tun0 साठी before6.rules फाइलमध्येही जुळणारे टाकणे जोडा, कारण IPv4 गंतव्य यादी IPv6 पॅकेटबद्दल काहीही सांगत नाही.

पूर्वावलोकन नाही, लोड झालेले धोरण तपासा

रीलोडचे पूर्वावलोकन करा, ते देखभाल विंडोमध्ये लागू करा, आणि जिवंत नियमसंच वाचा.

sudo ufw --dry-run reload
sudo ufw show raw

टनेल गार्ड डीफॉल्ट स्थिती आणि ICMP परवानग्यांपूर्वी दिसतात याची खात्री करा. साधे ufw status हाताने संपादित before नियम दाखवत नाही, म्हणून ऑपरेटर असा निष्कर्ष काढतात की नियम गहाळ आहे, तो प्रत्यक्षात लोड झालेला असतो. तुकडा शोधण्याऐवजी कच्ची यादी वरून खाली वाचा. जर गार्ड स्थिती परवानगीनंतर दिसत असतील, तर सीमा फाइल सुचवते ते करत नाही.

मग मजकुर नाही, वर्तन तपासा. परवानगी दिलेल्या होस्टशी नवे कनेक्शन उघडा आणि उत्तर पहा, सबनेटबाहेरील गंतव्याकडे निरुपद्रवी विनंती पाठवा आणि ती मरते याची खात्री करा, समवयस्क कनेक्शन वापरून पहा, गेटवेवरील स्थानिक सेवा वापरून पहा, आणि न मागितलेले LAN-ते-क्लायंट कनेक्शन वापरून पहा. बदलापूर्वी अस्तित्वात असलेला एक व्याप्तीबाहेरचा प्रवाह समाविष्ट करा, आणि मशीनचा संपूर्ण ट्रॅकिंग तक्ता रिकामा करण्याऐवजी फक्त तो प्रवाह साफ करा.

नियमांसोबत मर्यादा नोंदवा: हे ट्रान्झिट मर्यादित करते आणि दुसरे काहीही नाही. हे क्लायंटला स्वतःचे इंटरनेट कनेक्शन वापरण्यापासून थांबवत नाही, परवानगी दिलेल्या LAN होस्टला रहदारी पुढे पाठवण्यापासून थांबवत नाही, आणि परवानगी दिलेल्या सेवांमधील प्रमाणीकरणाची जागा घेत नाही.