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

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

ત્રણ પ્રકારની ફરી વપરાય તેવી સામગ્રી

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

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

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

MaterialTypical lifetimeWhat invalidates it
Cached passwordUntil changedAccount or password policy change
Session tokenMinutes to hoursExpiry, revocation, reauthentication policy
Tunnel SA or TLS ticketConfigured rekey intervalRekey, network change, peer restart

કી નવીકરણ એ ફરી પ્રમાણીકરણ નથી

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

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

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

જ્યારે ક્લાયન્ટ નવો પડકાર પૂરો કરી શકતો નથી

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

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

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

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

શું જાણ કરવી અને શું બંધ ન કરવું

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

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

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

સંબંધિત લેખો