IKEv2 NO_PROPOSAL_CHOSEN: કયા તબક્કે સ્યૂટ નકારી?

લોગમાં NO_PROPOSAL_CHOSEN જોતાં લોકો પૂર્વ-વહેંચાયેલી કી તરફ દોડે છે, અને કી બદલ્યા પછી પણ ભૂલ ટકી રહે છે. તે ક્યારેય ઓળખપત્રની સમસ્યા નહોતી: પીઅરે તે આપલે માટે આપેલો દરેક પ્રસ્તાવ નકાર્યો, જે ઓળખ વિશે નહીં પણ અલ્ગોરિધમ વિશેનું નિવેદન છે. પ્રથમ ઉપયોગી પ્રશ્ન એ નથી કે કયો અલ્ગોરિધમ સંપાદિત કરવો, પણ એ કે કઈ આપલે નકારાઈ. કોઈપણ સરખામણી પહેલાં તેનો જવાબ આપો. પછી પ્રસ્તાવિત સંપૂર્ણ સ્યૂટની પીઅર મંજૂર કરે તે સંપૂર્ણ સ્યૂટ સાથે સરખામણી કરો.

પ્રથમ: કઈ આપલે નકારાઈ

IKEv2 બે પ્રકારના સંગઠનની વાટાઘાટ કરે છે. IKE SA પોતે વાટાઘાટનું રક્ષણ કરે છે, અને CHILD SA ટ્રાફિકનું રક્ષણ કરે છે. દરેકનો પોતાનો પ્રસ્તાવ-સમૂહ છે, અને દરેક સમાન સૂચના સાથે નિષ્ફળ થઈ શકે છે. પ્રારંભિક IKE વાટાઘાટ દરમિયાન નકાર અને CHILD વાટાઘાટ દરમિયાન નકારને જુદા જુદા સુધારા જોઈએ, અને લોગ સામાન્ય રીતે સૂચનાની એક-બે લાઇન ઉપર આપલેનું નામ આપે છે. તે બે લાઇન સાથે વાંચો, નહીં તો ખોટી પ્રસ્તાવ-યાદી સંપાદિત કરશો.

ફક્ત સૂચના આપલેને ઓળખતી નથી. તેની ઉપરની લાઇન વાટાઘાટ થતા SAનું નામ આપે છે, અને તે નામ તપાસવાની પ્રસ્તાવ-યાદી તરફ ઇશારો કરે છે.

સંપૂર્ણ સ્યૂટની સરખામણી કરો, એકલ કીવર્ડની નહીં

પ્રસ્તાવ એક સંયોજન છે: એન્ક્રિપ્શન અલ્ગોરિધમ, ઇન્ટિગ્રિટી અથવા AEAD, કી-એક્સચેન્જ જૂથ, અને કોઈપણ સ્યુડો-રેન્ડમ ફંક્શન. ફક્ત એન્ક્રિપ્શનનું નામ સરખાવવું તે સામાન્ય ભૂલ છે, કારણ કે બે પીઅર AES-256 પર સહમત થઈને પણ SHA-1 વિરુદ્ધ SHA-256 પર અસહમત રહી શકે છે. નિષ્ફળ તબક્કે પ્રસ્તાવિત અને મંજૂર સ્યૂટ બાજુમાં લખો, પછી ખાલી છેદ શોધો.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

એ પણ ચકાસો કે બંને અમલીકરણ તમે ગોઠવેલું સમર્થન કરે છે. બીજા પ્લેટફોર્મ પરથી કોપી કરેલું નામ વ્યાકરણની દૃષ્ટિએ પરિચિત લાગી શકે છે જ્યારે પ્લગઇન અથવા અમલીકરણ સંપૂર્ણ રૂપે ગેરહાજર હોય.

IKE સ્યૂટ અને ESP સ્યૂટ જુદી વસ્તુઓ છે

IKE પ્રસ્તાવ સંપાદિત કરવાથી નકારાયેલ CHILD પ્રસ્તાવ સુધરશે નહીં, અને ઊલટું પણ સાચું છે. strongSwanમાં આ અલગ સેટિંગ્સ છે, આશરે IKE SA માટે proposals = aes256-sha256-modp2048 અને CHILD SA માટે અલગ ESP યાદી. નિષ્ફળ આપલે સાથે મેળ ખાતી યાદી બદલો, પછી સુધારો કામ કર્યો એમ માનીને નહીં પણ લોગ ફરી વાંચો.

CHILD SA માટે સંબંધિત સેટિંગ ESP પ્રસ્તાવ-યાદી છે, IKEની નહીં. તેમાં IKE લાઇન કોપી કરવાથી એવી ગોઠવણી બને છે જે પાર્સ થાય છે પણ ખોટી વસ્તુની વાટાઘાટ કરે છે.

કામ કરતું ટનલ જે કી-નવીકરણ પર નિષ્ફળ જાય

જો ટનલ એક કલાક ચાલીને પછી નિષ્ફળ ગઈ, તો પ્રારંભિક વાટાઘાટ સમસ્યા નથી. કી-નવીકરણ જુદી પરિસ્થિતિઓ કસી શકે છે: પ્રથમ આપલે પછી જુદું કી-એક્સચેન્જ જૂથ, પીઅર વચ્ચે લાઇફટાઇમની અસંગતિ, અથવા બદલાયેલ રિસ્પોન્ડર નીતિ. બંને બાજુથી નવીકરણ ટાઇમસ્ટેમ્પ અને સંગઠન ઓળખકર્તા રાખો. તે પેટર્નને નવીકરણ વખતે પ્રસ્તાવની સરખામણી જોઈએ, લાંબો ટાઇમઆઉટ નહીં. ટાઇમઆઉટ બદલવાથી લક્ષણ ઢંકાય છે અને અસંગતિ યથાવત્ રહે છે.

ipsec statusall દરેક સંગઠન અને ખરેખર વાટાઘાટ થયેલા અલ્ગોરિધમ દર્શાવે છે. તે આઉટપુટ કઈ યાદી વપરાઈ તેની ખાતરી કરવાનો સૌથી ઝડપી રસ્તો છે, અને ગોઠવણીની ભૂલને ક્યારેય ફરી વાટાઘાટ ન કરેલી જૂની ટનલથી અલગ પાડે છે.

ipsec statusall | grep -E "IKE:|ESP:"

એક છેદ પસંદ કરો, પછી બંને તબક્કા ખાતરી કરો

વ્યવસ્થાપકને બંને પીઅર સમર્થિત દસ્તાવેજીકૃત આધુનિક છેદ પસંદ કરવા કહો અને તે લખી રાખો. ભૂલને દરેક જૂનું અલ્ગોરિધમ ચાલુ કરીને કે ઓળખ ચકાસણી બંધ કરીને ઉકેલશો નહીં, કારણ કે નકારમાંથી બંનેમાંથી એક પણ અનુસરતું નથી. બદલાવ પછી નવું જોડાણ સ્થાપો અને પછી કી-નવીકરણ ફરજિયાત કરો. ફક્ત પ્રથમ જોડાણ નવીકરણ માર્ગ કામ કરે છે તે સાબિત કરતું નથી.

સ્વીકૃત સંયોજન ફર્મવેર આવૃત્તિઓ સાથે રાખો. જો આગળની ભૂલ ટ્રાફિક સિલેક્ટર વિશે હોય, તો તેને અલગ ગણો, કારણ કે ક્રિપ્ટોગ્રાફી પરની સહમતિ ટનલ કયા સબનેટનું રક્ષણ કરે છે તે વિશે કંઈ કહેતી નથી. strongSwanની પ્રસ્તાવ દસ્તાવેજીકરણ બંને યાદી માટે વાક્યરચના આવરે છે.