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 विपरीत प्रमाणित नहुँदासम्म अवस्थाको समस्या हो। डेमन सफा गर्नु रिबुटभन्दा छिटो छ, र रिबुटले फाल्ने ती लग प्रमाणहरू यसले जोगाउँछ।