OpenVPN नियंत्रण पैकेट का पता लगाना: TLS से पहले tls-auth

tls-auth विफलता को आम तौर पर हैंडशेक समस्या बताया जाता है, जबकि वह कभी ऐसी थी ही नहीं। किसी भी TLS प्रसंस्करण से पहले नियंत्रण पैकेट पर HMAC जाँचा जाता है, इसलिए बेमेल कुंजी या दिशा ऐसी विफलता देती है जो प्रमाणपत्र समस्या जैसी दिखती है और दो परत पहले तय हो जाती है। लिफ़ाफ़े को अलग वस्तु मानने से निदान छोटा हो जाता है: फ़ील्ड पढ़ें, पुष्टि करें कि जाँच जल्दी चलती है, और फिर उन तीन चीज़ों की तुलना करें जिन पर दोनों सिरे सहमत होने चाहिए।

लिफ़ाफ़े को उसी क्रम में पढ़ें जिसमें वह बनता है

नियंत्रण पैकेट में सत्र पहचानकर्ता, वैकल्पिक tls-auth HMAC, पुनरावृत्ति और पावती जानकारी, और एक विश्वसनीय संदेश पहचानकर्ता होता है, और उसके बाद संदेश प्रकार का पेलोड आता है। जब संदेश हैंडशेक संदेश होता है, तब पेलोड TLS सिफ़रटेक्स्ट होता है। पूरा संबंध यही है: TLS सामग्री ऐसे संदेश के भीतर यात्रा करती है जिसे लिफ़ाफ़ा पहले से सुरक्षित रखता है। देखें OpenVPN नेटवर्क प्रोटोकॉल संदर्भ जो नियंत्रण चैनल के फ़ील्ड उसी क्रम में सूचीबद्ध करता है।

विश्वसनीयता परत को क्रिप्टोग्राफ़ी समझ लेना आसान है। पावतियाँ, पुनःप्रेषण और संदेश पहचानकर्ता इसलिए हैं कि नियंत्रण संदेश अविश्वसनीय परिवहन पर एक बार और क्रम में पहुँचें। वे प्रमाणीकरण नहीं हैं, और सही संदेश पहचानकर्ता इस बारे में कुछ सिद्ध नहीं करता कि पैकेट किसने भेजा।

इस समूहीकरण को वैचारिक रखें। यह बाइट-क्रम आरेख नहीं है, और टैग गणना के लिए पर्याप्त नहीं है, क्योंकि HMAC में जाने वाले फ़ील्ड कार्यान्वयन, संस्करण और मोड पर निर्भर करते हैं।

दिखाएँ कि जाँच हैंडशेक से पहले चलती है

जिसके पास साझा कुंजी है वह HMAC सत्यापित कर सकता है और नकली पैकेट तुरंत गिरा सकता है, बिना हैंडशेक स्थिति आवंटित किए या सार्वजनिक कुंजी का काम किए। सुरक्षा शुरुआती हैंडशेक पैकेटों को भी ढकती है, और ठीक इसी कारण गलत कुंजी देर से आने वाली प्रमाणीकरण त्रुटि के बजाय विफल कनेक्शन के रूप में दिखती है।

डेमन की वर्बोसिटी बढ़ाएँ और tun डिवाइस के बजाय नियंत्रण चैनल देखें:

openvpn --config /etc/openvpn/server.conf --verb 6

आप जो खोज रहे हैं वह पैकेट स्तर पर रिपोर्ट होने वाली नियंत्रण-चैनल HMAC सत्यापन विफलता है, किसी भी TLS चेतावनी से पहले। लॉग में TLS चेतावनी का अर्थ है कि लिफ़ाफ़ा स्वीकार हो गया और विफलता अंदर की ओर चली गई, जो अलग उपाय वाली अलग जाँच है।

दिशा-प्रबंधन भी यहीं है। जब स्थैतिक कुंजी फ़ाइल tls-auth के साथ उपयोग होती है, तो दोनों सिरे विपरीत कुंजी दिशाएँ लेते हैं, और प्रोटोकॉल उस विभाजन का उपयोग करता है ताकि पकड़ा गया पैकेट उसके भेजने वाले की ओर वापस परावर्तित न हो सके। दिशा उलटने से कुंजी समान रहती है और फिर भी हर पैकेट विफल होता है। एक बार में एक सिरा बदलें, फिर दोनों डेमन पुनः आरंभ करें ताकि जोड़ी साथ लोड हो।

दोनों सिरों पर कुंजी, दिशा और digest मिलाएँ

तीन मान सहमत होने चाहिए और उनमें से केवल एक फ़ाइल है। स्थैतिक कुंजी की सामग्री दोनों सिरों पर समान होनी चाहिए, दिशा विपरीत होनी चाहिए, और HMAC के लिए उपयोग किया गया digest मेल खाना चाहिए। कुंजी सामग्री छूने से पहले कॉन्फ़िगरेशन जाँचें, क्योंकि एक उलटी दिशा भ्रष्ट फ़ाइल से अधिक विफलताएँ समझाती है:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

साझा रहस्य एडिटर के बजाय उपकरण से बनाएँ, और अनुमतियाँ कड़ी रखें:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

पुराने संस्करण कुंजी निर्माण के लिए थोड़ा अलग विकल्प क्रम स्वीकार करते थे, और उन संस्करणों के लिए लिखी प्रोफ़ाइल अभी भी प्रचलन में हैं। बनी फ़ाइल दोनों स्थितियों में एक ही प्रकार की वस्तु है, इसलिए जाँच यह है कि दोनों सिरों के बाइट समान हैं या नहीं, न कि किस वर्तनी ने उन्हें बनाया।

tls-auth को tls-crypt से न मिलाएँ। दोनों नियंत्रण चैनल की रक्षा करते हैं, लेकिन tls-crypt उसे एन्क्रिप्ट भी करता है और पर्यवेक्षकों से हैंडशेक छिपाता है, और वह दिशा-विभाजन को अपने कुंजी-प्रबंधन से बदल देता है। एक का उपयोग करने वाली प्रोफ़ाइल दूसरे के लिए कॉन्फ़िगर किए गए साथी के साथ काम नहीं करेगी, और कोई digest ट्यूनिंग वह अंतराल बंद नहीं करती।

टैग केवल वास्तविक प्रारूप से पुनः उत्पन्न करें

बाइट-सटीक पुनरुत्पादन VPN चलाने से अलग कार्य है, और यह केवल वास्तविक इनपुट के साथ काम करता है: वह कार्यान्वयन और संस्करण जिसने पैकेट बनाया, चुना गया digest, दिशा, और सत्र पहचानकर्ता व पावती सरणी सहित वास्तविक बाइट। फ़ील्ड सूची का पाठ्य निरूपण वे बाइट नहीं हैं।

टैग की लंबाई digest से आती है, इसलिए स्थिर लंबाई की धारणा उसी क्षण टूट जाती है जब कोई उसे बदल देता है। पैकेट को उसी तरह हैश करें जैसे कार्यान्वयन करता है, ब्लॉग पोस्ट की तालिका जैसे प्रस्तुत करती है वैसे नहीं, और हाथ से निकाले गए अनुमान के बजाय उसी साथी से लिए गए कैप्चर से तुलना करें।

इस अभ्यास को उत्पादन प्रोफ़ाइल से दूर रखें। टैग पुनः उत्पन्न करने में ऐसा कुछ नहीं है जो बताए कि किसी तैनाती को सुरक्षा सक्षम करनी चाहिए या नहीं।

सुरक्षा हटाए बिना बेमेल वापस लें

लुभावना परीक्षण यह है कि tls-auth हटा दें, कनेक्शन सफल होते देखें और निष्कर्ष निकालें कि कुंजी गलत थी। वह उत्तर आपको सुरक्षा का मूल्य चुकाता है और यह नहीं सिखाता कि तीन में से कौन-सा मान बेमेल था। इसके बजाय सर्वर पक्ष से स्वीकृत मिलान वाला कॉन्फ़िगरेशन लें और उससे तुलना करें।

परिवर्तन को उलटा जा सके ऐसे तैयार करें। पिछला सर्वर कॉन्फ़िगरेशन और कुंजी फ़ाइल रखें, सुधारी गई जोड़ी लागू करें, सत्यापित करें कि कोई क्लाइंट हैंडशेक पूरा करता है, और तभी बैकअप हटाएँ। यदि परिवर्तन के बाद क्लाइंट विफल हों, तो रुकावट के दौरान तीसरा प्रकार गढ़ने के बजाय पिछली फ़ाइलें बहाल करें। बहाली एक ऐसा आदेश होना चाहिए जिसे आप शुरू करने से पहले ही जानते हों।

अंत में याद रखें कि पास हुई जाँच का क्या अर्थ है। यह सिद्ध करती है कि साथी के पास साझा कुंजी है, यह नहीं कि उसका प्रमाणपत्र या खाता अधिकृत है, और यह बातचीत किए गए डेटा-चैनल सिफ़र के बारे में कुछ नहीं कहती. अधिकृति और डेटा सुरक्षा बाद में स्थापित होती हैं, इसलिए स्वच्छ लिफ़ाफ़ा जाँच प्रारंभ बिंदु है, फ़ैसला नहीं।