મોટા અપલોડ દરમિયાન VPN કપાઈ જાય છે: પહેલાં કતાર વાંચો

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

દરેક રનમાં એક ચલ બદલો અને એન્ડપોઇન્ટ સ્થિર રાખો.

પુનરાવર્તનયોગ્ય ભાર સરખામણી બનાવો

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

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

આઉટપુટ સમયછાપ સાથે સાચવો જેથી ભારિત અને નિષ્ક્રિય રન લીટી દીઠ સરખાવી શકાય.

ઝડપ નહીં, કતાર વાંચો

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

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

ઉપકરણ અને નિયંત્રણ માર્ગ તપાસો

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

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

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

એક વસ્તુ બદલો અને ફરો

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

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

નવી વિનંતી અને વપરાશકર્તા ખરેખર જે પુનઃજોડાણ વર્તન પર આધાર રાખે છે તેનું પરીક્ષણ કરીને પૂર્ણ કરો. જે ભારે ફરિયાદ ઊભી કરી તે હેઠળની સ્થિરતા જ નોંધવા લાયક એકમાત્ર પરિણામ છે.