UFW नियमों से OpenVPN गेटवे को एक LAN तक सीमित करें

फ़ायरवॉल फ़ाइल खोलने से पहले अनुमति तय करें: प्रमाणित क्लाइंट एक निश्चित सबनेट से कनेक्शन खोल सकते हैं, और गेटवे को हर अन्य ट्रांज़िट मार्ग अस्वीकार करना चाहिए, तब भी जब कोई क्लाइंट अतिरिक्त रूट स्थापित करे। वही वाक्य डिज़ाइन है, और नीचे का हर नियम उसे लागू करने के लिए है। इससे व्यापक कुछ भी, जैसे पूरा निजी पता स्थान, टनल से इंटरनेट जाना या पीयर-टू-पीयर ट्रैफ़िक, एक अलग डिज़ाइन है जिसे अपना निर्णय चाहिए। नियम जानबूझकर उबाऊ भी हैं, क्योंकि चतुर फ़ायरवॉल वही है जिसे बाद में कोई ऑडिट नहीं कर सकता।

पहले टोपोलॉजी और अनुमति लिखें

उदाहरण एक Community OpenVPN सर्वर का उपयोग करता है जिसमें उपयोगकर्ता-स्थान का TUN डिवाइस tun0 नाम से है, क्लाइंट पूल 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 होस्ट को ट्रैफ़िक आगे भेजने से नहीं रोकता, और स्वीकृत सेवाओं के भीतर प्रमाणीकरण का स्थान नहीं लेता।