એક કરતાં વધુ ક્લાયન્ટને અનુકૂળ IKEv2 સેટિંગ્સનું આયોજન કરો
કામ કરતી ડેસ્કટોપ પ્રોફાઇલે એક જ ક્લાયન્ટનું પરીક્ષણ કર્યું છે. ઓળખ કરાર પર સંમત થાઓ, સમર્થિત છેદ પસંદ કરો, પછી દરેક પ્લેટફોર્મ માટે નવીકરણ અને સ્લીપનું પરીક્ષણ કરો.
એક ડેસ્કટોપ પર કામ કરતી પ્રોફાઇલ એ એક ક્લાયન્ટનું સફળ પરીક્ષણ છે. તે આંતર-પ્લેટફોર્મ જમાવટ નથી, અને તેને એમ ગણવાથી પરિચિત સહાય પેટર્ન ઊભી થાય છે: Windows જોડાય છે, ફોન ઓળખ તપાસમાં નિષ્ફળ જાય છે, અને સંચાલિત લેપટોપ જ્યારે પણ જાગે ત્યારે ફરી જોડાય છે. તફાવતો વાસ્તવિક છે અને મોટાભાગે અનુમાન કરી શકાય તેવા છે, તેથી યોજના સ્ક્રીનશોટ નહીં, મેટ્રિક્સ હોવી જોઈએ.
પહેલાં ઓળખ કરાર નક્કી કરો
અલ્ગોરિધમની ચર્ચા કરતાં પહેલાં સર્વર ઓળખ, પ્રમાણપત્ર વિશ્વાસ અને ક્લાયન્ટ પ્રમાણીકરણ પદ્ધતિ વિશેનું દસ્તાવેજીકરણ કરો. આ ત્રણ નક્કી કરે છે કે ક્લાયન્ટ બિલકુલ પ્રમાણીકરણ કરી શકે છે કે નહીં, અને પ્લેટફોર્મ આ ભાગોને અલગ રીતે વ્યક્ત કરે છે.
દરેક પ્લેટફોર્મ અપેક્ષિત ઓળખકર્તાને કેવી રીતે નામ આપે છે અને વિષયના વૈકલ્પિક નામો સાથે કેવી રીતે વ્યવહાર કરે છે તે તપાસો. એક ક્લાયન્ટ પર સર્વરનું નામ સ્વીકારતી પ્રોફાઇલ બીજા પર તે જ પ્રમાણપત્ર નકારી શકે છે, કારણ કે ઓળખકર્તા ક્ષેત્ર અલગ મૂલ્યથી ભરાય છે.
| Contract element | What to decide | Where platforms diverge |
|---|---|---|
| Server identity | Name or address the client must see | Identifier field and SAN matching |
| Client authentication | Certificate, EAP method or both | Which EAP variants exist and how prompts appear |
| Trust anchor | Which CA and how it is delivered | Store location and provisioning path |
પછી ક્રિપ્ટોગ્રાફિક છેદ પસંદ કરો
દરેક સમર્થિત ક્લાયન્ટ આપી શકે તેવા પ્રસ્તાવોની તુલના કરો અને આધુનિક છેદ પસંદ કરો જે ગેટવે પણ પરવાનગી આપે છે. એક જૂનું ઉપકરણ જોડાય તે માટે અતિશય મોટી જૂની સૂચિ સક્રિય કરશો નહીં, કારણ કે તે સૂચિ પછીથી આવનાર દરેક માટે ગેટવેનું મૂળભૂત બની જાય છે. દરેક જૂનો વિકલ્પ હજી કેમ છે તે લખો. જે ઉપકરણને તેની જરૂર છે તે કોઈ નામ આપી શકતું ન હોય, તો તે આવશ્યકતા નથી.
યોજનામાં IKE અને CHILD સેટિંગ્સ અલગ રાખો. IKE વિનિમય માટે સ્વીકાર્ય પ્રસ્તાવ સુરક્ષિત ટ્રાફિક માટે આપોઆપ સ્વીકાર્ય નથી, અને બંને અલગથી વાટાઘાટ થાય છે. એક સ્તર પર પ્રસ્તાવ સ્વીકારતું ગેટવે બીજા સ્તર પર તેને હજી નકારી શકે છે, અને લોગ એવી નિષ્ફળતા દર્શાવશે જે પ્રથમ સ્તર સફળ થયું હોય તેવું લાગે.
ચકાસાયેલ પ્રક્રિયા દ્વારા ઓળખપત્રો પ્રદાન કરો, અને વપરાશકર્તા પાસવર્ડ, શેર કરેલ રહસ્ય અને ક્લાયન્ટની ખાનગી કી તેમના પોતાના ક્ષેત્રોમાં રાખો. સમાન નામનાં બોક્સ પર અજમાયશ અને ભૂલ એ જ રીત છે જેમાં કામ કરતું પરીક્ષણ પુનરાવર્તન ન કરી શકાય તેવું બને છે.
સ્થિર સ્થિતિ નહીં, જીવનચક્રનું પરીક્ષણ કરો
દરેક ક્લાયન્ટ માટે પ્રારંભિક પ્રમાણીકરણ, ઇચ્છિત એપ્લિકેશન, DNS રિઝોલ્યુશન અને સરનામાં-કુટુંબ કવરેજનું પરીક્ષણ કરો. પછી માત્ર પછીથી દેખાતા ભાગોનો અભ્યાસ કરો: નવીકરણ, સ્લીપ અને સામાન્ય નેટવર્ક ફેરફાર.
MOBIKE સમર્થન અને ફરી પ્રમાણીકરણનું વર્તન તમે હમણાં માપેલા સ્થિર પરિણામથી અલગ હોઈ શકે છે. તે સમયની ઘટના અને સંલગ્નતાની સ્થિતિ નોંધો, ફક્ત ઇન્ટરફેસ આખરે જોડાયેલું દેખાય છે કે નહીં તે નહીં.
VPN ઉપલબ્ધ ન હોય ત્યારે સીધો ટ્રાફિક શું કરી શકે તે વ્યાખ્યાયિત કરો. આ ક્લાયન્ટ ફરી જોડાય છે કે નહીં તેનાથી અલગ નીતિ નિર્ણય છે, અને મોટાભાગની જમાવટો પ્રથમ પ્રશ્નને અવગણીને બીજા પ્રશ્નનો જવાબ આપે છે. જવાબ પ્રોફાઇલ નામોની બાજુમાં જમાવટ નોંધમાં લખો. કોઈને વિક્ષેપ દરમિયાન તેની જરૂર પડશે, અને તેને ફરી બનાવવાનો સમય નહીં હોય.
એક પ્લેટફોર્મ અસહમત હોય ત્યારે સર્વર ઓળખ તપાસનો ઉપયોગ કરો
જ્યારે પ્રોફાઇલ એક પ્લેટફોર્મ પર કામ કરે છે અને બીજું તેનું નામ નકારે છે, ત્યારે ક્લાયન્ટે ખરેખર મોકલેલ ઓળખકર્તાને પ્રમાણપત્ર ધરાવતા ઓળખકર્તાઓ સાથે સરખાવો. આ સરખામણી સાઇફર સૂચિ બદલવા કરતાં આમાંથી મોટાભાગના કિસ્સાઓ ઝડપથી ઉકેલે છે.
પરીક્ષણ કરેલ મેટ્રિક્સને રૂપરેખાંકન સ્રોત અને અપડેટ પ્રક્રિયા સાથે રાખો. જૂના ક્લાયન્ટ માટે સમર્થન સમાપ્ત થાય ત્યારે આગલી ઓડિટને મળે તે માટે ગેટવેમાં નબળી સુસંગતતા સેટિંગ્સ છુપાવી રાખવાને બદલે તેનો અપવાદ જાણી જોઈને દૂર કરો. strongSwan IKEv2 દસ્તાવેજીકરણ વિનિમયો કેવી રીતે રૂપરેખાંકિત થાય તે માટે ઉપયોગી સંદર્ભ છે.