keepalive એ પુનઃકનેક્શન નથી: તમારી પાસે જે નિષ્ફળતા છે તેના આધારે પસંદ કરો

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

જ્યારે મેપિંગ જ સમસ્યા હોય

માત્ર મિનિટોની શાંતિ પછી મરતો ટનલ સામાન્ય રીતે પીઅર નહીં પણ અનુવાદ એન્ટ્રી ગુમાવે છે. WireGuardનું PersistentKeepalive NAT અને ફાયરવોલ સ્ટેટ માટે અસ્તિત્વમાં છે, અને પ્રોજેક્ટની પોતાની નોંધો તેને બરાબર એ જ રીતે વર્ણવે છે, આરોગ્ય-તપાસ તરીકે નહીં. થોડા દસક સેકન્ડનું અંતરાલ એન્ટ્રીને ગરમ રાખે છે, જ્યારે દર સેકન્ડે એક પેકેટ બેટરીનો નિર્ણય છે, વિશ્વસનીયતાનો નહીં. OpenVPN એ જ જગ્યાએ પહોંચે છે ping અને ping-restart દ્વારા, જે પહેલા શાંતિ નોંધે છે અને પછી તેના પર કાર્ય કરે છે.

આ સેટિંગ્સ પ્રોટોકોલ વચ્ચે પણ અદલાબદલી કરી શકાય તેવી નથી. IKEv2ની મૃત-પીઅર નીતિ, OpenVPNનું ping ટાઇમર અને WireGuardનું keepalive એક જ પ્રશ્નનો જવાબ ત્રણ જુદી સિન્ટેક્સ અને ત્રણ જુદા ડિફોલ્ટ સાથે આપે છે, તેથી તેમની વચ્ચે સંખ્યા નકલ કરવી એ ટ્યુનિંગના વેશમાં અટકળ છે.

જ્યારે સંબંધ ગયો હોય

જો પીઅર સરનામું બદલે, ક્રેડેન્શિયલની મુદત પૂરી થાય અથવા દૂરનું છેડું ફરી શરૂ થાય, તો નાના પેકેટ સમારકામ નથી. પુનઃકનેક્શનને સ્ટેટ ફરી બાંધવું પડશે : સરનામું મેળવો, રૂટ ફરી સ્થાપિત કરો, કી ફરી વાટાઘાટ કરો અને કેટલાક ડિપ્લોયમેન્ટમાં વપરાશકર્તાને ફરી પ્રમાણિત કરો.

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

બંનેમાંથી કોઈ શું સાબિત કરતું નથી

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

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

સીધા ટ્રાફિકને અવરોધવો એ અલગ નિર્ણય છે

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

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

નીતિ લખો, ફક્ત સંખ્યા નહીં

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

મર્યાદાઓ વિશે WireGuardની નોંધો એ ઉપયોગી યાદ છે કે keepalive મધ્ય-બોક્સ માટેનો આડમાર્ગ છે, જીવંતતાની સામાન્ય ડિઝાઇન નહીં. જે સમસ્યાને તે હલ કરી શકતું નથી તેના જવાબમાં આવર્તન વધારતા પહેલા તે મર્યાદા વાંચો.