OpenVPN પછી OTP સત્ર છોડી દે છે: ફરી પ્રમાણીકરણને શું જોઈએ

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

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

ક્લાયન્ટના દૃષ્ટિકોણથી આદાનપ્રદાનને અનુસરો

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

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

auth-gen-token બદલે છે કે બીજા પ્રશ્નનો જવાબ કોણ આપે

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

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

ખાતાની સ્થિતિનું શું થાય તે નક્કી કરો

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

બહુ-સર્વર જમાવટમાં ટોકન સહી કરવાની ગુપ્તતા વહેંચવી પડે, નહીં તો ક્લાયન્ટને એવા નોડ પર મોકલી શકાય જે તેનું ટોકન ચકાસી શકતું નથી.

માત્ર લોગિન નહીં, સમાપ્તિ અને ફરી જોડાણની કસોટી કરો

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

ખાતું દૂર કરવાની કસોટી સૌથી છેલ્લે કરો. તે કિસ્સો તમને કહે છે કે તમે લખેલી નીતિ અમલમાં મુકાય છે કે માત્ર દસ્તાવેજીકૃત છે.

નવીકરણ બંધ કરીને તેને ઠીક ન કરો

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

લાંબો ફરી પ્રયાસ ટાઇમર વપરાયેલ કોડને ફરી માન્ય બનાવતો નથી. તે ફક્ત ડિસ્કનેક્શનમાં વિલંબ કરે છે અને લોગ વાંચવાનું મુશ્કેલ બનાવે છે.