8192-બિટ કી હેન્ડશેકને અટકાવે છે; 1024-બિટ DH નકારાય છે
વિરોધી સુધારા સાથેની બે કદની ભૂલો: વધુ પડતી મોટી કી હેન્ડશેકનો સમય બાળે છે જ્યાં સુધી સામેની બાજુનો સમય પૂરો ન થાય, જ્યારે નાનું DH જૂથ શરૂ થતાં પહેલાં નકારાય છે.
એક સર્વરમાં ક્લાયન્ટ થોડી વાર અટકીને પછી ફરી જોડાય છે, અને બીજું સર્વર કીના કદ વિશેના સંદેશ સાથે જોડાણો તરત જ નકારે છે. એ અલગ બગ લાગે છે અને એ જ બગ છે જે વિરોધી દિશામાં જુએ છે. હેન્ડશેક ક્રિપ્ટોગ્રાફીનો ખર્ચ પરિમાણોના કદ સાથે વધે છે, અને તેની એક નીચી મર્યાદા પણ છે જેની નીચે આધુનિક લાઇબ્રેરીઓ જતી નથી. સામગ્રીનું કદ નક્કી કરવું એ ચેકલિસ્ટ છે, અને પહેલું મુદ્દું એ નક્કી કરવાનું છે કે તમારી પાસે ખરેખર બેમાંથી કઈ ભૂલ છે.
કંઈ પણ ફરી બનાવતા પહેલાં નિષ્ફળતા વાંચો
સમય તમને મોટા ભાગનું કહી દે છે. થોડી સેકન્ડ લઈને પછી મરી જતો હેન્ડશેક સામાન્ય રીતે એમ કહે છે કે ગણતરીએ સામેની બાજુની ધીરજને વટાવી દીધી, જે હાર્ડવેર કે સમયમર્યાદા માટે ઘણા મોટા પરિમાણો તરફ ઇશારો કરે છે. કી કે જૂથનું કદ બોલતો તાત્કાલિક અસ્વીકાર બીજી દિશામાં ઇશારો કરે છે, એ સામગ્રી તરફ જે લાઇબ્રેરી બિલકુલ સ્વીકારશે નહીં.
એ બેને વિરોધી સુધારા જોઈએ છે, અને અહીં જ મોટા ભાગની કોશિશો ખોટી પડે છે. જે ક્લાયન્ટ ઓછેવત્તે જૂથ નકારી ચૂક્યું છે તેના પર 8192-બિટ પરિમાણો ફરી બનાવવાથી ધીમો કિસ્સો વધુ ખરાબ થાય છે જ્યારે ઝડપી કિસ્સા માટે કંઈ કરતું નથી. કોઈ ફાઇલને અડકતા પહેલાં તમે કઈ નિશાની જોઈ તે લખી રાખો.
પછી સામેની બાજુ પાસેથી શું માંગવામાં આવે છે તે તપાસો. મોટા મર્યાદિત-ક્ષેત્ર જૂથ માટે ગોઠવાયેલું સર્વર દરેક ક્લાયન્ટને ફક્ત જોડાણ વખતે જ નહીં, પણ દરેક ફરી-વાટાઘાટ વખતે સમાન CPU સમય ખર્ચવાની ફરજ પાડે છે. સમસ્યા શરૂઆતમાં નહીં પણ નિયમિત અંતરાલે દેખાય તો એ અંતરાલ કઈ ગોઠવણ મોંઘી છે તેનો મજબૂત સંકેત છે. ફરી-વાટાઘાટ આખી ગણતરી પુનરાવર્તિત કરે છે, તેથી દર કલાકે પાછું આવતું અટકવું સામાન્ય રીતે એ જ ખર્ચ ફરી ચૂકવવાનું છે.
ધીમો કિસ્સો: એવી સામગ્રી જે હાર્ડવેર પરવડી શકે નહીં
Diffie-Hellman અને RSAનું કામ કીના કદ સાથે ઝડપથી વધે છે, અને એ બધું ટનલમાં કોઈ ટ્રાફિક વહેતા પહેલાં જ થાય છે. નાના રાઉટર કે ઓછી શક્તિવાળા ક્લાયન્ટ પર પૂરતું મોટું જૂથ આદાનપ્રદાનને સામેની બાજુની સમયમર્યાદા વટાવી જવા ધકેલી શકે છે, જેથી જોડાણ ફરી પ્રયાસ કરે છે અથવા કોઈપણ ભૂલ વગર ફક્ત અટકેલું દેખાય છે.
ઉપાય એ છે કે એવા કદ પર આવવું જે દરેક સામેની બાજુ ટેકો આપે અને દરેક ઉપકરણ આરામથી ગણી શકે. 2048-બિટ RSA કી અને 2048-બિટ જૂથ વ્યાપક રીતે સુસંગત આધારરેખા રહે છે; મોટું કરવું ફક્ત ત્યારે જ મદદ કરે છે જ્યારે બધી બાજુઓ સહમત હોય અને પ્રોસેસર દરેક ફરી-વાટાઘાટમાં તેનો ખર્ચ આપી શકે. એ આધારરેખા ઉપરનું બધું જાણી જોઈને કરેલી આપલે છે, સુધારો નહીં.
કદ કોઈ સ્કોર નથી, અને સરખામણી કોષ્ટકની સૌથી મોટી સંખ્યા આપમેળે સાચી પસંદગી નથી. તમારી નીતિ જે નાનામાં નાનું મૂલ્ય મંજૂર કરે અને બધી બાજુઓ સ્વીકારે તે પસંદ કરો, પછી સુધર્યું છે એમ માનવાને બદલે હેન્ડશેક માપો. હજી પણ સમય પૂરો કરતું નાનું જૂથ તમને કહે છે કે કદ ક્યારેય આખી વાર્તા ન હતું.
ઝડપી કિસ્સો: લાઇબ્રેરી જે જૂથ નકારે છે
આધુનિક OpenSSL બિલ્ડ સૌથી નાનાં મર્યાદિત-ક્ષેત્ર જૂથોને સીધાં નકારે છે, અને વધારેલું સુરક્ષા સ્તર નીચી મર્યાદાને વધુ ઉપર ધકેલે છે. દાયકાઓ જૂની પરિમાણ ફાઇલ સાથે લાવતું રાઉટર ફર્મવેર સામાન્ય સ્રોત છે, અને નિશાની એ છે કે જૂથ કે કીનું કદ બોલતા સંદેશ સાથે જોડાણ તરત જ નિષ્ફળ જાય છે. એ નિષ્ફળતામાં કંઈ પણ અંતરાલબદ્ધ નથી, અને એ જ તેને ઓળખવું સહેલું બનાવે છે.
તપાસ છોડવા માટે ગોઠવણી સંપાદિત કરવાને બદલે ફાઇલ બદલો. વર્તમાન જૂથ બનાવો, તેને માન્ય કરો, પછી ડિમન ખરેખર જ્યાં વાંચે છે ત્યાં સ્થાપિત કરો. ક્લાયન્ટ નવા સાથે સફળતાપૂર્વક જોડાય ત્યાં સુધી જૂની ફાઇલ રાખો:
openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pemતપાસ આદેશ ફાઇલને માન્ય કરે છે અને પસાર થાય ત્યારે ઉપયોગી કંઈ છાપતો નથી; યાદી પુષ્ટિ કરે છે કે તમે સેવા જે ફાઇલ લોડ કરે છે તે બદલી છે, બાજુની જૂની નકલ નહીં. ગોઠવણીને એ પથ પર દોરો, ડિમન ફરી ચાલુ કરો, અને પુષ્ટિ કરો કે પહેલાં નિષ્ફળ ગયેલો ક્લાયન્ટ હવે હેન્ડશેક પૂરો કરે છે.
જો સર્વર સુરક્ષા સ્તર કે પ્રમાણપત્ર પ્રોફાઇલ પણ સેટ કરે, તો જૂથ ખોટું હતું એવો નિષ્કર્ષ કાઢતા પહેલાં એ વાંચો. વધુ કડક વર્ગ માંગતું પ્રોફાઇલ એવી સામગ્રી નકારી શકે જે ડિફોલ્ટ સ્વીકારત, અને એ ગોઠવણ દૂર કરવી વૈશ્વિક રીતે તપાસ બંધ કરવા કરતાં સાંકડો ફેરફાર છે.
સામેની બાજુ અને હાર્ડવેર માટે કદ પસંદ કરો
કંઈ વિચિત્ર બનાવતા પહેલાં દૂરનો છેડો શું સહન કરી શકે તે શોધો. 2048-બિટ જૂથ માટે ઘણું જૂનું ઉપકરણ બદલવા જેવું ઉપકરણ છે, કારણ કે સર્વરને નબળા જૂથ તરફ દોરવાથી ફક્ત સુસંગતતાની ફરિયાદ વિક્ષેપમાં ફેરવાય છે. ટકાઉ ઉપાય જૂનાં પરિમાણો તરફ નહીં, નવા સોફ્ટવેર તરફ જાય છે. આ ક્ષેત્રનો દરેક કામચલાઉ અપવાદ કાયમી ગોઠવણી બનવાની રીત શોધી લે છે.
જ્યાં સર્વરનું CPU મર્યાદા છે ત્યાં નીતિની નીચે ઉતરવાને બદલે અલ્ગોરિધમ બદલો. X25519 જેવું લંબગોળ વક્ર કી આદાનપ્રદાન મોટા મર્યાદિત-ક્ષેત્ર જૂથ કરતાં નાટકીય રીતે સસ્તું છે અને વ્યાપકપણે ટેકાયેલું છે, જે તેને નાના RSA મોડ્યુલસ કરતાં કાર્યક્ષમતાની ફરિયાદનો સારો જવાબ બનાવે છે.
તમે શું પણ પસંદ કરો, એક વાસ્તવિક જોડાણ સાથે પરીક્ષણ કરો અને હેન્ડશેક કેટલો સમય લે છે તે જુઓ, ફક્ત અંતે જોડાય છે કે નહીં તે નહીં. બાર સેકન્ડમાં સફળ થતા જોડાણનું મૂળ કારણ પંદરમાં નિષ્ફળ થતા જોડાણ જેવું જ છે.
પસંદગી લખી રાખો જેથી પુનર્બાંધણી તેને રદ કરી ન શકે
પરિમાણ ફાઇલને ગોઠવણી વ્યવસ્થાપન હેઠળ રાખો અને બાજુમાં કદ, કારણ અને તારીખ લખો. પોતાના ડિફોલ્ટ ચૂપચાપ બનાવતું ફરી બાંધેલું સર્વર એ જ રીત છે જેનાથી એ જ ભૂલ છ મહિના પછી પાછી આવે છે અને કોઈ મૂળ નિર્ણય સમજાવી શકતું નથી.
એ જ માહિતી એન્ડપોઇન્ટ અને પ્રોફાઇલ પાસે લખો, જેથી સમીક્ષાએ તેને ફાઇલના કદમાંથી ફરી બનાવવી ન પડે. આગલું જોડાણ અટકે ત્યારે એ નોંધ પાંચ મિનિટની તપાસ અને નવી તપાસ વચ્ચેનો ફરક છે. તે આગલા ઇજનેરને ઝડપી કિસ્સા માટે બનાવેલા ઉપાયથી ધીમો કિસ્સો ઉકેલતા પણ રોકે છે.