दोन 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 यादीने दोन ओळखी दाखवल्या पाहिजेत। नंतर प्रत्येक फोन लॉक आणि अनलॉक करून निष्क्रिय प्रकरण अजूनही योग्य वागते याची खात्री करा।
जर एक सत्र अजूनही दिवसातून एकदा इतर काहीही न जोडता पडत असेल, तर ओळख यापुढे संशयित नाही। प्रोफाइल पुन्हा संपादित करण्याऐवजी निष्क्रिय टाइमर आणि सर्व्हर सत्र मर्यादांकडे जा।