pfSense मा Client Export र बाहिर जाने OpenVPN इन्स्टेन्स

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

केही पनि स्थापना गर्नु अघि कसले सुरु गर्ने निर्णय गर्नुहोस्

एउटा प्रश्न सोध्नुहोस्: कुन यन्त्रले जडान सुरु गर्छ? यदि यात्रामा रहेको कर्मचारी कार्यालयको फायरवालमा जोडिन्छ भने pfSense सर्भर हो र कर्मचारीको ल्यापटप क्लाइन्ट हो। त्यस अवस्थामा आवश्यक प्याकेजले ल्यापटपका लागि सामग्री तयार गर्छ, किनकि डायल गर्ने पक्ष ल्यापटप हो।

यदि pfSense अरू कसैको VPN सेवामा जोडिन्छ भने फायरवाल क्लाइन्ट हो र तपाईंले डायल गर्ने अन्तिम बिन्दुको मालिक टाढाको सञ्चालक हो।

दुवै अवस्थाले क्लाइन्ट शब्द प्रयोग गर्छन्, र भ्रम यहीँबाट सुरु हुन्छ। यो शब्द एउटा जडानमा भूमिका बताउँछ, उत्पादन श्रेणी होइन।

निर्यातकर्ता सर्भर-पक्षको सहायक हो

Client Export ले pfSense मा पहिलेदेखि रहेको टाढा-पहुँच सर्भर लिन्छ र जोडिने यन्त्रलाई आवश्यक सामग्री उत्पादन गर्छ। यसले त्यो सर्भरका सेटिङ, प्रमाणपत्र र टनेल विकल्प पढ्छ, त्यसपछि अन्यत्र प्रयोगका लागि प्याकेज गर्छ।

त्यसैले चयनकर्ताले Remote Access मोडका सर्भर मात्र सूचीबद्ध गर्छ। त्यस्तो सर्भर नभए निर्यात गर्ने केही हुँदैन, र खाली सूची दोष होइन, सटीक प्रतिवेदन हो। पहिले टाढा-पहुँच सर्भर बनाउनुहोस्, चयनकर्ता आफैं भरिन्छ। यो क्रमले मानिसहरूलाई प्याकेजभित्रको कुनै पनि सेटिङभन्दा बढी पटक अलमल्याउँछ।

प्याकेज सन्दर्भ यो निर्भरता स्पष्ट बताउँछ। प्याकेजले तपाईंका लागि सर्भर बनाउन सक्छ भन्ने ठान्नु अघि यो पढ्नुहोस्।

बाहिर जाने इन्स्टेन्स छुट्टै कन्फिगरेसन हो

pfSense लाई अर्को सेवाको क्लाइन्ट बनाउनु भनेको OpenVPN क्लाइन्ट इन्स्टेन्स त्यो प्रदायकको अन्तिम बिन्दु, पोर्ट, प्रोटोकल, प्रमाण-परिचय र विश्वास सामग्रीसहित बनाउनु हो। Netgate ले यसलाई निर्यात प्याकेजबाट छुट्टै कागजात गर्छ, किनकि यो कन्फिगरेसनमा फरक वस्तु हो।

निर्यातकर्ता स्थापना गर्दा यी कुनै पनि फिल्ड भरिँदैन, र कुनै निर्यात ढाँचाले ती तपाईंका लागि बनाउँदैन। यदि तपाईंको प्रदायकले प्रोफाइल दिन्छ भने तपाईंले त्यसका मान तपाईंले बनाएको इन्स्टेन्समा आयात वा प्रतिलिपि गर्नुहुन्छ।

दुवै कन्फिगरेसन छुट्टाछुट्टै मानसिक बाकसमा राख्नुहोस्। एउटाले अन्य यन्त्रलाई जवाफ दिन्छ; अर्कोले अर्को सर्भरसँग टनेल माग्छ।

यन्त्रले प्रयोग गर्न सक्ने निर्यात ढाँचा छान्नुहोस्

निर्यात इनलाइन कन्फिगरेसन, बन्डल गरिएका अभिलेख र विशेष क्लाइन्ट अनुप्रयोगका लागि इन्स्टलरका रूपमा आउँछन्। कुन डाउनलोड सबैभन्दा पूर्ण देखिन्छ भन्ने होइन, प्राप्त गर्ने यन्त्रले साँच्चै के आयात गर्न सक्छ भन्ने आधारमा छान्नुहोस्।

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

केही निर्यातमा प्रमाणपत्र र निजी कुञ्जी हुन्छन्, र त्यो कुञ्जी सामग्री जोगाउने पासवर्ड प्रयोगकर्ताको खाता पासवर्डभन्दा फरक हुन सक्छ। पूरै निर्यात कन्फिगरेसन नमुनाका रूपमा टिकटमा टाँस्नुको सट्टा स्वीकृत दर्ता माध्यमबाट सामग्री पुर्‍याउनुहोस्।

साइट-टु-साइटलाई प्याकेज होइन, भूमिका र मार्ग चाहिन्छ

शाखा टनेल फेरि फरक डिजाइन हो। कुन अन्तिम बिन्दुले सर्भर भूमिका र कुनले क्लाइन्ट भूमिका लिन्छ पहिचान गर्नुहोस्, त्यसपछि केही कन्फिगर गर्नु अघि दुवैतर्फका मार्गित सञ्जाल परिभाषित गर्नुहोस्।

शाखाका मार्ग, फर्वार्डिङ अनुमति वा फिर्ती मार्गबारे Client Export को कुनै मत छैन, किनकि टाढा-पहुँच क्लाइन्ट सामग्री तयार गर्नु नै यसको सम्पूर्ण काम हो।

पहिले भूमिका र मार्ग सूची लेख्नुहोस्, प्याकेजको प्रश्न आफैं जवाफ दिन्छ। गलत गरे कुनै निर्यात ढाँचाले डिजाइन जोगाउँदैन। फिर्ती मार्गमा पनि यही लागू हुन्छ: केन्द्रसम्म पुग्ने तर जवाफ पाउन नसक्ने शाखा कार्यरत टनेल होइन।