दुई फोन, एउटा प्रोफाइल र कसैले गेटवे नहेरेसम्म अलौकिक देखिने ढाँचा। एउटा यन्त्रले सुरुङ राख्छ, दोस्रो जोडिन्छ, र पहिलोले केही सेकेन्डभित्र त्यो गुमाउँछ। पहिलो फेरि जोडिन्छ र दोस्रो खस्छ। ब्याट्री बचत, Wi-Fi रोमिङ र क्यारियर NAT सबैलाई दोष दिइन्छ, जबकि वास्तविक कारण अरू सबैसँगै प्रतिलिपि भएको पाठ फाँटमा बसेको हुन्छ। IKEv2 ले peer लाई नामले चिन्छ, र दुवै फोनले एउटै नाम प्रस्तुत गरिरहेका छन्।

पहिचान भनेको सर्भरले तपाईंलाई राख्ने साँचो हो

IKEv2 आदानप्रदानभित्र प्रत्येक पक्षले आफू को हो भनी बताउँछ: सुरु गर्नेले स्थानीय पहिचानकर्ता पठाउँछ, जवाफ दिनेले आफ्नै पहिचानकर्ताले जवाफ दिन्छ, र जवाफ दिनेले सुरु गर्नेले दाबी गरेको पहिचानलाई नीतिको आधारमा जाँच्छ पनि। गेटवेले आफ्नो अवस्था यन्त्रअनुसार नभई पहिचानअनुसार राख्छ, किनकि यन्त्र त्यो चीज होइन जो उसले देख्न सक्छ। त्यसैले एउटै पहिचानकर्ता भएका दुई फोन एउटा peer का रूपमा आउँछन्, र दोस्रो आदानप्रदानले पहिलोमाथि लेख्नुपर्छ। समस्या दुवै प्रयोगमा हुँदा मात्र देखिन्छ, त्यसैले एउटा फोनको परीक्षणले यसलाई कहिल्यै दोहोर्याउँदैन।

यीमध्ये केही पनि क्लाइन्टमा बग होइन। प्रोफाइलले भनेको कुरा नै क्लाइन्टले ठ्याक्कै पठायो।

गेटवेबाट ठोक्किने घटना कस्तो देखिन्छ

दुवै फोन जागा र प्रयोगमा हुँदा peer सूची हेर्नुहोस्। ठोक्किने घटनाले एउटै प्रविष्टि देखाउँछ जसको ठेगाना फोन फेरिँदा बदलिन्छ, र सक्रिय सत्रको गणक कहिल्यै दुईमा पुग्दैन। मागअनुसार विच्छेद फरक देखिन्छ, र तिनीहरूलाई छुट्याउन सिद्धान्त नभई एउटा अवलोकन चाहिन्छ।

ObservationShared identityIdle teardown
Peer entries while both are awakeOne, with a changing addressOne per phone, or none
What triggers the dropThe other device connectingTime without traffic
What restores itThe other device disconnectingAny app needing the tunnel

यो हुँदै गर्दा दुवै घटना समय-छापसहित लेख्नुहोस्। अर्को ह्यान्डसेटको जडानसँग मिल्ने विच्छेदले पहिचानकर्तातर्फ संकेत गर्छ, र अन्तिम प्याकेटपछि एउटा निष्क्रिय अन्तरालपछि आउने विच्छेदले टाइमरतर्फ संकेत गर्छ।

नक्कली प्रतिलिपि कहाँबाट आउँछन्

एउटा चल्ने कन्फिगरेसन निर्यात गरेर सर्भर ठेगाना मात्र सम्पादन गर्दा पहिलो फाइलको पहिचान अझै भित्र भएको दोस्रो फाइल बन्छ। यो यस असफलतातर्फको सामान्य बाटो हो, र सामान्यतया हतारमा सानो समूह अनबोर्ड गर्दा हुन्छ।

फाँटका नामहरूले यसलाई छुटाउन सजिलो बनाउँछन्। टाढाको पहिचानकर्ताले फोनले अपेक्षा गर्ने गेटवेको नाम दिन्छ, र त्यसलाई प्रतिलिपि गर्नु सही हो। स्थानीय पहिचानकर्ताले यो ह्यान्डसेटलाई गेटवेसामु नाम दिन्छ, र त्यो मान प्रतिलिपि गर्नु नै पूरै समस्या हो।

प्रत्येक यन्त्रका लागि मान जारी गर्नुहोस्

ह्यान्डसेटका लागि अद्वितीय र यसको सम्पूर्ण आयुभर स्थिर रहने कुरा प्रयोग गर्नुहोस्, जस्तै इन्भेन्टरीको यन्त्र पहिचानकर्ता वा तपाईंको व्यवस्थापन प्रणालीले प्रत्येक दर्ताका लागि उत्पन्न गर्ने मान। विभागको लेबल, साझा सेवा खाताको नाम वा प्रयोगकर्ताको इमेल ठेगाना—ती व्यक्तिसँग दोस्रो यन्त्र हुने बित्तिकै सबै ठोक्किन्छन्।

एउटा फाइल वितरण गर्नुको सट्टा प्रत्येक यन्त्रका लागि पेलोड उत्पन्न गर्नुहोस्। कुन मान कुन ह्यान्डसेटको हो लेख्नुहोस्, ताकि प्रतिस्थापनले पुरानो प्रोफाइल पुनर्स्थापित गरी नयाँ फोनलाई सिधै त्यही ठोक्किने अवस्थामा नपुर्याओस्।

सर्भर पक्ष पनि जाँच्नुहोस्। पहिचानलाई स्थिर सुरुङ ठेगानामा म्याप गर्ने गेटवेले दुई फरक पहिचानकर्ताले एउटै बाँडफाँट पाउँदा अझै ठोक्किन सक्छ, त्यसैले पूलमा ठाउँ छ र बाँडफाँट प्रयोगकर्ताअनुसार पिन गरिएको छैन भनी पुष्टि गर्नुहोस्।

दुवै फोन जागा राखेर प्रमाणित गर्नुहोस्

पहिलो जोड्नुहोस्, निजी स्रोतमा पुग्नुहोस्, त्यसपछि दोस्रो जोड्नुहोस् र दुवैलाई एक मिनेट निष्क्रिय राख्नुहोस्। दुवै सत्र टिक्नुपर्छ र peer सूचीले दुई पहिचान देखाउनुपर्छ। त्यसपछि प्रत्येक फोन लक र अनलक गरी निष्क्रिय अवस्था अझै ठीक व्यवहार गर्छ भनी पुष्टि गर्नुहोस्।

यदि एउटा सत्र अझै दिनको एक पटक अरू केही नजोडिई खस्छ भने पहिचान अब शंकास्पद छैन। प्रोफाइल फेरि सम्पादन गर्नुको सट्टा निष्क्रिय टाइमर र सर्भर सत्र सीमातर्फ जानुहोस्।

सम्बन्धित लेखहरू