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 त्रुटी याच क्रमाने येतात, जे सांगते की वरीलपैकी कोणती तपासणी तुम्ही वगळली।