iOS ने तुमचा strongSwan बोगदा नाकारला: IKE प्रस्तावांची तुलना करा

प्रमाणपत्रात किंवा पत्त्यात काहीच स्पष्ट करत नाही की गेल्या वर्षी strongSwan ला जोडलेला iPhone या वर्षी का अयशस्वी होतो. पत्ता, आधीच सामायिक केलेली किल्ली किंवा क्लायंटची ओळख यात काहीही बदलण्याची गरज नव्हती. जे सरकले ते म्हणजे फोनच्या अंगभूत क्लायंटला बोलणी करायला तयार असलेल्या रूपांतरणांची यादी, आणि ती यादी सर्व्हरच्या यादीशी जुळणे थांबवताच, कोणाचीही ओळख तपासण्यापूर्वीच देवघेव संपते.

निर्णय देणारी लॉग ओळ

त्या कनेक्शनसाठी लॉगिंग वाढवा आणि निकाल ठरवणाऱ्या दोन नोंदी शोधा: फोनने काय सुचवले आणि सर्व्हरने काय निवडले. लॉग निवडलेल्या प्रस्तावाशिवाय संपला आणि काहीच जुळले नाही असे नोंदवले, तर प्रमाणीकरणाचा प्रयत्नच झाला नाही. नवे प्रमाणपत्र आणि नवा पासवर्ड त्या टप्प्यावर काहीही बदलत नाहीत, कारण दोन्ही पुढच्या टप्प्यात वापरले जातात. ओळख तपासण्यापूर्वी ठरलेल्या निकालावर दोन्हीपैकी कोणीही परिणाम करू शकत नाही.

काहीही संपादित करण्यापूर्वी अयशस्वीतेचे दोन प्रकार वेगळे ठेवा. रूपांतरणांत केलेले कोणतेही संपादन नाकारलेली ओळखपत्रे वाचवत नाही, आणि ओळखपत्रांतील कोणतीही दुरुस्ती नाकारलेले रूपांतरण वाचवत नाही. निवडलेल्या प्रस्तावाचे नाव सांगणारी लॉग नोंद तुम्ही दोनपैकी कोणत्या स्थितीत आहात ते सांगते. ती नोंद नसेल, तर तुम्ही अंदाज करत आहात.

निवडलेली ओळ प्रस्तावाचे नाव मैत्रीपूर्ण लेबलऐवजी त्याच्या रूपांतरण-संचाने घेते. एन्क्रिप्शन, अखंडता आणि गट फील्डची तुलना करा त्या ओळीत फोनने पाठवलेल्या यादीशी, कारण कोणत्याही एका फील्डमधील फरक हारायला पुरतो.

फोनवर काय बदलले

iOS च्या एका आवृत्तीने आपल्या क्लायंटला वापरायला तयार असलेले अल्गोरिदम कमी केले. कमकुवत अखंडता हॅश, लहान Diffie-Hellman गट आणि जुने पर्याय आधी मांडणारे प्रस्ताव यापुढे स्वीकारार्ह नाहीत.

इथे लांब याद्या अधिक सुरक्षित नाहीत. निवड फोनच्या स्वीकारलेल्या संचावर आणि त्याच्या स्वतःच्या प्राधान्यक्रमावर चालते, त्यामुळे विस्तृत कॅटलॉग जाहीर करणारा सर्व्हरही आधुनिक नोंदी निवडल्या न गेल्यास बोलणीत हरू शकतो. आधुनिक नोंदी पुढे असलेली छोटी यादी पसंत करा. जुन्या पर्यायांनी सुरू होणारी लांब यादी तुम्ही टाळू पाहत असलेल्या अयशस्वीतेलाच आमंत्रण देते. स्वीकारलेला संच हा बाहेरचा निर्बंध आहे जो क्लायंट अद्ययावत होताच सरकतो, त्यामुळे काल काम करणारे संरचना कालबद्दलचा पुरावा आहे.

अजूनही बोलणी करणारी एक जोडी

आजच्या फोनसाठी एक आधुनिक संयोजन पुरते. बोलणी करणारी एक जोडी अशी दिसते:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

ike ओळ किल्लीची देवघेव चालू असताना वापरले जाणारे एन्क्रिप्शन, अखंडता आणि Diffie-Hellman गट वाहते. esp ओळ फक्त डेटा वाहिनी व्यापते, कारण गट ती लागू होण्यापूर्वीच ठरला होता. कनेक्शन पुन्हा लोड करा किंवा डीमन पुन्हा सुरू करा, नंतर फोन पुन्हा जोडा. तो गट मूल्य तुम्ही सेवा देता त्या प्रत्येक क्लायंटला अजूनही ते स्वीकारत असेल तरच ठेवा, आणि एका जुन्या सहकाऱ्याला अधिक हवे म्हणून सर्वांसाठी प्रस्ताव रुंदावू नका.

दुरुस्तीची तीन ठिकाणे, एक सहसा बंद असते

• प्रत्येक सहकाऱ्यासाठी एक आधुनिक प्रस्ताव. सर्व क्लायंट आजचे फोन आणि डेस्कटॉप असतील तर बरोबर. जुन्या रूपांतरणांच्या भोवती बोलणी करण्याऐवजी ती पुसून टाकते.
• Apple क्लायंटसाठी दुसरी कनेक्शन व्याख्या. एका जुन्या सहकाऱ्याला जिवंत ठेवते आणि फोनला तो स्वीकारेल असा प्रस्ताव देते. यासाठी अजून एक कनेक्शन ब्लॉक लागतो आणि अपवाद दृश्य होतो.
• क्लायंट बदलणे. तुम्हाला क्वचितच उघडे असते: व्यवस्थापन प्रणाली किंवा अॅप प्रोफाइल पुरवत असेल, तर स्पर्श करण्यासारखा प्रस्ताव-संपादक नसतो, आणि अंगभूत क्लायंट असा कोणताही दाखवत नाही.

तुमच्या नियंत्रणाबाहेरील उपकरण अद्ययावत करता येत नसेल तर दुसरा पर्याय निवडा. जुना सहकारी निवृत्त करता येत असेल आणि एकच धोरण बाळगणे पसंत असेल तर पहिला निवडा.

कोणत्याही प्रकारे, निवड संरचनेत दिसते, आणि तोच मुद्दा आहे. जुन्या रूपांतरणापर्यंत खाली बोलणी करणारा शांत फॉलबॅक स्पष्ट ब्लॉकपेक्षा वाईट आहे, कारण कोणताही आढावा तो कधीच पुढे आणणार नाही.

ते सिद्ध करा, नंतर नोंदवा

पुन्हा जोडा आणि सर्व्हरवर तीन स्वतंत्र तथ्ये तपासा: प्रस्ताव निवडला गेला, कनेक्शन स्थापित दिसते, आणि क्लायंटला पत्ता मिळाला. दूरच्या पत्त्याशिवाय स्थापित हस्तांदोलन पूल किंवा रहदारी निवडकांकडे इशारा करते, आणि ते स्वतंत्र बदलात मोडते. दोन्ही एकत्र घेतल्यास सुटलेली बोलणी न सुटलेली दिसते.

स्वीकारलेला रूपांतरण-संच, तो कधी बदलला आणि कोणते क्लायंट बिल्ड तपासले ते नोंदवा. पुढील अद्ययावत आवश्यकता पुन्हा सरकवू शकते, आणि जी मूल्ये चालली ती नव्यांच्या शेजारी तुम्हाला पहिल्यांदा हवी असतात.