બે 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 યાદી બે ઓળખ દર્શાવવી જોઈએ. પછી દરેક ફોન લૉક અને અનલૉક કરીને ખાતરી કરો કે નિષ્ક્રિય કેસ હજી યોગ્ય રીતે વર્તે છે.
જો એક સત્ર હજી પણ દિવસમાં એક વાર તૂટે છે અને બીજું કંઈ જોડાતું નથી, તો ઓળખ હવે શંકાસ્પદ નથી. પ્રોફાઇલ ફરી સંપાદિત કરવાને બદલે નિષ્ક્રિય ટાઇમર અને સર્વર સત્ર મર્યાદા તરફ આગળ વધો.