IKEv2 એક જ આદાનપ્રદાન નથી: પહેલા IKE SA, પછી પ્રમાણીકરણ અને પછી CHILD SA
ગેટવેનો જવાબ પહોંચ દર્શાવે છે, ઓળખ નહીં. IKE_SA_INIT, IKE_AUTH અને પ્રથમ CHILD SA ને અનુસરો, અને પછી તપાસો કે ટ્રાફિક પસાર થાય તે પહેલાં શું સાચું હોવું જોઈએ.
તમે વિચારી શકો કે IKEv2 કનેક્શન એ એક જ આદાનપ્રદાન છે જે તમારા ટ્રાફિકના એન્ક્રિપ્શન સાથે પૂરું થાય છે. તે ઓછામાં ઓછા બે છે, અને પહેલું કોઈની ઓળખ પ્રમાણિત કરતું નથી. બંને પક્ષો નિયંત્રણ સંદેશાઓથી શરૂ કરે છે, ક્રિપ્ટોગ્રાફિક પરિમાણો પર સંમત થાય છે, ઓળખ સાબિત કરે છે અને ત્યાર પછી જ એ સ્થિતિ પર વાટાઘાટ કરે છે જે એપ્લિકેશન પેકેટો વહન કરે છે. એ ક્રમ જ એ વિસંગતિ સમજાવે છે જે લોકો સતત જણાવે છે: ગેટવે જવાબ આપે છે, ક્લાયન્ટ કનેક્ટેડ કહે છે, અને ખાનગી એપ્લિકેશન હજી સમયમર્યાદા વટાવે છે. અહીં દરેક તબક્કો ખરેખર શું કરે છે અને તેના પછી શું સાચું હોવું જોઈએ તે છે.
દંતકથા: જો ગેટવે જવાબ આપે તો તમે કનેક્ટેડ છો
પ્રથમ સંદેશના જવાબથી સાબિત થાય છે કે એન્ડપોઈન્ટ પહોંચમાં છે અને બોલવા તૈયાર છે. તે સાબિત કરતું નથી કે ખાતું સ્વીકારાયું, પ્રમાણપત્ર શૃંખલા માન્ય થઈ, અથવા કોઈ ડેટા નીતિ સ્થાપિત થઈ.
એ નિષ્ફળતાઓ પછી થાય છે, અને તેઓ જુદાં લક્ષણો ઉત્પન્ન કરે છે. પ્રમાણપત્રનો અસ્વીકાર કે EAP નિષ્ફળતા પ્રથમ આદાનપ્રદાન સફળ થયા પછી આવે છે, એટલે UDP 500 પરનો પિંગ અને લીલું ક્લાયન્ટ ચિહ્ન તમને ખૂબ ઓછું કહે છે.
IKE_SA_INIT: પરિમાણો પર સંમત થાઓ, ઓળખ પર નહીં
પ્રથમ આદાનપ્રદાન IKE સુરક્ષા સંગઠન માટેના પ્રસ્તાવો વહન કરે છે: એન્ક્રિપ્શન અને અખંડિતતા અલ્ગોરિધમ, સ્યુડોરેન્ડમ ફંક્શન અને Diffie-Hellman જૂથ. બંને પક્ષો નોન્સની પણ આપલે કરે છે, અને દરેક બાજુ એ મૂલ્યોમાંથી બનતા વહેંચાયેલ રહસ્યમાંથી IKE SA માટે કી સામગ્રી મેળવે છે. આ આદાનપ્રદાનમાં કંઈ પણ નક્કી કરતું નથી કે સામેનો પક્ષ કોણ છે. તે નક્કી કરે છે કે બંને બાજુઓ સમાન કી ગણી શકે છે અને તેઓ એક પ્રસ્તાવ પર સંમત છે. જેને કોઈ પ્રસ્તાવ ન ગમે તે જવાબદાતા અહીં આદાનપ્રદાન નકારે છે, એટલે આવૃત્તિ કે અલ્ગોરિધમની અસંગતિ સર્વર બંધ હોય તેવું લાગે છે.
આ બિંદુએ બનેલું IKE SA પછીના બધા વ્યવસ્થાપન આદાનપ્રદાનનું રક્ષણ કરે છે. તે તેનું કામ છે, અને તે તમારા પેકેટોના રક્ષણથી અલગ કામ છે.
IKE_AUTH: ઓળખ સાબિત કરો અને પછી પ્રથમ CHILD SA બનાવો
બીજું આદાનપ્રદાન ઓળખ વહન કરે છે. પ્રમાણપત્રો સાથે, દરેક પક્ષ પોતાની ખાનગી કી સાથે સહી કરે છે અને એવી શૃંખલા રજૂ કરે છે જે બીજા પક્ષે માન્ય કરવી પડે; EAP સાથે, જવાબદાતા પસંદ કરેલી રીત દ્વારા આરંભકર્તાને પડકારે છે. અહીં જ ખોટું સર્વર નામ, સમાપ્ત પ્રમાણપત્ર કે નકારાયેલો પાસવર્ડ છેવટે સપાટી પર આવે છે.
સામાન્ય કિસ્સામાં IKE_AUTH પ્રથમ CHILD SA પર પણ વાટાઘાટ કરે છે, એટલે ડેટા રક્ષણ એ જ આગળ-પાછળની મુસાફરીમાં નક્કી થાય છે. આરંભકર્તા ટ્રાફિક સિલેક્ટર પ્રસ્તાવિત કરે છે, જવાબદાતા તેમને સાંકડા કરે છે કે નકારે છે, અને ડેટા માર્ગની કી IKE SA માંથી મેળવાય છે. એનો અર્થ એ છે કે એક આદાનપ્રદાન બે ખૂબ જુદી જગ્યાએ નિષ્ફળ થઈ શકે: ઓળખ કે નીતિ. સામાન્ય હેન્ડશેક નિષ્ફળતાને બદલે સૂચના પેલોડ કે ભૂલ વાંચો, કારણ કે એકનો ઉપાય પ્રમાણપત્ર છે અને બીજાનો ઉપાય સબનેટ અસંગતિ.
બે SA, બે કામ
| સંગઠન | રક્ષણ કરે છે | આયુષ્યનું વર્તન |
|---|---|---|
| IKE SA | વ્યવસ્થાપન આદાનપ્રદાન: કી ફરી બનાવવી, કાઢી નાખવું, રૂપરેખાંકન પેલોડ | પોતાના સમયપત્રક મુજબ કી ફરી બને છે; ડેટા માર્ગ એ ફેરફાર ટકી શકે છે |
| CHILD SA | ટ્રાફિક સિલેક્ટર સાથે મેળ ખાતો એપ્લિકેશન ટ્રાફિક | સ્વતંત્ર રીતે કી ફરી બને છે, ઘણી વાર વધુ વારંવાર |
તેમને અલગ રાખવાથી બે વર્તન સમજાય છે જે ભૂલો જેવા લાગે છે. ટ્યુનેલ સ્થપાયેલું દેખાઈ શકે જ્યારે પાછળ કી ફરી બનાવવાની પ્રક્રિયા નિષ્ફળ જાય, અને ક્લાયન્ટ કનેક્શન ગુમાવ્યા વિના CHILD SA બદલાઈ શકે છે.
strongSwan પર, IKEv2 રૂપરેખાંકન સંદર્ભ અને swanctl --list-sas બંને સ્તરો દર્શાવે છે, અને ip xfrm state સાથે ip xfrm policy દર્શાવે છે કે કર્નલે ખરેખર શું સ્થાપિત કર્યું. એ બે દૃશ્યોની સરખામણી એ જોવાનો સૌથી ઝડપી રસ્તો છે કે વાટાઘાટ પૂરી થઈ કે ફક્ત પૂરી લાગી. જો ડિમન એવું CHILD SA સૂચિબદ્ધ કરે જેના માટે કર્નલ પાસે સ્થિતિ નથી, તો સ્થાપન ચૂપચાપ નિષ્ફળ ગયું. જો કર્નલ પાસે એવી સ્થિતિ હોય જે ડિમન જાણતું નથી, તો તમે અગાઉના પ્રયાસનો અવશેષ જોઈ રહ્યા છો.
ટ્યુનેલ ઊભો થયા પછી પણ શું સાચું રહેવું જોઈએ
ટ્રાફિક સિલેક્ટર નક્કી કરે છે કે કયા સરનામાં આવરી લેવાય છે. જો ક્લાયન્ટ એક સબનેટ પ્રસ્તાવિત કરે અને સર્વર બીજી અપેક્ષા રાખે, CHILD SA સ્થપાય છે પણ કંઈ ઉપયોગી વહન કરતું નથી, અને ભૂલ વાટાઘાટની સમસ્યા નહીં પણ રૂટિંગ સમસ્યા તરીકે દેખાય છે. પછી સ્થાનિક સ્ટેકે સહકાર આપવો પડે: જ્યાં હોસ્ટ રૂટ કરે ત્યાં ફોરવર્ડિંગ સક્ષમ, ટ્યુનેલ તરફના રૂટ, ડિકેપ્સ્યુલેટ થયેલા પેકેટોને મંજૂરી આપતા ફાયરવોલ નિયમો અને ખાનગી નામો સંડોવાયેલા હોય તો આંતરિક રિઝોલ્વર. એમાંનું દરેક અલગથી નિષ્ફળ થાય છે અને IKE ડિમન ફરી ચાલુ કરવાથી એમાંથી કોઈ સુધરતું નથી.
નિદાન કરતી વખતે લોગ દૃશ્યમાન રાખો: પ્રારંભિક આદાનપ્રદાન, પછી ઓળખ ચકાસણી, પછી જ્યાં લાગુ પડે ત્યાં વપરાશકર્તા પ્રમાણીકરણ, પછી CHILD સ્થાપન અને અંતે એપ્લિકેશન ટ્રાફિક. જે તબક્કો અટકે છે તે જ સુધારવાનો છે, અને પછીની રૂટિંગ નિષ્ફળતા ક્યારેય પસાર થઈ ગયેલી ઓળખ ચકાસણીઓને ઢીલી કરવાનું કારણ નથી.