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 आणि ओळख नकाशाला स्वतंत्र नियंत्रणे म्हणून नोंदवते।
दोन मशीनवर एकच ओळख
दुसऱ्या लॅपटॉपवर प्रत केलेली प्रोफाइल तेच प्रमाणपत्र आणि तेच सामान्य नाव घेऊन जाते। सर्व्हरच्या सेटिंग्जनुसार नवीन जोडणी जुन्याची जागा घेऊ शकते, आणि मालकी धारण करणारी प्रत संलग्नता तपासणी जिंकते।
यामुळे बिघाड अधूनमधून दिसतो आणि दोन्ही उपकरणे जागी असतानाच प्रकट होतो।
दुहेरी सामान्य नावांना परवानगी दिल्याने दोन्ही जोडले जाऊ शकतात, पण त्यांना स्वतंत्र स्थिर पत्ते किंवा स्वतंत्र मालकी मिळत नाही। दोन उपकरणांनी एकत्र राहायचे असेल, तर प्रत्येकाची स्वतःची ओळख आणि स्वतःचे वाटप असेल यासाठी त्यांना वेगवेगळे नोंदवा। दुहेरी सेटिंगला या इशाऱ्याचा दुरुस्ती मानल्यास कोडे जागचे राहते आणि दुसरे जोडले जाते।
संलग्नता बदलली हे सिद्ध करा
दुरुस्ती संरचनेच्या मालकामार्फत लागू करा, मग नवीन धोरण लोड होण्यासाठी बाधित क्लायंट पुन्हा जोडा।
तोच प्रवाह पुन्हा करा आणि तीन गोष्टींची खात्री करा: पॅकेटचा अंतर्गत स्रोत, सर्व्हर ज्या क्लायंट प्रतीशी तो जोडतो, आणि नंतर गंतव्यस्थानाचे वर्तन।
इशारा थांबला पण अनुप्रयोग अजूनही अपयशी ठरत असेल, तर समस्या नाहीशी झाली नाही तर सरकली आहे। फॉरवर्डिंग, फायरवॉल नियम आणि परतीचा मार्ग वेगवेगळे टप्पे आहेत, आणि संलग्नता तपासणी पार करणे म्हणजे पॅकेटला टनेल सोडण्याची परवानगी मिळाली एवढेच।