OpenVPN प्रोफाइलको सर्भर आयात गर्नु अघि कसरी जाँच्ने

कसैले तपाईंलाई प्रोफाइल पठाउँछ, तपाईं त्यसलाई आयात गर्नुहुन्छ, र तीस सेकेन्डपछि कोही पनि नजाँचेको गन्तव्यमा क्लाइन्ट डायल गर्दै छ। पहिले फाइल पाठ सम्पादकमा पढ्नुहोस्, किनकि महत्त्वपूर्ण सबै कुरा मुठीभर निर्देशनहरूमा अटाउँछ: remote, proto, port, ca, cert, tls-crypt र verify-x509-name। बाँकी सबै पूर्वनिर्धारित मान हुन्, र अचम्महरू त्यहीँ बस्छन्।

फाइलले प्रयोग गर्न सक्ने हरेक अन्त्य बिन्दु सूचीबद्ध गर्नुहोस्

अन्त्य बिन्दुबाट सुरु गर्नुहोस्, किनकि एउटा प्रोफाइलमा धेरै हुन सक्छन्। grep -nE '^[[:space:]]*(remote|proto|port|remote-random|connection)' profile.ovpn ले हरेक उम्मेदवारलाई फाइलको क्रममा छाप्छ, इनलाइन <connection> ब्लकभित्र नेस्ट गरिएकाहरू पनि समावेश गरी।

जब निर्देशनले पोर्ट छोड्छ, क्लाइन्ट सुन्नेको पूर्वनिर्धारितमा फर्कन्छ, त्यसैले एक्लै remote vpn.example.com भन्नाले पोर्ट 1194 बुझिन्छ, फाइलमा पछि जुनसुकै proto आए पनि। धेरै साधारण remote लाइनहरू विकल्प हुन्: क्लाइन्टले तिनीहरूलाई क्रममा प्रयास गर्छ, remote-random ले नमिसाएसम्म, र यसले कहिल्यै चुपचाप अर्को अपरेटरको होस्ट प्रतिस्थापन गर्दैन। असम्बन्धित डोमेनमा दुई remote लाइनहरू भनेको रोकिएर कुन चाहिँ अभिप्रेत थियो भनी सोध्ने ठाउँ हो।

proto को हिज्जेमा पनि ध्यान दिनुहोस्। tcp क्लाइन्ट पक्षको tcp-client को पर्यायवाचीका रूपमा स्वीकारिन्छ, तर क्लाइन्ट प्रोफाइलमा tcp-server कन्फिगरेसन त्रुटि हो जुन सफा रूपमा असफल हुनुभन्दा अड्किने प्रवृत्ति राख्छ।

पहिले नाम, त्यसपछि पोर्ट पुष्टि गर्नुहोस्

dig +short vpn.example.com ले नाम अवस्थित छ कि छैन र कुन ठेगानाहरू फर्काउँछ भनी बताउँछ, र बहु-ठेगाना वा प्रोक्सीपछाडिको अन्त्य बिन्दुले वैध रूपमा धेरै फर्काउन सक्छ। नामको समाधान पूर्वशर्त हो, स्वामित्वको प्रमाण होइन; जो कोहीले नामलाई ठेगानामा संकेत गर्न सक्छ, र एउटा ठेगानाले धेरै नामका लागि जवाफ दिन सक्छ।

त्यसपछि तपाईंले भेट्टाउनुभएको पोर्टमा सुन्ने जाँच्नुहोस्, यातायातसँग मिलाएर। TCP मा openssl s_client -connect vpn.example.com:1194 -servername vpn.example.com ले सर्भरले प्रस्तुत गर्ने शृंखला छाप्छ। UDP मा तपाईंलाई DTLS चाहिन्छ: openssl s_client -dtls1_2 -connect vpn.example.com:1194 डेटाग्राममा त्यही ह्यान्डशेक चलाउँछ। पूरा भएको ह्यान्डशेकले केही सुनिरहेको र प्रमाणपत्र राखेको प्रमाणित गर्छ, जुन ping ले देखाउनेभन्दा बढी र प्रोफाइलका आफ्नै विश्वास सेटिङले माग्नेभन्दा कम हो।

जब ह्यान्डशेक असफल हुन्छ र होस्टले ping मा जवाफ दिन्छ, पोर्ट सम्भवतः गलत वा फिल्टर गरिएको छ। यसलाई सही पोर्ट माग्ने कारण मान्नुहोस्, नजिकका पोर्ट सफा गर्ने निम्तो होइन। nc -vzu ले पनि केही स्ट्याकमा केही नसुन्दै सफलता रिपोर्ट गर्छ, त्यसैले पछाडि ह्यान्डशेक बिना खाली UDP परीक्षणले केही अर्थ राख्दैन।

विश्वास पिन ठेगानाबाट अलग पढ्नुहोस्

ठेगानाले क्लाइन्ट कहाँ जाने निर्धारण गर्छ; विश्वास ब्लकले पुगेपछि कसलाई विश्वास गर्ने निर्धारण गर्छ। verify-x509-name "vpn.example.com" name विषयको सामान्य नाम पिन गर्छ, र remote-cert-tls server सर्भर प्रमाणीकरणका लागि विस्तारित कुञ्जी प्रयोगको माग गर्छ। अपरेटरले दिएको प्रोफाइलमा दुवै हुनुपर्छ।

ca, इनलाइन <ca> ब्लक, र tls-crypt वा tls-auth मध्ये एक खोज्नुहोस्। tls-auth प्रयोग गर्ने प्रोफाइललाई क्लाइन्टमा key-direction 1 चाहिन्छ जब सर्भर पक्षले दिशा 0 प्रयोग गर्छ, र अमिल्दोले ह्यान्डशेकलाई प्रमाणपत्रको दोषजस्तै पढिने TLS त्रुटिले असफल बनाउँछ। भर्खरै नाम समाधान गरिएको अपरेटरको नभएको इनलाइन CA भनेको फाइल दुई स्रोतबाट जोडिएको हो, र यही त्यो अवस्था हो जसलाई स्पष्ट रूपमा अस्वीकार गर्नुपर्छ।

verify-x509-name name, name-prefix वा subject मोड लिन्छ, र अन्तिमले सर्भरले छाप्ने ठ्याक्कै त्यही क्रममा पूर्ण विशिष्ट नाम अपेक्षा गर्छ। मानको आकारसँग मिल्ने मोड छान्नुहोस्, किनकि क्लाइन्टले नजिकको चुकबारे चेतावनी दिनुभन्दा हरेक जडान अस्वीकार गर्छ। तपाईंले नलेखेको फाइलका लागि साधारण होस्टनामसहित name सबैभन्दा कम अचम्मलाग्दो विकल्प हो।

चुपचाप असफल हुने विकल्पहरू जाँच्नुहोस्

OpenVPN 2.6 ले data-ciphers मार्फत साइफरहरूमा वार्ता गर्छ, र पुरानो cipher AES-256-CBC लाइन मात्र भएको प्रोफाइलले नियन्त्रण च्यानल पूरा गरेर त्यसपछि डेटामा अड्किन सक्छ। त्यो मान पढ्दा फाइल तपाईं जोडिनुभएको सर्भरभन्दा पुरानो हो कि होइन थाहा हुन्छ; 2.6 को म्यानुअल पृष्ठ ले वार्ताको क्रम सूचीबद्ध गर्छ, अपरेटरलाई उद्धृत गर्नुपरेमा।

फाइलनाम बिनाको auth-user-pass भन्नाले क्लाइन्ट सोध्छ, त्यसैले आफैं पूर्ण देखिने प्रोफाइललाई पनि प्रमाणहरू चाहिन्छ। auth-user-pass credentials.txt भन्नाले सम्भवतः तपाईंलाई नपठाइएको फाइल अपेक्षा गर्छ। nobind र resolv-retry infinite सामान्य र हानिरहित छन्, जबकि explicit-exit-notify UDP का लागि मात्र हो र TCP मा बेकार छ।

यीमध्ये कुनैले पनि प्रोफाइल कहाँ जोडिन्छ भन्ने बदल्दैन, तर हरेकले यो जोडिन्छ कि जोडिँदैन भन्ने बदल्छ, र कुनै पनि क्लाइन्टको आयात संवादमा देखिँदैन।

निर्णय गर्नुहोस्, त्यसपछि के निर्णय गर्नुभयो लेख्नुहोस्

यो पढाइपछि तीन नतिजा छन्, र एउटा मात्र आयात हो। जब अन्त्य बिन्दु र पिनहरू छुट्टै माध्यमबाट प्राप्त निर्देशनसँग मिल्छन्, त्यसलाई आयात गर्नुहोस्। जब अन्त्य बिन्दु सही देखिन्छ तर पिन वा CA मिल्दैनन्, सुधारिएको फाइल माग्नुहोस्। जब फाइलले फरक स्रोतका अन्त्य बिन्दु वा CA सामग्री मिसाउँछ, त्यसलाई मेटेर नयाँ प्रतिलिपि माग्नुहोस्।

तपाईंले समीक्षा गर्नुभएको ह्यास लेख्नुहोस्, ताकि अर्को व्यक्तिले फाइल बदलियो कि भनी जान्न सकोस्: sha256sum profile.ovpn, तपाईंका टिप्पणीमा अन्त्य बिन्दुको छेउमा टाँस्नुहोस्। प्रोफाइल ठेगानाको सूची होइन, पूरै व्यवस्था हो, त्यसैले कहिल्यै काम गर्ने remote लाई अर्काको विश्वास ब्लकमा उनीहरूका प्रमाण राखेर नजोड्नुहोस्।

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

यदि तपाईंले त्यसलाई आयात गर्नुभयो र पहिलो प्रयास असफल भयो, क्लाइन्टलाई --verb 3 सहित चलाउनुहोस् र पहिलो दस लाइन पढ्नुहोस्: समाधान गरिएको remote ठेगाना, वार्ता गरिएको proto र TLS त्रुटि यही क्रममा आउँछन्, जसले माथिका कुन जाँच तपाईंले छोड्नुभयो भनी बताउँछ।