दो OpenVPN पैकेट पथों के लिए Shorewall ज़ोन
एन्क्रिप्टेड OpenVPN परिवहन को डिक्रिप्टेड क्लाइंट ट्रैफ़िक से अलग करें, टनल को अपना ज़ोन दें और केवल वही एक सेवा अनुमत करें जिसकी क्लाइंट को ज़रूरत है।
दो पैकेट प्रवाह उस Shorewall गेटवे से गुज़रते हैं जो OpenVPN को समाप्त करता है, और उनमें से केवल एक एन्क्रिप्टेड है। पहला इंटरनेट की ओर के इंटरफ़ेस पर VPN श्रोता तक क्लाइंट का परिवहन है। दूसरा टनल इंटरफ़ेस से निकलने वाला डिक्रिप्टेड अनुरोध है, जो कार्यालय सर्वर या गेटवे पर किसी सेवा की ओर जाता है। नीति संपादित करने से पहले दोनों का नक्शा बनाएँ, क्योंकि पहले को संतुष्ट करने वाला नियम दूसरे के लिए कुछ नहीं करता।
नीति संपादित करने से पहले दोनों प्रवाह बनाएँ
प्रवाहों को स्रोत, गंतव्य, प्रोटोकॉल और पोर्ट वाली पंक्तियों के रूप में लिखें। बाहरी पथ पर स्रोत क्लाइंट का सार्वजनिक पता है और गंतव्य गेटवे का श्रवण पोर्ट है; Shorewall इसे इंटरनेट से फ़ायरवॉल की ओर ट्रैफ़िक मानता है। भीतरी पथ पर स्रोत टनल पता-परास है और गंतव्य अनुमोदित सेवा है। एक ही प्रशासक दोनों बनाए रखे तब भी दोनों पंक्तियों के स्वामी अलग होते हैं।
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
पंक्ति केवल तब जोड़ें जब अनुरोध गेटवे पर ही समाप्त होता हो, जैसे रिज़ॉल्वर या प्रबंधन तक पहुँच। होस्ट पर की सेवा अग्रेषित पथ नहीं, होस्ट-इनपुट नीति का पालन करती है। इन दोनों को मिलाना ही वह तरीका है जिससे संकीर्ण टनल नियम अंततः प्रशासनिक इंटरफ़ेस उजागर कर देता है।
टनल ज़ोन और इंटरफ़ेस का दायरा निर्धारित करें
रोड-वॉरियर ज़ोन /etc/shorewall/zones में घोषित होता है, टनल इंटरफ़ेस /etc/shorewall/interfaces में जुड़ता है, और बाहरी कनेक्शन /etc/shorewall/tunnels में वर्णित होता है। स्थापित संस्करण के सिंटैक्स के अनुरूप रहें, क्योंकि स्तंभ क्रम और विकल्प नाम प्रमुख संस्करणों के बीच बदल गए हैं। मार्गदर्शिका का उदाहरण पोर्ट डेमन के वास्तव में सुनने वाले पोर्ट से भिन्न पोर्ट की अनुमति देने का कारण नहीं है। केवल संख्याएँ मेल खाने से TCP और UDP विनिमेय नहीं हैं।
मार्गदर्शिका इंटरफ़ेस को tun+ से समूहित करती है। एक से अधिक टनल वाले होस्ट पर वह वाइल्डकार्ड भिन्न विश्वास-स्तर का दूसरा VPN उसी ज़ोन में रख सकता है। दायरे की समीक्षा वास्तव में विद्यमान इंटरफ़ेस के विरुद्ध करें, और इंटरफ़ेस के नाम हाथ से संपादित करने के बजाय नामकरण कनेक्शन प्रबंधक के जीवनचक्र के अधीन रखें।
ऐतिहासिक मार्गदर्शिका में बहुत पुराने OpenVPN कॉन्फ़िगरेशन नमूने हैं, और उसकी क्रिप्टो सलाह वर्तमान परिनियोजन में नकल नहीं की जानी चाहिए। इसके बजाय ज़ोन और प्रवाह का मॉडल उधार लें। क्रिप्टोग्राफ़िक आधार गेटवे की अनुरक्षित OpenVPN नीति से लें।
केवल उसी पथ को अनुमत करें जिसे आपने वर्गीकृत किया
VPN ज़ोन से LAN तक व्यापक स्वीकृति प्रारंभिक रेखाचित्र है, पूर्ण नीति नहीं। अनुमत क्लाइंट स्रोत, वास्तविक सेवा पता, प्रोटोकॉल और पोर्ट लिखें। फिर उसके ऊपर के नियम और ज़ोन का डिफ़ॉल्ट पढ़ें, क्योंकि संकीर्ण जोड़ पहले से मेल खाने वाली व्यापक अनुमति को रद्द नहीं करता। गेटवे होस्ट की ओर ट्रैफ़िक उसके माध्यम से अग्रेषित ट्रैफ़िक से अलग संबंध है।
क्लाइंट-से-क्लाइंट ट्रैफ़िक को अपना निर्णय चाहिए। OpenVPN का client-to-client और Shorewall का routeback दोनों इस पर असर डालते हैं कि क्लाइंट एक-दूसरे तक पहुँच सकें, और केवल एक LAN अनुप्रयोग चलाने के लिए किसी को भी सक्षम नहीं किया जाना चाहिए। परीक्षण से पहले तय करें कि अलगाव कहाँ लागू होता है।
उत्तर पथ को उसी योजना में रखें। सेवा या उसके राउटर को जानना चाहिए कि ट्रैफ़िक को टनल परास में कैसे लौटाना है, या डिज़ाइन को स्रोत का जानबूझकर और इच्छित दायरे में अनुवाद करना चाहिए।
सत्यापित करें, फिर दोनों पथ सिद्ध करें
कुछ भी पुनः प्रारंभ करने से पहले कॉन्फ़िगरेशन सत्यापित करें, और नई नीति गलत होने की स्थिति के लिए एक स्वतंत्र प्रशासनिक सत्र खुला रखें।
shorewall checkस्वच्छ जाँच के बाद कॉन्फ़िगरेशन लागू करें और पढ़ें कि Shorewall ने क्या लोड किया। ये पठन चल रही नीति का वर्णन करते हैं, न कि वह जो फ़ाइल कहती प्रतीत होती है।
shorewall show zones
ip route get 192.168.10.20एक ही क्लाइंट से एक नया अनुमत अनुरोध और एक जानबूझकर अस्वीकृत अनुरोध परखें। सफल OpenVPN हैंडशेक केवल बाहरी विनिमय सिद्ध करता है; अनुमत सेवा और अस्वीकृत संसाधन वह भीतरी नीति सिद्ध करते हैं जो आप चाहते थे। फिर क्लाइंट को पुनः जोड़ें और दोहराएँ, क्योंकि टनल इंटरफ़ेस का नाम और पता सत्रों के बीच बदल सकते हैं। यदि परिणाम भिन्न हो, तो नियम चौड़ा करने के बजाय ज़ोन का दायरा ठीक करें।