IKEv2 सर्व्हर पत्ता वि ओळख: क्लायंट प्रत्यक्षात काय तपासतो

पत्ता बदलणारा गेटवे नवीन प्रमाणपत्रामागील तोच गेटवे थांबत असताना काम करत राहू शकतो आणि उलटही घडते। पत्ता क्लायंटला पॅकेट कुठे पाठवायचा ते सांगतो; प्रमाणित ओळख क्लायंटला सांगते की समवयस्क उत्तर देणाऱ्यावर विश्वास ठेवायला हवा। IKEv2 त्यांना दोन स्वतंत्र फील्ड म्हणून ठेवते, जे एकदा तुम्ही त्यांना एक स्ट्रिंग म्हणून हाताळणे थांबवल्यास उपयुक्त ठरते। ते वेगवेगळ्या ठिकाणी कॉन्फिगर देखील केले आहेत, त्यामुळे एक बरोबर असू शकते तर दुसरा चुकीचा आहे।

त्यांना या क्रमाने तपासा आणि पहिल्या न जुळण्यावर थांबा, कारण नंतरच्या तपासण्या आधीचे पास झाले असे गृहीत धरतात।

प्रथम, कोणते मूल्य पत्ता आहे

कनेक्शन पत्ता हा क्लायंट डायल करत असलेला कोणताही असतो: एक IP, DNS नाव जे एकावर निराकरण करते किंवा लोड-संतुलित फ्रंट एंड। ही वाहतूक माहिती आहे आणि आणखी काही नाही। ओळख IKEv2 आयडी पेलोडमध्ये असते आणि नंतर ती पीअरच्या प्रमाणपत्राशी जुळते। ॲड्रेस बॉक्समधील DNS नाव अपेक्षित ओळख बनत नाही, आणि कच्चा IP ओळख बनत नाही कारण फक्त सॉकेट त्याला जोडलेले आहे।

strongSwan अटींमध्ये, पत्ता right किंवा left आहे, आणि अपेक्षित ओळख rightid किंवा leftid आहे, आणि IKEv2 कॉन्फिगरेशन दस्तऐवजीकरण हेच वर्णन करते। जर तुम्ही फक्त पत्ता संपादित केला असेल, तर तुम्ही अर्धा जोड कॉन्फिगर केला आहे।

दुसरे, प्रमाणपत्र काय सिद्ध करू शकते

ओळखीचा एक प्रकार आहे आणि प्रमाणपत्राला जुळणारे नाव असणे आवश्यक आहे। विषय पर्यायी नाव विस्तारामध्ये dNSName एंट्रीद्वारे DNS ओळख समाधानी आहे; IP ओळखीसाठी iPAddress एंट्री आवश्यक आहे। vpn.example.com साठी जारी केलेले प्रमाणपत्र शाब्दिक पत्त्याबद्दल काहीही सिद्ध करत नाही 203.0.113.10, आणि त्या पत्त्यासाठी जारी केलेले प्रमाणपत्र नावाबद्दल काहीही सिद्ध करत नाही। एकच की आणि CA पुन्हा वापरत असतानाही, वेगळ्या नावासाठी पुन्हा जारी करणे ही ड्रॉप-इन बदली नाही।

आधुनिक क्लायंट जेव्हा विषयाचे पर्यायी नाव अस्तित्वात असते तेव्हा सामान्य नावाकडे दुर्लक्ष करतात आणि बरेच जण त्याकडे पूर्णपणे दुर्लक्ष करतात। जर SAN सूचीमध्ये क्लायंट तपासत असलेले मूल्य नसेल, प्रमाणपत्र आधीपासून विश्वासार्ह म्हणून स्वीकारले गेल्यावर हँडशेक अयशस्वी होतो, म्हणूनच लॉग विश्वासार्ह त्रुटीऐवजी ओळख त्रुटीसारखे वाचतो।

तिसरे, प्रत्येक क्लायंट अपेक्षा कशी व्यक्त करतो

Windows तुम्ही टाइप केलेले सर्व्हरचे नाव किंवा पत्ता घेते आणि त्याच्याशी जुळण्यासाठी प्रमाणपत्र आवश्यक आहे, म्हणून IP टाइप केल्याने IP अपेक्षा निर्माण होते। Androidचा IKEv2 क्लायंट तशाच प्रकारे वागतो आणि दोघेही भिन्न होस्टचे नाव देणारे वैध, सार्वजनिकरित्या विश्वासार्ह प्रमाणपत्र नाकारतात। प्रोफाइल अयशस्वी होणे सुरू होऊ शकते कारण कोणीतरी स्थलांतर करताना होस्टनाव त्याच्या पत्त्यासह बदलले आहे। प्रमाणपत्रात काय समाविष्ट आहे हे पाहण्यापूर्वी क्लायंटने काय मागितले ते पहा।

strongSwan वर अपेक्षा स्पष्ट आहे: सर्व्हरने प्रत्यक्षात सादर केलेल्या ओळखीनुसार rightid सेट करा, जी उजवीकडून वेगळी असू शकते। ते %any वर सेट केल्याने पीअर जे काही ऑफर करतो ते स्वीकारतो आणि तुम्ही ठेवण्याचा प्रयत्न करत असलेला चेक काढून टाकतो।

चौथे, सरदार ओळखीपासून वेगळे वापरकर्ता लॉगिन

EAP प्रमाणीकरण आणि सर्व्हर ओळख वेगवेगळ्या प्रश्नांची उत्तरे देतात। एक EAP ओळख जसे की [email protected] वापरकर्ता कोण आहे हे सांगते, क्लायंटने सर्व्हर योग्य असल्याचे ठरवल्यानंतर। तो पासवर्ड फिरवल्याने समवयस्क ओळख जुळत नाही, कारण कनेक्शन कधीही वापरकर्ता-लॉगिन टप्प्यापर्यंत पोहोचत नाही।

निर्जंतुकीकरण केलेल्या अहवालात दोन्ही नावे असावीत: क्लायंटला अपेक्षित असलेली ओळख, सर्व्हरने सादर केलेली ओळख आणि प्रमाणपत्राच्या SAN नोंदी।

पाचवे, सत्यापित चॅनेलद्वारे ते बदला

जेव्हा गेटवे कायदेशीररित्या हलतो, तेव्हा प्रथम पत्ता अद्यतनित करा आणि ओळख सोडा, कारण हे प्रकरण IKEv2 चांगले हाताळते। जेव्हा ओळख स्वतःच बदलते, तेव्हा ती एक ट्रस्ट इव्हेंट म्हणून हाताळा आणि तुमचा आधीपासून विश्वास असलेल्या स्त्रोताकडून नवीन मूल्य मिळवा, सध्या अयशस्वी होत असलेल्या एंडपॉईंटवरून नाही। तुम्ही प्रमाणित करण्याचा प्रयत्न करत असलेल्या कनेक्शनवर वितरित केलेला संदेश त्या कनेक्शनचा पुरावा नाही।

प्रोफाइल नोट्समध्ये अंतिम पत्ता, ओळख आणि SAN यादी एकत्र रेकॉर्ड करा। प्रमाणपत्राला स्पर्श करणारी पुढील व्यक्ती नंतर तिघांपैकी कोणाला हलवण्याची परवानगी आहे हे पाहील।