Mac चा VPN एकदा जोडतो, नंतर वेळ संपते: IKE डीमन साफ करा

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

macOS वर ती गोष्ट सहसा IKE डीमन असते।

नमुना: एकदा कनेक्शन, नंतर वेळ संपणे

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

हे एकही लॉग उघडण्यापूर्वी तपासणीची व्याप्ती कमी करते। प्रश्न असा होतो की कोणती प्रक्रिया IKE पोर्टची मालक आहे आणि ती स्वतःला काय करत आहे असे वाटते।

दोन डीमन, एक पोर्ट

सिस्टम चालवते racoon जेव्हा कनेक्शन IKE आवृत्ती 1 बोलते। सध्याच्या आवृत्त्या देखील आणतात iked IKEv2 आणि नवीन IPsec स्टॅकसाठी। दोन्ही UDP 500 आणि UDP 4500 धरू शकतात, आणि पासवर्ड प्रॉम्प्टवर कनेक्शनचा प्रयत्न रद्द झाल्यास किंवा नेटवर्क बदलामुळे व्यत्यय आल्यास दोन्ही अर्धवट उघडे सुरक्षा असोसिएशन ठेवू शकतात।

असे झाल्यास, पुढचा प्रयत्न स्वच्छ सुरू होत नाही। जुने असोसिएशन अजूनही पीअरची स्थिती व्यापत असताना तो वाटाघाटी करण्याचा प्रयत्न करतो, आणि स्पष्ट त्रुटीने अयशस्वी होण्याऐवजी देवाणघेवाण थांबते। वापरकर्त्याला फिरणारे चिन्ह दिसते, नंतर वेळ संपतो।

काहीही मारण्यापूर्वी मालक शोधा, कारण उत्तर कोणती सेवा पुन्हा सुरू करावी आणि पुढे कोणता लॉग वाचावा हे ठरवते।

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

आउटपुट दोन तथ्ये म्हणून वाचा: कोणती प्रक्रिया पोर्ट धरून आहे, आणि त्यातील एकापेक्षा जास्त आहेत का। एकाच सॉकेटसाठी स्पर्धा करणारे दोन IKE डीमन अस्थिर सर्व्हरसारखे दिसणाऱ्या बऱ्याच अधूनमधून वर्तनाचे स्पष्टीकरण देतात।

प्रक्रिया नाही, काम पुन्हा सुरू करा

जुन्या सिस्टमवर प्रक्रिया मारून पुढच्या कनेक्शनला ती पुन्हा सुरू करू देणे पुरेसे आहे। सध्याच्या आवृत्त्यांमध्ये डीमन launchd द्वारे व्यवस्थापित होते, आणि फक्त प्रक्रियेला सिग्नल दिल्यास काम अशा स्थितीत राहू शकते जिथे ते चालू नाही आणि सुरू होण्यासाठी नियोजितही नाही। त्याऐवजी काम थांबवा आणि सुरू करा।

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

launchd कडे कामाची नोंद नसल्यास, नावाने प्रक्रिया मारल्याने पुढच्या प्रयत्नात नवीन वाटाघाटी तरीही सक्तीची होते। चाचणी दोन्ही बाबतीत सारखीच आहे: पुन्हा कनेक्ट करण्याचा प्रयत्न करताना कोणतीही प्रक्रिया पोर्ट धरून नसावी। त्याच आदेशाने त्याची पुष्टी करा lsof रीबूटने काम केले असे गृहीत धरण्याऐवजी।

नंतर एकदा कनेक्ट करा आणि क्लायंट लॉग सुरुवातीपासून वाचा। जी वाटाघाटी टप्पा 1 पार करते आणि नंतर ट्रान्समिट अपयश नोंदवते ती स्थानिक सॉकेट समस्या पुन्हा करत आहे; पीअरने नाकारलेली वाटाघाटी पूर्णपणे वेगळे तिकीट आहे।

जेव्हा सर्व्हरच नाकारत असतो

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

स्प्लिट टनल धोरण उलट दिशेने तोच आकार तयार करते। सर्व रहदारी टनलमध्ये मागणारा सर्व्हर स्प्लिट टनलसाठी संरचित क्लायंटला वाटाघाटीदरम्यान वगळेल, आणि क्लायंट धोरण नाकारण्याऐवजी वेळ संपल्याचे नोंदवेल। सर्व काही टनलमधून पाठवण्यासाठी प्रोफाइल बदलल्यास ते कनेक्ट होऊ शकते, पण तो नेटवर्क मालकासोबत घ्यायचा धोरण निर्णय आहे, गुपचूप लागू करायची दुरुस्ती नाही।

क्लायंट पुन्हा बदलण्यापूर्वी पीअरचा लॉग वाचा। नाकारणे, धोरण विसंगती आणि शांत वगळणे ही तीन वेगळी कारणे आहेत जी Mac च्या स्क्रीनवर सर्व “कनेक्ट होत आहे” अशी दिसतात।

जुने क्लायंट आणि 64-बिट कर्नेल

जुना Cisco IPSec क्लायंट 32-बिट आणि PowerPC सिस्टमसाठी बनवलेले कर्नेल एक्स्टेंशन लोड करतो। 64-बिट कर्नेलमध्ये बूट झालेल्या Mac वर ते एक्स्टेंशन लोड होऊ शकत नाही, आणि क्लायंट त्रुटी 51 ने लवकर अयशस्वी होतो कारण तो VPN उपप्रणालीपर्यंत अजिबात पोहोचत नाही। चुकीच्या आर्किटेक्चरचे कर्नेल एक्स्टेंशन कितीही डीमन रीस्टार्ट केल्याने सुधारत नाही।

एक्स्टेंशन पुन्हा लोड केल्यास काही काळ काम करू शकते आणि नंतर पुढच्या बूटवर पुन्हा अयशस्वी होऊ शकते। टिकाऊ उत्तरे म्हणजे जिथे अजून आधार आहे तिथे जुने कर्नेल चालवणे, किंवा सिस्टमसोबत येणाऱ्या अंगभूत क्लायंटकडे जाणे। जे लोड होऊ शकत नाही अशा तृतीय-पक्षीय क्लायंटवर संध्याकाळ घालवण्यापूर्वी आर्किटेक्चर तपासा।

• एकदा पुनरुत्पादन करा, नंतर प्रोफाइलला हात लावण्यापूर्वी कोणता डीमन UDP 500 धरून आहे ते तपासा।
• टप्पा 1 नंतरचे पहिले अपयश वाचा: ट्रान्समिट त्रुटी स्थानिक सॉकेटकडे निर्देश करते।
• फक्त प्रक्रिया नाही, launchd काम पुन्हा सुरू करा आणि पोर्ट मोकळा असल्याची पुष्टी करा।
• सर्व्हर-बाजूची पुनर्प्रमाणीकरण विंडो क्लायंट बिघाडापासून वेगळी करण्यासाठी दुसरे खाते वापरून पहा।
• क्लायंटला दोष देण्यापूर्वी कर्नेल आर्किटेक्चर नोंदवा।

नेमके एकदाच काम करणारा VPN उलट सिद्ध होईपर्यंत स्थितीची समस्या आहे। डीमन साफ करणे रीबूटपेक्षा वेगवान आहे, आणि रीबूट टाकून देईल ते लॉग पुरावे ते जतन करते।