pfSense पर Client Export बनाम एक आउटबाउंड OpenVPN इंस्टेंस

आप Client Export पैकेज इंस्टॉल करते हैं, उसे खोलते हैं, और सर्वर चयनकर्ता खाली है। स्वाभाविक निष्कर्ष यह है कि पैकेज खराब है या pfSense बिलकुल VPN क्लाइंट के रूप में काम नहीं कर सकता, और दोनों गलत हैं। चयनकर्ता खाली है क्योंकि pfSense पर कोई रिमोट-एक्सेस सर्वर कॉन्फ़िगर नहीं है, और यह पैकेज कभी फ़ायरवॉल से बाहर डायल कराने का औज़ार नहीं था। दो अलग काम एक शब्द साझा करते हैं, और खाली सूची उनमें से एक से ऐसी चीज़ माँगे जाने की आवाज़ है जो वह नहीं करता।

कुछ भी इंस्टॉल करने से पहले तय करें कि कौन शुरू करेगा

एक सवाल पूछें: कौन सा उपकरण कनेक्शन शुरू करता है? अगर कोई यात्रा करता कर्मचारी दफ़्तर के फ़ायरवॉल से जुड़ता है, तो pfSense सर्वर है और कर्मचारी का लैपटॉप क्लाइंट है। उस स्थिति में आपको जो पैकेज चाहिए वह लैपटॉप के लिए सामग्री तैयार करता है, क्योंकि लैपटॉप वह पक्ष है जो डायल करता है।

अगर pfSense किसी और की VPN सेवा से जुड़ता है, तो फ़ायरवॉल क्लाइंट है और दूरस्थ ऑपरेटर उस अंतिम बिंदु का मालिक है जिसे आप डायल करते हैं।

दोनों स्थितियाँ क्लाइंट शब्द का इस्तेमाल करती हैं, और उलझन यहीं से शुरू होती है. शब्द एक कनेक्शन में भूमिका बताता है, उत्पाद श्रेणी नहीं।

एक्सपोर्टर सर्वर-पक्ष का सहायक है

Client Export pfSense पर पहले से मौजूद रिमोट-एक्सेस सर्वर लेता है और जुड़ने वाले उपकरण को ज़रूरी सामग्री बनाता है। यह उस सर्वर की सेटिंग्स, प्रमाणपत्र और टनल विकल्प पढ़ता है, फिर उन्हें कहीं और इस्तेमाल के लिए पैकेज करता है।

इसलिए चयनकर्ता केवल Remote Access मोड के सर्वर सूचीबद्ध करता है। ऐसा सर्वर न हो तो एक्सपोर्ट करने के लिए कुछ नहीं है, और खाली सूची खराबी नहीं बल्कि सटीक रिपोर्ट है। पहले रिमोट-एक्सेस सर्वर बनाएँ और चयनकर्ता खुद भर जाएगा। यह क्रम लोगों को पैकेज की किसी भी सेटिंग से ज़्यादा बार उलझाता है।

पैकेज संदर्भ इस निर्भरता को स्पष्ट कहता है। पैकेज आपके लिए सर्वर बना सकता है यह मानने से पहले इसे पढ़ें।

आउटबाउंड इंस्टेंस एक अलग कॉन्फ़िगरेशन है

pfSense को किसी दूसरी सेवा का क्लाइंट बनाने का मतलब है OpenVPN क्लाइंट इंस्टेंस बनाना, उस प्रदाता के अंतिम बिंदु, पोर्ट, प्रोटोकॉल, क्रेडेंशियल और विश्वास सामग्री के साथ। Netgate इसे एक्सपोर्ट पैकेज से अलग प्रलेखित करता है, क्योंकि यह कॉन्फ़िगरेशन में अलग वस्तु है।

एक्सपोर्टर इंस्टॉल करने से इनमें से कोई भी फ़ील्ड नहीं भरता, और कोई एक्सपोर्ट प्रारूप आपके लिए उन्हें नहीं बनाएगा। अगर आपका प्रदाता प्रोफ़ाइल देता है, तो आप उसके मान अपने बनाए इंस्टेंस में आयात या उतार लेते हैं।

दोनों कॉन्फ़िगरेशन अलग मानसिक बक्सों में रखें। एक दूसरे उपकरणों को जवाब देता है; दूसरा किसी और सर्वर से टनल माँगता है।

वह एक्सपोर्ट प्रारूप चुनें जिसे उपकरण इस्तेमाल कर सके

एक्सपोर्ट इनलाइन कॉन्फ़िगरेशन, बंडल किए गए आर्काइव और विशिष्ट क्लाइंट ऐप्लिकेशन के लिए इंस्टॉलर के रूप में आते हैं। यह देखकर नहीं कि कौन सा डाउनलोड सबसे पूर्ण लगता है, बल्कि यह देखकर चुनें कि प्राप्तकर्ता उपकरण वास्तव में क्या आयात कर सकता है।

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

कुछ एक्सपोर्ट में प्रमाणपत्र और निजी कुंजियाँ होती हैं, और उस कुंजी सामग्री की रक्षा करने वाला पासवर्ड उपयोगकर्ता के खाता पासवर्ड से अलग हो सकता है। पूरा एक्सपोर्ट कॉन्फ़िगरेशन नमूने के तौर पर टिकट में चिपकाने के बजाय स्वीकृत नामांकन चैनल से सामग्री पहुँचाएँ।

साइट-टू-साइट को पैकेज नहीं, भूमिकाएँ और रूट चाहिए

शाखा टनल फिर एक अलग डिज़ाइन है। पहचानें कि कौन सा अंतिम बिंदु सर्वर भूमिका रखता है और कौन क्लाइंट भूमिका, फिर कुछ भी कॉन्फ़िगर करने से पहले दोनों ओर के रूट किए गए नेटवर्क परिभाषित करें।

शाखा के रूट, फ़ॉरवर्डिंग अनुमति या वापसी पथ पर Client Export की कोई राय नहीं है, क्योंकि रिमोट-एक्सेस क्लाइंट सामग्री तैयार करना ही उसका पूरा काम है।

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