OpenVPN पैकेट HMAC प्रमाणीकरण विफल: कौन-सी परत?

दो विफलताएँ एक ही शब्दावली में बताई जाती हैं और उनमें लगभग कुछ भी साझा नहीं है। एक वह पैकेट है जिसका प्रमाणीकरण टैग सत्यापित नहीं हुआ; दूसरा वह व्यक्ति है जिसके क्रेडेंशियल अस्वीकार किए गए। पहले को दूसरा मानकर आप ऐसे पासवर्ड की तलाश में जाते हैं जो कभी समस्या नहीं था।

संदेश एक परत का नाम लेता है, और उपयोगी काम यह तय करना है कि कौन-सी, किसी भी सामग्री को बदलने से पहले। उम्मीदवारों की साथ-साथ तुलना करना अंतर देखने का सबसे तेज़ तरीका है।

एक शब्द साझा करने वाली दो विफलताएँ

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

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

तुलना करें कि चल रही प्रक्रिया ने वास्तव में क्या लोड किया

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

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

नियंत्रण चैनल की डेटा चैनल से तुलना करें

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

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

सुधार की तुलना उस गुण से करें जिसे आप छोड़ते हैं

पैकेट प्रमाणीकरण बंद करने से चेतावनी शांत हो जाती है और वह जाँच हट जाती है जिसने बेमेल पाया था, जो प्रोफ़ाइल ठीक करने के बराबर नहीं है। पूछें कि आप कौन-सा गुण छोड़ रहे हैं और क्या डिज़ाइन उसके बिना टिकता है।

कुछ भी बदलने से पहले दोनों सिरों पर पहली प्रासंगिक घटना पढ़ें, फिर केवल वही बेमेल बदलें जिसका वह नाम लेती है।

अगर अगला प्रयास प्रमाणपत्र या लॉगिन त्रुटि तक पहुँचता है, तो वह प्रगति है, गिरावट नहीं: पैकेट परत अब सहमत है और कनेक्शन आगे बढ़ गया है। जिन सेटिंग्स ने बदलाव किया उन्हें दर्ज करें, ताकि अगला व्यक्ति पहेली के बजाय व्याख्या विरासत में पाए।