મારું VPN આટલું ધીમું કેમ છે? આ ચાર ભાગ ચકાસો

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

નીચેનો ક્રમ કાર્યથી બહાર તરફ જાય છે, કારણ કે ટનલ તેની નીચે ખૂટતી બેન્ડવિડ્થ આપી શકતી નથી.

માપતાં પહેલાં નક્કી કરો કે ધીમું એટલે શું

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

તે નોંધ વિના, પછીની દરેક સરખામણી છાપ વિશેની દલીલ બની જાય છે.

પહેલા એક્સેસ નેટવર્ક તપાસો

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

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

જો બેઝલાઇન પહેલેથી જ ખરાબ હોય, તો કામ Wi-Fi, રાઉટરની માંગ કે એક્સેસ સેવાનું છે. વાયરવાળી કસોટી કે એક્સેસ પોઇન્ટ નજીક સ્થિર સ્થિતિ નબળી રેડિયો લિંકને ભીડવાળી અપલિંકથી અલગ પાડે છે. ટનલ જે કંઈ કરે તે એ ક્ષમતા ઉમેરશે નહીં જે એક્સેસ લાઇન આપતી નથી.

એક્ઝિટ બદલો, પછી ટ્રાન્સપોર્ટ

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

જ્યાં સેવા બંને પ્રોફાઇલ આપે છે, ત્યાં UDP પર OpenVPN ને TCP પર OpenVPN સાથે સરખાવો. ઇન્ટરેક્ટિવ કામ માટે UDP સામાન્ય શરૂઆતનું બિંદુ છે, જ્યારે TCP એવા એક્સેસ નેટવર્ક પર મદદ કરી શકે જે UDP ટ્રાફિક બિલકુલ પસાર કરતું નથી. TCP ટનલ સ્ટ્રીમની અંદર ફરી મોકલીને નુકસાન પુનઃપ્રાપ્ત કરે છે, તેથી પેકેટ પાડતી લિંક પર તે ધીમું લાગી શકે છે, અને OpenVPN કામગીરી સમસ્યાનિવારણ નોંધ બીજું કંઈ ગોઠવતાં પહેલાં એ જ આપલે સમજાવે છે. પ્રોફાઇલમાં "udp" શબ્દને "tcp"માં બદલવાથી એવું શ્રોતા બની શકતું નથી જે સર્વરે કદી ખોલ્યું ન હોય.

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

ઉપકરણ અને લક્ષણ સાથે વાંચો

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

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

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