બે સેકન્ડનું થીજવું: VPN હતું કે Wi-Fi?

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

બે રેકોર્ડ, એક નહીં

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

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

એપ્લિકેશન થીજેલી હતી ત્યારે એક્સેસ લિંકે શું કર્યું

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

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

ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address show

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

રીસ્ટાર્ટ રેકોર્ડ શોધો

ખોવાયેલું UDP ડેટાગ્રામ પોતાની જાતે Community OpenVPN ને નવી TLS વાટાઘાટ શરૂ કરાવતું નથી. રીસ્ટાર્ટનું વર્તન ping-restart પર આધાર રાખે છે, અને અમલમાં રહેલું મૂલ્ય સર્વરે મોકલ્યું હોઈ શકે; 2.6 માર્ગદર્શિકા એ ટાઈમર વ્યાખ્યાયિત કરે છે. ડિલિવરી એક ક્ષણ માટે તૂટે છે, થ્રેશોલ્ડ ક્યારેય વટાવાતો નથી, અને લોગ ખાલી રહે છે. તેથી વિરામની આસપાસ લોગમાં રીસ્ટાર્ટ લાઈન, નવું કનેક્શન કે બદલાયેલી સત્ર ઓળખ શોધો. ત્રણમાંથી કંઈ જ ન દેખાય તો ટનલે કદાચ કંઈ કર્યું નથી અને ટાઈમર કદી સમસ્યા નહોતું.

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

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

શું સુધારવું તે સરખામણી નક્કી કરે

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

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

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