दो iPhone पर एक ही IKEv2 पहचान? वे बारी-बारी से जुड़ते हैं
दो डिवाइस पर कॉपी किया गया एक प्रोफ़ाइल गेटवे को दो के बजाय एक peer देता है। peer तालिका को भरते और खाली होते देखें, फिर हर डिवाइस के लिए एक मान जारी करें।
दो फ़ोन, एक प्रोफ़ाइल और एक ऐसा पैटर्न जो तब तक अलौकिक लगता है जब तक कोई गेटवे को न देखे। एक डिवाइस सुरंग रखता है, दूसरा जुड़ता है, और पहला कुछ सेकंड में उसे खो देता है। पहला फिर जुड़ता है और दूसरा गिर जाता है। बैटरी बचत, Wi-Fi रोमिंग और कैरियर NAT सब पर दोष मढ़ा जाता है, जबकि असली कारण एक टेक्स्ट फ़ील्ड में बैठा है जो बाकी सब के साथ कॉपी हुआ है। IKEv2 किसी peer को नाम से पहचानता है, और दोनों फ़ोन वही नाम पेश कर रहे हैं।
पहचान वह कुंजी है जिसके नीचे सर्वर आपको रखता है
IKEv2 आदान-प्रदान के भीतर हर पक्ष बताता है कि वह कौन है: आरंभकर्ता स्थानीय पहचानकर्ता भेजता है, उत्तरदाता अपने वाले से उत्तर देता है, और उत्तरदाता आरंभकर्ता के दावा किए गए पहचान को नीति के विरुद्ध जाँचता भी है। गेटवे अपनी स्थिति डिवाइस के बजाय पहचान के अनुसार रखता है, क्योंकि डिवाइस ऐसी चीज़ नहीं है जिसे वह देख सके। इसलिए एक पहचानकर्ता वाले दो फ़ोन एक ही peer के रूप में आते हैं, और दूसरे आदान-प्रदान को पहले को अधिलेखित करना पड़ता है। समस्या केवल तब दिखती है जब दोनों उपयोग में हों, इसलिए एक फ़ोन वाला परीक्षण इसे कभी दोहराता नहीं।
इसमें से कुछ भी क्लाइंट में बग नहीं है। क्लाइंट ने ठीक वही भेजा जो प्रोफ़ाइल ने उसे भेजने को कहा था।
गेटवे से टकराव कैसा दिखता है
जब दोनों फ़ोन जागृत और उपयोग में हों तब peer सूची देखें। टकराव एक ही प्रविष्टि दिखाता है जिसका पता फ़ोन बदलने पर बदलता है, और सक्रिय सत्रों का काउंटर कभी दो तक नहीं पहुँचता। माँग पर विच्छेद अलग दिखता है, और उन्हें अलग पहचानने के लिए सिद्धांत नहीं, एक अवलोकन चाहिए।
| Observation | Shared identity | Idle teardown |
|---|---|---|
| Peer entries while both are awake | One, with a changing address | One per phone, or none |
| What triggers the drop | The other device connecting | Time without traffic |
| What restores it | The other device disconnecting | Any app needing the tunnel |
जब ऐसा हो तब दोनों घटनाओं को समय-चिह्नों के साथ लिखें। दूसरे हैंडसेट के जुड़ने के साथ मेल खाता ड्रॉप पहचानकर्ता की ओर इशारा करता है, और अंतिम पैकेट के एक निष्क्रिय अंतराल बाद आया ड्रॉप टाइमर की ओर।
नकलें कहाँ से आती हैं
एक काम करने वाला कॉन्फ़िगरेशन निर्यात करके केवल सर्वर पता संपादित करने से दूसरी फ़ाइल बनती है जिसमें पहली फ़ाइल की पहचान अब भी भीतर होती है। यही इस विफलता का सामान्य रास्ता है, और यह आम तौर पर जल्दबाज़ी में किसी छोटे समूह को ऑनबोर्ड करते समय होता है।
फ़ील्ड के नाम इसे चूकना आसान बनाते हैं। दूरस्थ पहचानकर्ता उस गेटवे का नाम देता है जिसकी फ़ोन अपेक्षा करता है, और उसे कॉपी करना सही है। स्थानीय पहचानकर्ता इस हैंडसेट का नाम गेटवे के सामने देता है, और उस मान को कॉपी करना ही पूरी समस्या है।
हर डिवाइस के लिए एक मान जारी करें
हैंडसेट के लिए अद्वितीय और उसके पूरे जीवनकाल में स्थिर कुछ उपयोग करें, जैसे इन्वेंटरी से डिवाइस पहचानकर्ता या वह मान जो आपका प्रबंधन सिस्टम हर नामांकन के लिए उत्पन्न करता है। विभाग का लेबल, साझा सेवा खाते का नाम या उपयोगकर्ता का ईमेल पता—जैसे ही उस व्यक्ति के पास दूसरा डिवाइस होता है, सब टकराते हैं।
एक फ़ाइल वितरित करने के बजाय हर डिवाइस के लिए पेलोड उत्पन्न करें। दर्ज करें कि कौन-सा मान किस हैंडसेट का है, ताकि प्रतिस्थापन पुरानी प्रोफ़ाइल बहाल न करे और नए फ़ोन को सीधे उसी टकराव में न डाल दे।
सर्वर पक्ष भी जाँचें। जो गेटवे पहचान को स्थिर सुरंग पते पर मैप करता है, वह तब भी टकरा सकता है जब दो अलग पहचानकर्ताओं को एक ही आवंटन मिले, इसलिए पुष्टि करें कि पूल में जगह है और आवंटन उपयोगकर्ता के अनुसार पिन नहीं किए गए हैं।
दोनों फ़ोन जागृत रखकर सत्यापित करें
पहला जोड़ें, किसी निजी संसाधन तक पहुँचें, फिर दूसरा जोड़ें और दोनों को एक मिनट निष्क्रिय छोड़ दें। दोनों सत्र बने रहने चाहिए और peer सूची में दो पहचान दिखनी चाहिए। फिर हर फ़ोन को लॉक और अनलॉक करके पुष्टि करें कि निष्क्रिय मामला अब भी ठीक व्यवहार करता है।
अगर एक सत्र अब भी दिन में एक बार गिरता है और कुछ और नहीं जुड़ता, तो पहचान अब संदिग्ध नहीं है। प्रोफ़ाइल को फिर से संपादित करने के बजाय निष्क्रिय टाइमर और सर्वर सत्र सीमाओं की ओर बढ़ें।