Windows અને strongSwan સાઇફર: યોગ્ય સ્તર મેળવો

બંને છેડા AES-128 કહે છે અને ટનલ હજી પણ બનવાનું નકારે છે. CBC અને GCM અલગ રૂપાંતરણો છે જે સંજોગવશાત્ સમાન કી લંબાઈ વહેંચે છે, અને એક પ્રસ્તાવ કરતો ક્લાયન્ટ ફક્ત બીજું સ્વીકારતા ગેટવેને સંતોષતો નથી. AES શબ્દ એક કુટુંબનું વર્ણન કરે છે, કરારનું નહીં.

બીજો અક્ષ પણ છે, અને તે જ ગૂંચવણભરી ભૂલો પેદા કરે છે.

બે સ્તર, બે સ્વતંત્ર યાદીઓ

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

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

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

પ્રસ્તાવોની બાજુમાં ભૂલ વાંચો

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

પ્રાપ્ત પ્રસ્તાવ, ગોઠવેલ પ્રસ્તાવ અને પસંદ કરેલ પ્રસ્તાવની સરખામણી કરો તે એક જ પ્રયાસ માટે. અહીં ત્રણ અલગ યાદીઓ મહત્ત્વની છે, અને ફક્ત છેલ્લી જ વર્ણવે છે કે ખરેખર શું વપરાયું. ટિકિટમાં તેને સારાંશ આપવાને બદલે શબ્દશઃ ટાંકો.

CBC અને GCM ને અલગ વિકલ્પો તરીકે રાખો

જેને જાણી જોઈને કોઈપણ કુટુંબ સ્વીકારવાની પરવાનગી છે તેવા ગેટવેને બે પ્રસ્તાવ જોઈએ, એક નહીં. strongSwan માં અલ્પવિરામ વિકલ્પોને અલગ કરે છે અને હાઇફન એક સમૂહના ઘટકોને જોડે છે. બંને કુટુંબોને હાઇફનથી જોડવાથી બે સ્વીકાર્ય પ્રસ્તાવોને બદલે એક અશક્ય પ્રસ્તાવ બને છે.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

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

ESP પ્રસ્તાવ એ પુનઃનામિત IKE પ્રસ્તાવ નથી

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

એક દિશા પસંદ કરો અને તેમાં રહો. કાં તો ગેટવે ફક્ત GCM નીતિ રાખે છે અને ક્લાયન્ટ સંપૂર્ણ સુસંગત નીતિ તૈનાત કરે છે, અથવા ગેટવે બંને કુટુંબો સ્વીકારે છે અને ક્લાયન્ટ તેનો હાલનો સમૂહ રાખે છે. સુરક્ષા નીતિ જે ફોલબેક પર પ્રતિબંધ મૂકે છે તેને સક્ષમ કરવું એ ઉકેલ નથી, તે ભૂલને કેટલી ઝડપથી દૂર કરે તે પછી પણ.

બંને સમૂહો ચકાસો, પછી કી રિન્યુઅલ

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

તે પુરાવો ફેરફાર સાથે રાખો. વારંવાર થતું ડિસ્કનેક્શન કોઈને ટાઇમર કે પ્લેટફોર્મ ખામીને દોષ આપે તે પહેલાં તેને પોતાનું નિષ્ફળ-એક્સચેન્જ રેકોર્ડ જોઈએ.