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 त्रुटि उसी क्रम में आते हैं, जो बताता है कि ऊपर की कौन-सी जाँच आपने छोड़ी।