tls-auth key-direction: 0 र 1 फरक हुनुपर्छ, मिल्नु हुँदैन
tls-auth सँग दुवै छेउलाई विपरीत दिशा चाहिन्छ, 0 र 1, वा दुवैले सेटिङ छोड्नुपर्छ। उही संख्या असफल हुन्छ, र tls-crypt ले यसलाई कहिल्यै प्रयोग गर्दैन।
सुरुङको एक छेउले अर्को छेउले कहिल्यै जाँच नगर्ने कुञ्जी स्लटले नियन्त्रण च्यानलमा हस्ताक्षर गर्छ, र एउटै प्रमाणपत्र साटासाट हुनुअघि नै जडान प्रमाणीकरण त्रुटिले मर्छ। tls-auth को दिशा बेमेल यस्तै देखिन्छ, र यो निर्धारक छ: उही दुई फाइलहरू हरेक प्रयासमा, जुनसुकै सञ्जालबाट असफल हुन्छन्। लगमा तपाईंले खोजिरहनुभएको विकल्पको नाम छैन, त्यसैले मानिसहरू कहिल्यै नबिग्रिएका कुञ्जीहरू फेरि बनाउँछन् र प्रमाणपत्रहरू फेरि जारी गर्छन्। समाधान भनेको दुवै छेउलाई पूरक बनाउनु, वा दुवैलाई द्विदिश राख्नु हो, प्रमाणीकरण कमजोर पार्नु होइन।
असफलता प्रमाणपत्रहरूभन्दा अघि आउँछ
tls-auth सँग दुवै सहकर्मीले एउटै साझा कुञ्जी राख्छन् र प्रत्येकले त्यसबाट बनेका दुई स्लटमध्ये एउटा प्रयोग गर्छ: एउटा स्लटले बाहिर जाने नियन्त्रण प्याकेटमा हस्ताक्षर गर्छ, अर्कोले भित्र आउने प्याकेट जाँच्छ। दिशा 0 र दिशा 1 ले यी भूमिकाहरू उल्टो क्रममा तोक्छन्, त्यसैले HMAC जाँच मिल्नका लागि जोडी पूरक हुनुपर्छ। एक छेउमा तोकाइ उल्टिएमा प्राप्तकर्ताले गलत स्लटमा हस्ताक्षर खोज्छ र प्याकेट अस्वीकार गर्छ। सत्र त्यहीँ अन्त्य हुन्छ, त्यसैले त्रुटि प्याकेट प्रमाणीकरणसँग सम्बन्धित छ, प्रमाणपत्र भण्डारले बनाउने कुनै कुरासँग होइन।
निर्धारकता निदानका लागि महत्त्वपूर्ण छ, किनकि समय वा मार्गको समस्या फरक चिन्ह छोड्छ: रोकिएर जाने कटौती, एउटा दिशाको असफलता, वा निश्चित सञ्जालमा मात्र मर्ने सत्र। दिशा बेमेल हरेक पटक पहिलो ह्यान्डशेकमा असफल हुन्छ, र उही दुई फाइल भएको अर्को मेसिनमा पनि ठ्याक्कै त्यसै गरी असफल हुन्छ। --verb 4 मा लग पढ्नुहोस् र अन्तिम लाइनको सट्टा पहिलो अस्वीकृत प्याकेट खोज्नुहोस्। यदि त्यो अस्वीकृति कुनै प्रमाणपत्र साटासाटअघि हुन्छ भने, साझा कुञ्जी र त्यसको दिशा जाँच्न लायक दुई कुरा हुन्।
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
संख्या कहाँ बस्छ
OpenVPN 2.6 पुस्तिका ले दिशाका लागि दुई ठाउँ अभिलेख गर्छ: कुञ्जी छुट्टै फाइलमा हुँदा tls-auth को दोस्रो आर्गुमेन्ट, र कुञ्जी प्रोफाइलमा इनलाइन हुँदा छुट्टै key-direction लाइन। दुवैले एउटै मान सेट गर्छन्, त्यसैले प्रोफाइलले एउटा रूप वा अर्को प्रयोग गर्नुपर्छ, कहिल्यै दुवै होइन। छोड्नु पनि एउटा विकल्प हो, र यसले दुवै सहकर्मीलाई द्विदिश व्यवस्थामा राख्छ जुन कुनै पक्षले दिशा नबताउँदा काम गर्छ। एउटै संख्या भएका दुई सहकर्मी त्यो व्यवस्थामा छैनन्: प्रत्येकले एउटा स्लटमा हस्ताक्षर र अर्कोमा जाँचको अपेक्षा गर्छ, र दुवैले त्यो एउटै तरिकाले गर्छन्।
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
इनलाइन रूप आफ्नै लाइनमा निर्देश हो, कुञ्जी ब्लकको खोल्ने ट्यागमा विशेषता होइन, र त्यो ट्यागमा आर्गुमेन्ट थप्नु त्रुटि हो, दिशा परिवर्तन होइन। स्थान पनि महत्त्वपूर्ण छ: निर्देश आफू सम्बद्ध ब्लकको बाहिर हुन्छ, त्यसैले ब्लकभित्र लेखिएको मान कुञ्जी सामग्रीका रूपमा पढिन्छ। प्रोफाइलको वितरकले चाहेको व्यवस्था प्रतिलिपि गर्नुहोस्, जोडी बनाउने प्रयास नगर्नुहोस्, किनकि एउटा सर्भरविरुद्ध चल्ने प्रोफाइल सायद अर्को छेउमा पहिले नै प्रतिबिम्बित भइसकेको हुन सक्छ।
विकल्पले के अछुतो राख्छ
यसले अनुप्रयोग ट्राफिक इन्क्रिप्ट गर्दैन। tls-auth ले नियन्त्रण च्यानलका प्याकेटवरिपरि HMAC राख्छ, जबकि डेटा च्यानल ह्यान्डशेकमा वार्ता गरिएका सत्र कुञ्जीहरूले सुरक्षित रहन्छ, त्यसैले थ्रुपुट वा साइफरको प्रश्नको दिशा-संख्यासँग कुनै सम्बन्ध छैन। सेटिङले दोस्रो इन्क्रिप्शन तह पनि थप्दैन, र यही अनुमानले मानिसहरूलाई लामो कुञ्जी खोज्न पठाउँछ।
यो tls-crypt मा लागू हुँदैन, आफ्नै विकल्प र कुञ्जी-व्यवस्थापन भएको अर्को नियन्त्रण च्यानल संयन्त्र, र कुनै पनि सहकर्मीको प्रमाणपत्र पहिचानबारे केही भन्दैन। त्यसैले काम गर्ने दिशा-मिलानले दुवै छेउ नियन्त्रण च्यानल कसरी प्रमाणित गर्ने भन्नेमा सहमत छन् भन्ने मात्र प्रमाणित गर्छ, विश्वास-शृंखला प्रमाणित भयो भन्ने होइन।
जोडी मिलाउनुहोस्, त्यसपछि फेरि जोड्नुहोस्
कुनै पनि परिवर्तन गर्नुअघि दुवै कन्फिगरेसनको तुलना गर्नुहोस्, किनकि पहिले नै सही भएको पक्ष सम्पादन गर्दा काम दोब्बर हुन्छ। तलको grep ले प्रत्येक फाइलले कुन संयन्त्र छान्छ देखाउँछ; विस्तृत रनले नियन्त्रण च्यानल प्रमाणित भयो कि भएन देखाउँछ। दुवै आउटपुट राख्नुहोस्, ताकि अर्को परिवर्तन ज्ञात अवस्थासँग तुलना गर्न सकियोस्।
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
कुनै पनि परिवर्तनपछि दुवै सहकर्मी फेरि सुरु गर्नुहोस्, किनकि यी विकल्पहरू सुरुमा एक पटक पढिन्छन् र एउटा पक्ष फेरि लोड गर्दा पुरानो सत्रको सम्पूर्ण आयुभर जोडी असंगत रहन्छ। यदि तैनाथी अहिले दिशा कन्फिगर नगरी चलिरहेको छ भने, एउटा सहकर्मीमा सेटिङ थप्दा तपाईंले सुरु गरेको असफलता फेरि उत्पन्न हुन्छ; कि दुवैलाई रहन दिनुहोस् कि दुवैलाई कन्फिगर गर्नुहोस्। एक पटकमा एउटा छेउ बदल्नुहोस् र अघिल्लो फाइल राख्नुहोस्, ताकि रिग्रेसन पुनर्निर्माण होइन, दुई मिनेटको फर्काउने काम होस्।
प्रत्येक छेउका लागि संयन्त्र, कुञ्जी फाइल र दिशा तैनाथी टिप्पणीमा लेख्नुहोस्, नत्र अर्को व्यक्तिले दुई समान फाइल पढेर संख्याहरू एकअर्कासँग मिल्नुपर्छ भन्ने ठान्नेछ। दिशा समन्वयको विवरण हो, सुरक्षा सुधार होइन: यसले नियन्त्रण च्यानलका दुई दिशा छुट्याउँछ र अरू केही गर्दैन।