મોટી OpenVPN કી રીકી ટાઇમરને કેમ દૂર કરતી નથી

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

સાયફરને અડકતા પહેલાં રીકી સેટિંગ્સ વાંચો, અને એ કરતી વખતે બંને બાજુ વાંચો.

કીની તાકાત અને કીનું આયુષ્ય જુદા જુદા પ્રશ્નોના જવાબ આપે છે

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

ડિપ્લોયમેન્ટ નોંધમાં બંને લખો: ડેટા ચેનલને શું સુરક્ષિત રાખે છે અને તેની કીઓની જગ્યાએ નવી કી ક્યારે આવે છે.

રીકીને ત્રણ ટ્રિગર છે, અને કોઈપણ બાજુ તેમને ચાલુ કરી શકે છે

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

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

રીકી પ્રમાણીકરણ પ્રવાહને ઉઘાડી પાડે છે

ફરી વાટાઘાટ એ નવું TLS હેન્ડશેક છે, એટલે પ્રમાણીકરણનો માર્ગ ફરી ચાલે છે. એકવારના કોડ, હાર્ડવેર ટોકન કે RADIUS પડકાર વાપરતા ડિપ્લોયમેન્ટ આ અઘરી રીતે જાણે છે: પહેલું જોડાણ કામ કરે છે અને એક કલાક પછી સેશન મરી જાય છે, જ્યારે બીજું હેન્ડશેક પહેલેથી વપરાયેલો કોડ માંગે છે. auth-gen-token એ ખાલી જગ્યા પૂરવા માટે છે, જેથી સર્વર નવું ઇન્ટરેક્ટિવ લોગિન માંગવાને બદલે ફરી વાટાઘાટ માટે ટૂંકા ગાળાનું ટોકન આપી શકે.

આને ઓપરેટર સાથે ઉકેલવાની વર્કફ્લો સમસ્યા ગણો, નવીકરણ બંધ કરવું જોઈએ તેવો પુરાવો નહીં.

નવીકરણ ભાર હેઠળ ચકાસો, એક મિનિટના સેશનમાં નહીં

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

સફળ મોટા ટ્રાન્સફરને ક્રિપ્ટોગ્રાફિક મર્યાદાનો પુરાવો ન ગણો. તે ફક્ત દર્શાવે છે કે માર્ગ અને ગણકોએ એટલો ટ્રાફિક સહન કર્યો.

બંને પસંદગી દસ્તાવેજ કરો

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

જો સુસંગતતા અપવાદ ફરજિયાત કરે, તો તેને એક આવૃત્તિ અને એક અંતિમ તારીખ સુધી મર્યાદિત કરો. જે અપવાદ પોતાના કારણથી વધુ જીવે છે તે એ નીતિ બની જાય છે જે કોઈને યાદ નથી કે તેણે પસંદ કરી હતી.