MULTI: क्लाइंट से खराब स्रोत पता: यह किसका पता था?
आंतरिक स्रोत उस क्लाइंट से मेल नहीं खाता जिसने उसे पहुँचाया। इसे टनल आवंटन, क्लाइंट के पीछे के LAN, या डुप्लिकेट पहचान से मिलाएँ।
सर्वर लॉग MULTI: bad source address from client प्रिंट करता है, पैकेट गिरा देता है, और सत्र जुड़ा रहता है। यह संयोजन उन लोगों को उलझाता है जो संदेश को प्रमाणीकरण की विफलता के रूप में पढ़ते हैं। ऐसा नहीं है: क्लाइंट प्रमाणित हो चुका है, और जो पैकेट आया वह एक आंतरिक स्रोत पता लेकर आया था जिसे सर्वर उस क्लाइंट इंस्टेंस से जोड़ नहीं सका। जाँच डिलीवरी से पहले होती है, इसलिए टनल स्वस्थ दिखती है जबकि उससे होकर कुछ भी उपयोगी नहीं गुज़रता।
डिलीवरी से पहले सर्वर क्या तुलना करता है
क्लाइंट से आने वाले हर पैकेट के लिए, यूज़र-स्पेस सर्वर टनल के भीतर के स्रोत पते को देखता है और अपनी आंतरिक रूटिंग स्थिति से पूछता है कि वह पता किस क्लाइंट का है। अगर मालिक कोई दूसरा इंस्टेंस है, या कोई मालिक ही नहीं है, तो पैकेट हटा दिया जाता है और चेतावनी जारी होती है।
टनल इंटरफ़ेस से सामान्य डिलीवरी कभी नहीं होती।
यही क्रम उस विवरण को समझाता है जो लोगों को चौंकाता है: होस्ट फ़ायरवॉल के काउंटर नहीं हिलते, क्योंकि पैकेट कभी फ़ायरवॉल तक पहुँचा ही नहीं। होस्ट पर रिवर्स-पाथ फ़िल्टरिंग बदलने से यहाँ कुछ नहीं बदलता, क्योंकि अस्वीकृति डेमॉन की अपनी एसोसिएशन जाँच में हुई थी। संदेश को स्वामित्व के बारे में एक कथन के रूप में पढ़ें, फिर पता लगाएँ कि तीन में से किस स्थिति ने इसे पैदा किया।
बेमेल आंतरिक पते के तीन स्रोत
क्लाइंट ऐसे पते से भेज रहा हो सकता है जो उसे आवंटित नहीं हुआ, ऐसे नेटवर्क से जिसे किसी ने उसका घोषित नहीं किया, या ऐसी पहचान की नकल से जिसका पहले से मालिक है। तीनों एक ही लॉग पंक्ति बनाते हैं। वे इस बात में अलग हैं कि आपको क्या बदलना है। पते और मौजूदा आवंटन सूची से शुरू करें, और इन दो तथ्यों को मामला चुनने दें।
उन्हें अलग करने के लिए दो तथ्य चाहिए: लॉग में अस्वीकृत पता, और वे आवंटन जिन्हें सर्वर मौजूदा मानता है। दूसरा चालू इंस्टेंस के स्टेटस या प्रबंधन दृश्य से उपलब्ध है, और यही एकमात्र प्राधिकार है जिससे परामर्श करना उचित है, क्योंकि कॉन्फ़िगरेशन फ़ाइल इरादे दर्ज करती है, वर्तमान स्थिति नहीं।
कुछ भी बदलने से पहले दोनों दर्ज करें, फिर वर्गीकृत करें। बाद में लिया गया स्क्रीनशॉट उस स्थिति का रिकॉर्ड नहीं है जिसने चेतावनी पैदा की। टाइमस्टैम्प भी रखें, क्योंकि आवंटन सत्रों के बीच खिसकते हैं।
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
क्लाइंट के पीछे का LAN और iroute
जब कोई साइट क्लाइंट अपना निजी नेटवर्क रूट करता है, तो उस नेटवर्क को क्लाइंट का घोषित करना पड़ता है। iroute प्रविष्टि वाली क्लाइंट-विशिष्ट फ़ाइल यह करती है, और प्रविष्टि उस प्रीफ़िक्स का नाम देती है जिसे क्लाइंट ले जाने का हक़ रखता है।
वही प्रीफ़िक्स टनल की ओर इंगित करने वाला कर्नेल रूट अलग आवश्यकता है, और उसे जोड़ने से डेमॉन के आंतरिक स्वामित्व में कुछ नहीं बदलता।
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0पुष्टि करें कि प्रभावी पहचान फ़ाइल नाम से मेल खाती है, क्योंकि बेमेल का अर्थ है कि फ़ाइल कभी लोड नहीं होती और लक्षण अनुपस्थित प्रविष्टि जैसा ही होता है। चेतावनी शांत करने के लिए चौड़ा iroute न जोड़ें, क्योंकि वह अप्रत्याशित स्रोत को अधिकृत बना देता है और यह नहीं बताता कि क्लाइंट ने उसे क्यों भेजा। OpenVPN 2.6 मैनुअल iroute, duplicate-cn और पहचान मैपिंग को अलग नियंत्रणों के रूप में दर्ज करता है।
दो मशीनों पर एक ही पहचान
दूसरे लैपटॉप पर नकल की गई प्रोफ़ाइल वही प्रमाणपत्र और वही सामान्य नाम लेकर चलती है। सर्वर की सेटिंग्स पर निर्भर करता है कि नया कनेक्शन पुराने को बदल सके, और जो इंस्टेंस स्वामित्व रखता है वही एसोसिएशन जाँच जीतता है।
इससे खराबी रुक-रुक कर दिखती है और केवल तब प्रकट होती है जब दोनों डिवाइस जागे हुए हों।
डुप्लिकेट सामान्य नामों की अनुमति दोनों को जुड़ने देती है, पर उन्हें स्वतंत्र स्थिर पते या स्वतंत्र स्वामित्व नहीं देती। अगर दो डिवाइस को साथ रहना है, तो उन्हें अलग-अलग पंजीकृत करें ताकि हर एक की अपनी पहचान और अपना आवंटन हो। डुप्लिकेट सेटिंग को इस चेतावनी का इलाज मानने से रहस्य अपनी जगह रहता है और दूसरा जुड़ जाता है।
साबित करें कि एसोसिएशन बदली
सुधार को कॉन्फ़िगरेशन के मालिक के माध्यम से लागू करें, फिर नई नीति लोड होने के लिए प्रभावित क्लाइंट को दोबारा जोड़ें।
वही प्रवाह दोहराएँ और तीन बातों की पुष्टि करें: पैकेट का आंतरिक स्रोत, वह क्लाइंट इंस्टेंस जिससे सर्वर उसे जोड़ता है, और उसके बाद गंतव्य का व्यवहार।
अगर चेतावनी रुक जाए पर एप्लिकेशन अब भी विफल हो, तो समस्या हटी नहीं, खिसक गई है। फ़ॉरवर्डिंग, फ़ायरवॉल नियम और वापसी पथ अलग-अलग चरण हैं, और एसोसिएशन जाँच पार करने का अर्थ केवल यह है कि पैकेट को टनल छोड़ने की अनुमति मिली।