તમારું VPN વિક્ષેપ કરતાં વધુ સમય કેમ લે છે પુનઃપ્રાપ્ત થવામાં

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

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

એક જેવા દેખાતા ત્રણ વિલંબ

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

લોગમાં એક શાંત મિનિટ એ જરૂરી નથી કે થીજી ગયેલી પ્રક્રિયા હોય. એ ઘાતાંકીય બેકઓફ હોઈ શકે છે જે બરાબર એ જ કરે છે જેના માટે તેને ગોઠવવામાં આવ્યું હતું.

ખરેખર કયો તબક્કો ધીમો છે?

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

કોઈ સંખ્યાને સ્પર્શ કરતા પહેલા નિષ્ફળતાનું વર્ગીકરણ કરો.

ટાઈમર ઘટાડવો ક્યારે મદદ કરે છે અને ક્યારે નહીં

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

દરેક પ્રોફાઇલમાં કોપી કરેલો ખૂબ નીચો સમયમર્યાદા એ માપન વિના ગોઠવણની સામાન્ય અંતિમ સ્થિતિ છે.

ક્લાયન્ટને દોષ આપતા પહેલા તૈયારી ચકાસો

કંઈક પ્રયાસ કરે ત્યાં સુધી ક્લાયન્ટ ઘણી વાર જોઈ શકતું નથી કે નેટવર્ક વાપરી શકાય તેવું છે. કેપ્ટિવ પોર્ટલ, DHCP નવીકરણ અથવા રૂટ ફેરફાર તેને એ પહેલા સેટ કરેલા સમયપત્રક પર રાહ જોવા માટે મૂકી શકે છે. ઑપરેટિંગ સિસ્ટમના નેટવર્ક સ્થિતિના ફેરફાર અને ક્લાયન્ટના આગલા પ્રયાસને એક જ ઘડિયાળ પર જુઓ, અને તમે જોશો કે કોની રાહ છે. ઝડપી આવૃત્તિ એ છે કે નેટવર્ક-તૈયાર ઘટનાનો સમયછાપ અને તેના પછીના પ્રથમ પ્રયાસનો સમયછાપ નોંધવો.

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

શું નોંધવું

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

એ નોંધ આગલા સૉફ્ટવેર અપગ્રેડને પ્રયોગને બદલે સરખામણીમાં ફેરવે છે.