Tunnelblick data-ciphers ओळखला जात नाही: कोणते इंजिन चालू होते?

Tunnelblick न ओळखलेल्या data-ciphers पर्यायाची नोंद करते, त्याच श्वासात OpenVPN 2.4 चा उल्लेख करते, आणि कनेक्शन कधीही सुरू होत नाही। हे सिफरबद्दलचे मतभेद नसून स्थानिक पार्सिंग अपयश आहे, कारण गेटवेसोबत कोणतीही वाटाघाटी होण्यापूर्वीच इंजिनने प्रोफाइल नाकारले। सर्व्हरच्या सिफर धोरणाबद्दलचा नेहमीचा सल्ला इथे उपयोगी पडणार नाही; पार्सरने आधी फाइल समजून घेतली पाहिजे। ह्या एका कॉन्फिगरेशनने प्रत्यक्षात सुरू केलेले इंजिन शोधा, आणि बाकी आपोआप येईल।

प्रोफाइलला हात लावण्यापूर्वी लॉग ओळ वाचा

अयशस्वी कनेक्शन Tunnelblick च्या तपशील विंडोमध्ये उघडा आणि लॉग वरून वाचा। पहिल्या ओळी इंजिनची आवृत्ती आणि त्याला दिले जाणारे प्रोफाइल सांगतात, त्यानंतर पार्सिंग थांबवणारा पर्याय। त्यानंतरचे सर्व आवाज आहे, कारण प्रक्रिया बाहेर पडली।

त्या लॉगमधून तीन तथ्ये नोंदवा: इंजिनची आवृत्ती, कॉन्फिगरेशनचे नाव आणि अचूक संदेश। ही तीनच संपूर्ण निदान आहेत। दुरुस्तीसाठी स्थापित अॅप्लिकेशन बदलावे लागल्यास हीच तुम्हाला लागतील। ओळींचा स्क्रीनशॉट घ्या, पुन्हा सांगण्याऐवजी, कारण स्मरणातून पुनरावृत्ती करताना पर्यायांची नावे चुकीची टाइप होणे सोपे आहे।

ते कॉन्फिगरेशन कोणते इंजिन चालवते याची पुष्टी करा

Tunnelblick हे OpenVPN इंजिनभोवती गुंडाळलेले अॅप्लिकेशन आहे, आणि वेगवेगळी कॉन्फिगरेशन वेगवेगळी इंजिन चालवू शकतात। अॅप्लिकेशनची आवृत्ती वाचण्याऐवजी तपशील विंडोमध्ये या कॉन्फिगरेशनसाठी निवडलेली आवृत्ती तपासा, आणि कॉन्फिगरेशन कधीही वापरत नाही अशा टर्मिनल openvpn बायनरीचे आउटपुट त्याजागी ठेवू नका। Tunnelblick चे OpenVPN आवृत्तींचे मार्गदर्शक ती निवड कशी काम करते आणि निवड कुठे साठवली जाते हे स्पष्ट करते।

हा फरक महत्त्वाचा आहे कारण मशीनमध्ये PATH वर आधुनिक बायनरी असू शकते आणि अयशस्वी कनेक्शनच्या मागे बंडल केलेले 2.4 इंजिन असू शकते। प्रोफाइलचे मूल्यांकन दुसरे करते।

openvpn --version
ls /Applications/Tunnelblick.app/Contents/Resources/openvpn/

हे दोन आदेश दाखवतात की टर्मिनल काय चालवेल आणि स्थापित अॅप्लिकेशनकडे कोणत्या इंजिन डिरेक्टरी आहेत। दोन्हीपैकी एकही अयशस्वी कॉन्फिगरेशनने काय वापरले याचा पुरावा नाही, कारण लॉगने ते आधीच सांगितले आहे, आणि Tunnelblick च्या आवृत्त्यांमध्ये मार्ग वेगळे असतात।

निर्देशाचे नाव का बदलले

OpenVPN ने 2.5 मध्ये data-ciphers वाटाघाटी यादी म्हणून सादर केले, आणि त्या आवृत्तीत अप्रचलित झालेले पूर्वीचे ncp-ciphers लेखन बदलले। 2.4 इंजिनमध्ये असा पर्याय नाही, म्हणून ते न ओळखता येणाऱ्या पहिल्या टोकनवर थांबते। एकटा cipher पर्यायही यादीचे जुने टोपणनाव नाही; तो वाटाघाटी संचाऐवजी एक सिफर नाव देतो।

म्हणूनच आवृत्त्यांमध्ये मजकूर बदलल्याने पार्स होणारी आणि नंतर अनपेक्षित वागणारी प्रोफाइल तयार होतात, आणि म्हणूनच फोरम पोस्टमधील तुकडा कॉपी करणे आवृत्ती तपासणी नाही। पर्यायांची नावे फॉलबॅक हाताळणी आणि डीफॉल्टसोबत सरकली, आणि एक निर्देश नाव बदलून जोडलेली फाइल इंजिनसाठी लिहिलेल्या फाइलशी समान नाही।

लक्षण नाही, इंजिन किंवा प्रोफाइल दुरुस्त करा

समर्थित तैनातीसाठी टिकाऊ दुरुस्ती म्हणजे ऑपरेटरचे प्रोफाइल स्वीकारणारे समर्थित Tunnelblick आणि इंजिन यांचे संयोजन, अॅप्लिकेशनच्या स्थापनेच्या मालकामार्फत आयोजित केलेले। जुनी स्थापना काही काळ राहायची असल्यास त्या इंजिनासाठी आणि गेटवे प्रत्यक्षात स्वीकारत असलेल्या सिफरसाठी लिहिलेले प्रोफाइल मागा।

data-ciphers आणि data-ciphers-fallback हटवल्याने ही विशिष्ट पार्सिंग त्रुटी खरोखर दूर होते, आणि म्हणूनच ते मोहक वाटते। ते संपादित करण्याचा उद्देश नसलेल्या सुरक्षा कॉन्फिगरेशनमध्ये कोणत्या सिफरवर वाटाघाटी होतील हेही ते गुपचूप बदलते। मूळ प्रोफाइल ठेवा आणि त्याऐवजी समर्थित सेटिंग्जची जाणीवपूर्वक तुलना करा।

पुन्हा प्रयत्न करा आणि पुढील टप्पा वाचा

दुरुस्तीनंतर कनेक्शन पुन्हा वापरून पाहा आणि यश गृहीत धरण्याऐवजी नवीन लॉग सुरुवातीपासून वाचा। आता पार्स होणारे प्रोफाइल तरीही सिफर वाटाघाटी, प्रमाणपत्र पडताळणी, प्रमाणीकरण किंवा राउटिंगवर थांबू शकते, आणि त्या प्रत्येक अपयशाचा स्वतःचा पुरावा आहे।

वाटाघाटी अयशस्वी झाल्यास दोन्ही टोकांना समर्थित सिफर आणि प्रत्येकाला परवानगी असलेल्या सिफरची तुलना करा। प्रमाणीकरण अयशस्वी झाल्यास प्रोफाइल आणि इंजिन आता गेटवेपर्यंत पोहोचण्याइतके चांगले काम करत आहेत, जी नोंदवण्यासारखी प्रगती आहे। पहिल्या शांत लॉगवर ती साखळी थांबवणे म्हणजे चुकीच्या कारणाने सुरक्षा सेटिंग काढण्याचा मार्ग।