ਮੇਰਾ 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]*"

ਟਨਲ ਵਾਰ-ਵਾਰ ਰੀਸੈਟ ਹੋਵੇ ਤਾਂ ਕਿਸੇ ਵੀ ਥ੍ਰੂਪੁਟ ਅੰਕੜੇ ਦੀ ਵਿਆਖਿਆ ਤੋਂ ਪਹਿਲਾਂ ਕਟੌਤੀਆਂ ਠੀਕ ਕਰੋ, ਕਿਉਂਕਿ ਦੁਬਾਰਾ ਜੁੜਨ ਵਾਲੀ ਟਨਲ ਰਾਹ ਨਹੀਂ, ਹੈਂਡਸ਼ੇਕ ਮਾਪਦੀ ਹੈ। ਹਰ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਮੂਲ ਕੰਮ ਦੁਹਰਾਓ ਅਤੇ ਨਤੀਜਾ ਰੱਖੋ। ਤੇਜ਼ ਸਪੀਡ ਟੈਸਟ ਜੋ ਅਜੇ ਵੀ ਕਾਲ ਤੋੜਦਾ ਹੈ, ਉਹ ਸ਼ਿਕਾਇਤ ਹੱਲ ਨਹੀਂ ਕੀਤੀ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ।