રીકી, ફરી કનેક્ટ કરવું કે ફરી પ્રમાણીકરણ: તમને કયું જોઈએ?

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

નિર્ણય એના પર આધાર રાખે છે કે ખરેખર કયો સ્તર સમાપ્ત થયો છે.

રોટેશન કહેવાતી ત્રણ ક્રિયાઓ

રીકી હાલના નિયંત્રણ સંબંધની અંદર પ્રોટોકોલ જે પદ્ધતિ નક્કી કરે છે તેનો ઉપયોગ કરીને નવી ટ્રાફિક કી બનાવે છે. IKEv2 આ નવા ચાઇલ્ડ સિક્યોરિટી એસોસિએશન સાથે કરે છે, TLS 1.3 કી અપડેટ સંદેશ સાથે, અને WireGuard તેની સમય કે સંદેશ મર્યાદા પૂરી થાય ત્યારે નવા હેન્ડશેક સાથે. ટનલના સરનામાં અને પ્રમાણિત ઓળખ જ્યાં હતાં ત્યાં જ રહે છે.

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

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

નવીકરણ વખતે વપરાશકર્તા શું નોંધે છે

રીકી લગભગ અદૃશ્ય હોવું જોઈએ. એસોસિએશન ઓળખકર્તા બદલાય છે, કાઉન્ટર રીસેટ થઈ શકે છે, અને એપ્લિકેશનો પોતાના સોકેટ રાખે છે; આદાનપ્રદાન દરમિયાન એક દિશામાં ટૂંકો વિરામ સામાન્ય છે. સ્ટેટસ યાદીમાં નવો ઓળખકર્તા જોવો ખામીનો પુરાવો નથી. આદાનપ્રદાન પછીની લોગ લાઇન જ તમને કહે છે કે તે પૂરું થયું કે નહીં.

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

વ્યવહારમાં ત્રણે ક્યાં અલગ પડે છે

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

પ્રોટોકોલના ડિફોલ્ટમાં સામાન્ય રીતે સાચો જવાબ હોય છે. WireGuard કોઈ વપરાશકર્તા ક્રિયા વિના સમય અને ડેટા-વોલ્યુમ થ્રેશોલ્ડ પછી કી બદલે છે; IKEv2 ના લાઇફટાઇમ દરેક ચાઇલ્ડ એસોસિએશન માટે વાટાઘાટ થાય છે; TLS આધારિત ટનલ હાલના સેશનની અંદર જ કી ફેરવે છે. પુનરાવર્તિત ભૂલ ટાળવા લાઇફટાઇમ વધારવાથી નિષ્ફળતા મોકૂફ રહે છે અને કી લીક થાય તો એક્સપોઝર લાંબું થાય છે.

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

ડિફોલ્ટ પસંદ કરો, પછી તબક્કો નોંધો

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

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

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