VPN ਸਰਵਰ ਲੋਡ ਦੀ ਵਿਆਖਿਆ: ਵਰਤੋਂਕਾਰ, CPU ਜਾਂ ਅਪਲਿੰਕ?
ਘੱਟ ਲੋਡ ਸਕੋਰ ਦਾ ਮਤਲਬ ਵਿਹਲੇ ਵਰਤੋਂਕਾਰ, ਬਚਿਆ CPU ਜਾਂ ਚੌੜਾ ਅਪਲਿੰਕ ਹੋ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਤੇਜ਼ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ loadavg, ਇੰਟਰਫੇਸ ਕਾਊਂਟਰ ਅਤੇ ਸਟੇਟਸ ਫਾਈਲ ਪੜ੍ਹੋ।
0.4 ਲੋਡ 'ਤੇ ਬੈਠਾ ਗੇਟਵੇ ਆਪਣੇ ਪਿੱਛੇ ਦੇ ਹਰ ਵਰਤੋਂਕਾਰ ਲਈ ਅਜੇ ਵੀ ਰੇਂਗ ਸਕਦਾ ਹੈ। ਔਸਤ ਲੋਡ ਉਹਨਾਂ ਕੰਮਾਂ ਨੂੰ ਗਿਣਦਾ ਹੈ ਜੋ ਚਲਾਏ ਜਾ ਸਕਦੇ ਹਨ ਜਾਂ ਜੋ ਅਟੁੱਟ ਨੀਂਦ ਵਿੱਚ ਫਸੇ ਹੋਏ ਹਨ, ਅਤੇ ਚਾਰ ਕੋਰ ਵਾਲੇ ਹੋਸਟ 'ਤੇ ਇੱਕੋ ਸੰਤ੍ਰਿਪਤ ਪ੍ਰਕਿਰਿਆ ਇਸਨੂੰ 1.0 ਵੱਲ ਧੱਕਣ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਜਦੋਂ ਤਿੰਨ ਕੋਰ ਵਿਹਲੇ ਬੈਠੇ ਹੁੰਦੇ ਹਨ। ਉਸ ਸੰਖਿਆ ਨੂੰ ਰਾਖਵਾਂ ਹੋਣ ਵਜੋਂ ਪੜ੍ਹਨਾ ਐਂਡਪੌਇੰਟ ਚੋਣ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ ਹੈ। ਟਨਲ ਨੂੰ ਅਸਲ ਵਿੱਚ ਸੀਮਤ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਚਾਰ ਵਿੱਚੋਂ ਇੱਕ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਰੁੱਝਿਆ ਕੋਰ, ਅਪਲਿੰਕ, ਇਸਦੇ ਅੱਗੇ ਦੀ ਕਤਾਰ, ਜਾਂ ਕੋਈ ਅਜਿਹੀ ਪ੍ਰਤੀ-ਸੈਸ਼ਨ ਨੀਤੀ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਕੀਤਾ।
ਔਸਤ ਲੋਡ ਕੰਮ ਗਿਣਦਾ ਹੈ, ਥ੍ਰੂਪੁਟ ਨਹੀਂ
ਕਰਨਲ ਰਨ ਕਿਊ ਅਤੇ ਇਨਪੁਟ-ਆਉਟਪੁਟ ਦੀ ਉਡੀਕ ਕਰ ਰਹੇ ਕੰਮਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਨਮੂਨੇ ਲੈਂਦਾ ਹੈ, ਫਿਰ ਦੋਵਾਂ ਨੂੰ ਇੱਕ, ਪੰਜ ਅਤੇ ਪੰਦਰਾਂ ਮਿੰਟਾਂ ਵਿੱਚ ਸਮਤਲ ਕਰਦਾ ਹੈ। ਉਸ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਬਾਈਟ, ਪੈਕੇਟ ਜਾਂ ਟਨਲ ਦਾ ਕੋਈ ਜ਼ਿਕਰ ਨਹੀਂ ਹੈ। ਜਿਸ ਹੋਸਟ ਦਾ ਸਟੋਰੇਜ ਅਟਕ ਗਿਆ ਹੈ ਉਹ ਲਗਭਗ ਕੋਈ ਟ੍ਰੈਫਿਕ ਤੋਂ ਬਿਨਾਂ ਉੱਚਾ ਲੋਡ ਦੱਸ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਰਨਲ ਡੇਟਾ ਮਾਰਗ ਰਾਹੀਂ ਗੀਗਾਬਿਟ ਧੱਕਣ ਵਾਲਾ ਹੋਸਟ ਆਰਾਮਦਾਇਕ ਲੋਡ ਦੱਸ ਸਕਦਾ ਹੈ।
ਇਸ ਲਈ ਲੋਡ ਨੂੰ ਟਨਲ ਪ੍ਰਦਰਸ਼ਨ ਨਾਲ ਜੋੜਨ ਲਈ ਪ੍ਰਤੀ-ਕੋਰ ਨਜ਼ਰ ਚਾਹੀਦੀ ਹੈ। ਜੇ ਇੱਕ ਕੋਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰਿਆ ਹੈ, ਤਾਂ ਡੈਸ਼ਬੋਰਡ 'ਤੇ ਕੁੱਲ ਪ੍ਰਤੀਸ਼ਤ ਅਜੇ ਵੀ ਠੀਕ ਦਿਸੇਗਾ:
cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20ਤੀਜਾ ਕਮਾਂਡ VPN ਹੋਸਟਾਂ 'ਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਹੈ। OpenVPN 2.x ਵਿੱਚ ਵਰਤੋਂਕਾਰ ਸਪੇਸ ਵਿੱਚ ਪੈਕੇਟ ਪ੍ਰੋਸੈਸਿੰਗ ਬਹੁਤ ਹੱਦ ਤੱਕ ਪ੍ਰਤੀ ਪ੍ਰਕਿਰਿਆ ਕ੍ਰਮਬੱਧ ਹੈ, ਇਸ ਲਈ ਇੱਕੋ ਰੁੱਝਿਆ ਥ੍ਰੈਡ ਉੱਪਰੀ ਸੀਮਾ ਬਣ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਡੈਸ਼ਬੋਰਡ ਬਹੁਤ ਸਾਰੀ ਵਿਹਲੀ ਸਮਰੱਥਾ ਦੱਸਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਹੌਲੀ ਸਮੇਂ ਦੌਰਾਨ ਇੱਕ ਥ੍ਰੈਡ ਕੋਰ ਦਾ ਬਹੁਤਾ ਹਿੱਸਾ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਹੋਸਟ ਕੁੱਲ ਮਿਲਾ ਕੇ ਘੱਟ ਸੁਸੱਜਿਤ ਨਹੀਂ; ਇਹ ਉਸ ਆਯਾਮ ਵਿੱਚ ਸੀਮਤ ਹੈ ਜੋ ਸੰਜੋਗ ਨਾਲ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਸਮੇਂ ਵੱਲ ਵੀ ਧਿਆਨ ਦਿਓ। ਪੰਦਰਾਂ ਮਿੰਟ ਦੀ ਔਸਤ ਉਸ ਧਮਾਕੇ ਨੂੰ ਲੁਕਾਉਂਦੀ ਹੈ ਜਿਸਨੇ ਕਾਲ ਬਰਬਾਦ ਕੀਤੀ, ਇਸ ਲਈ ਸ਼ਿਕਾਇਤ ਤੋਂ ਬਾਅਦ ਲਿਆ ਸਕ੍ਰੀਨਸ਼ਾਟ ਕਮਜ਼ੋਰ ਸਬੂਤ ਹੈ। ਸਮੱਸਿਆ ਦੌਰਾਨ ਨਮੂਨੇ ਲਓ, ਅਤੇ ਆਉਟਪੁੱਟ ਨਾਲ ਸਮਾਂ-ਛਾਪ ਰੱਖੋ।
ਅਪਲਿੰਕ ਅਤੇ ਇਸਦੇ ਅੱਗੇ ਦੀ ਕਤਾਰ
ਇੰਟਰਫੇਸ ਕਾਊਂਟਰ ਬੈਂਡਵਿਡਥ ਦੇ ਉਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ ਜੋ CPU ਦੇ ਅੰਕੜੇ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਉਹ ਸਮਰੱਥਾ ਨੂੰ ਨੁਕਸਾਨ ਤੋਂ ਵੀ ਵੱਖ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਵੱਖਰੇ ਉਪਾਵਾਂ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਹਨ:
ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmitਤੁਹਾਡੇ ਟੈਸਟ ਦੌਰਾਨ ਆਪਣੇ ਨਿਰਧਾਰਤ ਦਰ ਦੇ ਨੇੜੇ ਬੈਠਾ ਲਿੰਕ ਹੀ ਵਿਆਖਿਆ ਹੈ, ਅਤੇ ਬਚੇ CPU ਦੀ ਕੋਈ ਵੀ ਮਾਤਰਾ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲਦੀ। qdisc ਲਾਈਨ ਉਹ ਵੇਰਵਾ ਜੋੜਦੀ ਹੈ ਜੋ ਇੰਟਰਐਕਟਿਵ ਟ੍ਰੈਫਿਕ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਬੈਕਲਾਗ ਅਤੇ ਡ੍ਰੌਪ ਦੱਸਦੇ ਹਨ ਕਿ ਪੈਕੇਟ ਨਿਕਲਣ ਤੋਂ ਪਹਿਲਾਂ ਕਤਾਰ ਵਿੱਚ ਉਡੀਕਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਭਾਰੀ ਅਪਲੋਡ ਹੇਠ ਭਰਨ ਵਾਲੀ ਕਤਾਰ ਉਹੀ ਲੱਛਣ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਿਸਦਾ ਦੋਸ਼ ਲੋਕ ਦੂਰ ਦੇ ਸਰਵਰ 'ਤੇ ਪਾਉਂਦੇ ਹਨ, ਭਾਵ ਅਜਿਹੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਹੌਲੀ ਕਾਲਾਂ ਜੋ ਬੈਂਚਮਾਰਕ ਵਿੱਚ ਅਜੇ ਵੀ ਚੰਗਾ ਦਿਸਦਾ ਹੈ।
ਮੁੜ-ਭੇਜਣ ਕਾਊਂਟਰ ਉਹ ਸਥਿਤੀ ਫੜਦੇ ਹਨ ਜਿੱਥੇ ਪੈਕੇਟ ਨਿਕਲਦੇ ਹਨ ਪਰ ਕਦੇ ਸਾਫ਼ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਜੇ ਹੌਲੀ ਵਿੰਡੋ ਵਿੱਚ ਮੁੜ-ਭੇਜਣ ਵਧਦੇ ਹਨ ਅਤੇ ਇੰਟਰਫੇਸ ਸਮਰੱਥਾ ਦੇ ਨੇੜੇ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਹੋਸਟ 'ਤੇ ਨਹੀਂ ਮਾਰਗ ਵਿੱਚ ਹੈ, ਅਤੇ ਉਸੇ ਸ਼ਹਿਰ ਵਿੱਚ ਦੂਜੇ ਐਂਡਪੌਇੰਟ 'ਤੇ ਜਾਣ ਨਾਲ ਮਦਦ ਨਹੀਂ ਹੋਵੇਗੀ।
ਸੈਸ਼ਨ ਗਿਣਤੀ ਮੰਗ ਦੱਸਦੀ ਹੈ, ਰਾਖਵੀਂ ਸਮਰੱਥਾ ਨਹੀਂ
ਹਰ ਜਨਤਕ ਡਾਇਰੈਕਟਰੀ ਕੁਝ ਗਿਣਤੀ ਵਿੱਚ ਜੁੜੇ ਵਰਤੋਂਕਾਰ ਦਿਖਾਉਂਦੀ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਲਗਭਗ ਕੋਈ ਵੀ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਉਹ ਵਰਤੋਂਕਾਰ ਕੀ ਕਰ ਰਹੇ ਹਨ। ਇੰਟਰਐਕਟਿਵ ਕੰਮ ਕਰਦੇ ਵੀਹ ਸੈਸ਼ਨ ਅਤੇ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਖਿੱਚਦੇ ਚਾਰ ਸੈਸ਼ਨ ਇੱਕੋ ਹਾਰਡਵੇਅਰ 'ਤੇ ਬਹੁਤ ਵੱਖਰੇ ਲੋਡ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਦੂਜਾ ਨਮੂਨਾ ਵਰਤੋਂਕਾਰ ਗਿਣਤੀ ਵਿੱਚ ਅਦਿੱਖ ਹੈ, ਅਤੇ ਉਹੀ ਇੱਕ ਸ਼ਾਮ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ ਸੈਸ਼ਨ ਗਿਣਤੀ ਨੂੰ ਮੰਗ ਦਾ ਸੰਕੇਤ ਪੜ੍ਹਨਾ ਬਿਹਤਰ ਹੈ, ਕਦੇ ਵੀ ਰਾਖਵੀਂ ਸਮਰੱਥਾ ਬਾਰੇ ਬਿਆਨ ਵਜੋਂ ਨਹੀਂ।
| Number on the page | What it is really measuring | What it cannot tell you |
|---|---|---|
| Connected users | How many sessions hold an address | How much each one is transferring |
| Load or score | Whatever the operator chose to publish | Whether that definition matches your task |
| Uptime | How long since the process started | Current capacity, queue depth or packet loss |
| Distance or ping | Round-trip time on a small probe | Throughput under sustained transfer |
ਜਿਸ ਹੋਸਟ ਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ, ਉੱਥੇ ਸਟੇਟਸ ਫਾਈਲ ਗੁੰਮ ਆਯਾਮ ਦਿੰਦੀ ਹੈ। OpenVPN ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਸਨੈਪਸ਼ਾਟ ਲਿਖਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਬਾਈਟ ਕਾਊਂਟਰ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਦੇਖਣ ਲਈ ਕਾਫ਼ੀ ਹੈ ਕਿ ਕੀ ਇੱਕੋ ਸੈਸ਼ਨ ਪੂਰੇ ਅਪਲਿੰਕ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ:
status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.statusਦਸ ਸਕਿੰਟ ਦੇ ਅੰਤਰਾਲ 'ਤੇ ਦੋ ਨਮੂਨੇ ਉਹਨਾਂ ਸੰਚਿਤ ਗਿਣਤੀਆਂ ਨੂੰ ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਦਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਇਹੀ ਉਹ ਮਾਪ ਹੈ ਜਿਸਦੀ ਥਾਂ ਵਰਤੋਂਕਾਰ ਗਿਣਤੀ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਤੁਸੀਂ ਪਤਾ ਲਗਾਉਂਦੇ ਹੋ ਕਿ ਇੱਕ ਗਲਤ ਕਨਫਿਗਰ ਕੀਤਾ ਕਲਾਇੰਟ ਹਰ ਰਾਤ ਉਸੇ ਘੰਟੇ ਲਿੰਕ ਨੂੰ ਸੰਤ੍ਰਿਪਤ ਕਰਦਾ ਹੈ।
ਪ੍ਰਤੀ-ਸੈਸ਼ਨ ਸੀਮਾਵਾਂ ਨੀਤੀ ਵਿੱਚ ਲੁਕੀਆਂ ਹੁੰਦੀਆਂ ਹਨ
ਸਰਵਰ ਵਿਹਲਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਤੁਹਾਨੂੰ ਬੈਂਡਵਿਡਥ ਦੇਣ ਤੋਂ ਇਨਕਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਦਰ ਸੀਮਾਵਾਂ, ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਬੈਂਡਵਿਡਥ ਸਿਖਰ ਅਤੇ ਟ੍ਰੈਫਿਕ ਆਕਾਰ ਦੇਣਾ ਅਕਸਰ ਸਾਂਝੇ ਨਾਮ ਜਾਂ ਪੂਲ ਅਨੁਸਾਰ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕੋ ਗੇਟਵੇ 'ਤੇ ਦੋ ਵਰਤੋਂਕਾਰ ਬਹੁਤ ਵੱਖਰੇ ਨਤੀਜੇ ਪਾ ਸਕਦੇ ਹਨ। ਕਾਰਜਵਿਧੀ ਸੂਖਮ ਨਹੀਂ, ਪਰ ਬਾਹਰੋਂ ਅਦਿੱਖ ਹੈ ਕਿਉਂਕਿ ਦੋਵਾਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਟਨਲ ਆਮ ਤੌਰ 'ਤੇ ਉੱਠਦਾ ਹੈ।
ਆਕਾਰ ਦੇਣਾ ਟਨਲ ਇੰਟਰਫੇਸ 'ਤੇ ਲੱਭੋ, ਭੌਤਿਕ 'ਤੇ ਨਹੀਂ। ਜਾਂਚੋ ਕਿ ਸੀਮਾ ਵਰਤੋਂਕਾਰ, ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਪਤਾ ਪੂਲ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਟੈਸਟ ਖਾਤਾ ਸੀਮਾ ਰਹਿਤ ਪੂਲ ਵਿੱਚ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਿੱਟਾ ਕੱਢੋਗੇ ਕਿ ਸਰਵਰ ਠੀਕ ਹੈ ਅਤੇ ਸ਼ਿਕਾਇਤ ਕਰਨ ਵਾਲਾ ਵਰਤੋਂਕਾਰ ਗਲਤ ਹੈ। ਉਹ ਸਿੱਟਾ ਕਿਸੇ ਵੀ ਸਿੱਟੇ ਤੋਂ ਵਾਹਵਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਟਿਕਟ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।
ਇੱਕ ਨਿਸ਼ਚਿਤ ਕੰਮ ਨਾਲ ਦੋ ਐਂਡਪੌਇੰਟ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਕਲਾਇੰਟ ਪਾਸੇ ਦਾ ਪ੍ਰਯੋਗ ਅਜੇ ਵੀ ਕਰਨ ਯੋਗ ਹੈ, ਪਰ ਸਿਰਫ਼ ਜੇ ਚਰ ਸਥਿਰ ਹੋਣ। ਉਹੀ ਡਿਵਾਈਸ, ਉਹੀ ਐਕਸੈਸ ਨੈੱਟਵਰਕ, ਉਹੀ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਉਹੀ ਮੰਜ਼ਿਲ ਫਾਈਲ ਵਰਤੋ, ਫਿਰ ਸਮਾਨ ਦੂਰੀ 'ਤੇ ਦੂਜੇ ਐਂਡਪੌਇੰਟ ਵਿਰੁੱਧ ਦੁਹਰਾਓ। ਦੌੜਾਂ ਵਿਚਕਾਰ ਬਦਲਣ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼, ਦਿਨ ਦਾ ਸਮਾਂ ਵੀ ਸ਼ਾਮਲ, ਨਤੀਜੇ ਨੂੰ ਦੂਸ਼ਿਤ ਕਰਦੀ ਹੈ।
ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਫਲਤਾਵਾਂ ਜਿੰਨੀ ਸਾਵਧਾਨੀ ਨਾਲ ਦਰਜ ਕਰੋ। ਜਿਸ ਲੜੀ ਵਿੱਚ ਤਿੰਨ ਐਂਡਪੌਇੰਟ ਚੱਲਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸਮਾਂ-ਸੀਮਾ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ, ਉਹ ਚਾਰ ਗਤੀ ਅੰਕੜਿਆਂ ਤੋਂ ਵੱਧ ਜਾਣਕਾਰੀਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਮਰੱਥਾ ਦੀ ਨਹੀਂ ਸਗੋਂ ਮਾਰਗ ਜਾਂ ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ। ਹਰ ਕੇਸ ਘੱਟੋ-ਘੱਟ ਦੋ ਵਾਰ ਚਲਾਓ; ਸਾਂਝੇ ਨੈੱਟਵਰਕ 'ਤੇ ਇੱਕ ਹੌਲੀ ਨਮੂਨਾ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਅੰਤ ਵਿੱਚ, ਤੁਸੀਂ ਇਕੱਠੇ ਕੀਤੇ ਅੰਕੜੇ ਉਸ ਦਾਅਵੇ ਨਾਲ ਰੱਖੋ ਜਿਸਦਾ ਉਹ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। "ਇਸ ਐਂਡਪੌਇੰਟ ਨੇ ਉਸੇ ਵਿੰਡੋ ਵਿੱਚ ਤਬਾਦਲਾ ਪੂਰਾ ਕੀਤਾ ਜਿਸ ਵਿੱਚ ਦੂਜਾ ਅਟਕ ਗਿਆ ਸੀ" ਬਚਾਅ ਯੋਗ ਹੈ, ਜਦੋਂ ਕਿ "ਇਹ ਐਂਡਪੌਇੰਟ ਤੇਜ਼ ਹੈ" ਉਸ ਬਹਿਸ ਨੂੰ ਸੱਦਾ ਦਿੰਦਾ ਹੈ ਜੋ ਹੋਮਪੇਜ ਸਕੋਰ ਨਾਲ ਨਹੀਂ ਜਿੱਤੀ ਜਾ ਸਕਦੀ। OpenVPN 2.6 ਮੈਨੂਅਲ ਸਟੇਟਸ ਫਾਈਲ ਅਤੇ ਆਕਾਰ ਦੇਣ ਵਾਲੇ ਵਿਕਲਪਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ, ਜੇ ਤੁਹਾਨੂੰ ਹੋਸਟ ਪਾਸੇ ਦੀਆਂ ਸਹੀ ਹਦਾਇਤਾਂ ਚਾਹੀਦੀਆਂ ਹਨ।