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 उलटा साबित होने तक स्थिति की समस्या है। डेमॉन साफ़ करना रीबूट से तेज़ है, और यह वे लॉग सबूत बचाता है जो रीबूट फेंक देता।