ਸਫ਼ੇ ਲੋਡ ਹੁੰਦੇ ਹਨ ਪਰ VPN 'ਤੇ ਅੱਪਲੋਡ ਰੁਕ ਜਾਂਦੇ ਹਨ: ਕਿਹੜਾ ਕਾਰਨ ਜਿੱਤਦਾ ਹੈ
ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਰੁਕਾਵਟ ਪਾਥ MTU ਖਰਾਬੀ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ, ਅਤੇ DNS, ਐਪ ਸੀਮਾ ਜਾਂ ਅਸਥਿਰ ਟਨਲ ਨਾਲ ਵੀ ਮੇਲ ਖਾਂਦੀ ਹੈ। ਚਾਰ ਨਿਰੀਖਣ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਕਿਹੜਾ।
ਸਫ਼ੇ ਲੋਡ ਹੁੰਦੇ ਹਨ, VPN ਜੁੜਿਆ ਹੋਣ ਦੀ ਸੂਚਨਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫ਼ਾਈਲ ਅੱਪਲੋਡ ਹਰ ਵਾਰ ਉਸੇ ਥਾਂ 'ਤੇ ਜੰਮ ਜਾਂਦਾ ਹੈ। ਇਸ ਵਰਣਨ ਨਾਲ ਚਾਰ ਵਿਆਖਿਆਵਾਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ: ਪੈਕਟ ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ, ਨਾਮ-ਹੱਲ ਦੀ ਸਮੱਸਿਆ, ਐਪ ਦੀ ਸੀਮਾ ਅਤੇ ਲਗਾਤਾਰ ਮੁੜ-ਸੈੱਟ ਹੁੰਦੀ ਟਨਲ। ਹਰ ਇੱਕ ਨੂੰ ਵੱਖਰੇ ਨਿਰੀਖਣ ਨਾਲ ਸਿੱਧ ਜਾਂ ਰੱਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਫ਼ੈਸਲਾ ਕਾਰਨ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਨਹੀਂ, ਸਗੋਂ ਸਹੀ ਪਰਖ ਚੁਣਨਾ ਹੈ।
ਚਾਰ ਉਮੀਦਵਾਰ ਅਤੇ ਇੱਕ ਆਕਾਰ
ਅਸਫਲਤਾ ਦੇ ਆਕਾਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਸੰਦ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸੂਚੀ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਸਥਿਰ ਆਕਾਰ 'ਤੇ ਹੋਣ ਵਾਲੀ ਰੁਕਾਵਟ ਉਲਟਾ ਸਿੱਧ ਹੋਣ ਤੱਕ ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਬੇਤਰਤੀਬ ਥਾਵਾਂ 'ਤੇ ਹੋਣ ਵਾਲੀ ਰੁਕਾਵਟ ਨੁਕਸਾਨ ਜਾਂ ਸਥਿਰਤਾ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਜੁੜਾਅ ਖੁੱਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਅਸਫਲਤਾ ਨਾਮ ਦੀ ਸਮੱਸਿਆ ਹੈ।
ਚੌਥਾ ਉਮੀਦਵਾਰ ਐਪ ਹੈ। ਅੱਪਲੋਡ ਸੀਮਾਵਾਂ, ਬੇਨਤੀਆਂ ਦੇ ਸਮੇਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਅਤੇ ਪ੍ਰੌਕਸੀ ਦੀ ਬਾਡੀ-ਆਕਾਰ ਸੀਮਾ ਅਜਿਹੀਆਂ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਨੈੱਟਵਰਕ ਖਰਾਬੀ ਵਰਗੀਆਂ ਦਿਸਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਰੁਕਣ ਦੀ ਥਾਂ ਇਨਕਾਰ ਵਜੋਂ ਆਉਂਦੀਆਂ ਹਨ।
ਕੁਝ ਵੀ ਪਰਖਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇਖਿਆ ਗਿਆ ਆਕਾਰ ਲਿਖ ਲਓ। "ਲਗਭਗ ਉਸੇ ਬਾਈਟ ਗਿਣਤੀ 'ਤੇ, ਹਰ ਵਾਰ, ਟਨਲ ਚਾਲੂ ਹੁੰਦਿਆਂ ਰੁਕ ਜਾਂਦਾ ਹੈ" — "ਅੱਪਲੋਡ ਕੰਮ ਨਹੀਂ ਕਰਦੇ" ਤੋਂ ਕਿਤੇ ਵੱਧ ਮਜ਼ਬੂਤ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਹੈ।
ਫਿਰ ਪਰਖ ਦੌਰਾਨ ਪਾਥ ਸਥਿਰ ਰੱਖੋ। ਐਗਜ਼ਿਟ, ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਸਰਵਰ ਇਕੱਠੇ ਬਦਲਣ ਨਾਲ ਅਜਿਹਾ ਨਤੀਜਾ ਮਿਲਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ ਨਹੀਂ ਦੇ ਸਕਦੇ। ਪ੍ਰਤੀ ਦੌੜ ਇੱਕ ਚਰ, ਅਤੇ ਉਹ ਲਿਖ ਲਓ।
ਨੀਤੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਆਕਾਰ ਅੱਧਾ ਕਰੋ
ਸਭ ਤੋਂ ਸਸਤਾ ਭੇਦਕ ਉਹ ਪ੍ਰੋਬ ਹੈ ਜੋ ਇੱਕ ਸੰਖਿਆ ਬਦਲਦਾ ਹੈ। ਮੰਜ਼ਿਲ ਵੱਲ ਵਧਦੇ ਆਕਾਰ ਦੇ, ਟੁਕੜੇ-ਰਹਿਤ ਪਿੰਗ ਭੇਜੋ, ਅਤੇ ਤੁਸੀਂ ਜਿਸ ਫ਼ਾਈਲ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ ਉਹ ਉਸੇ ਸੇਵਾ 'ਤੇ ਅੱਪਲੋਡ ਕਰੋ, ਫਿਰ ਤੁਲਨਾ ਕਰੋ ਕਿ ਹਰ ਇੱਕ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ।
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadਪਹਿਲਾ ਕਮਾਂਡ ਦੱਸਦਾ ਹੈ ਕਿ ਪੂਰੇ ਆਕਾਰ ਦਾ ਪੈਕਟ ਪਾਥ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। 1500 ਬਾਈਟ MTU 'ਤੇ, ਜੋ ICMP ਪੇਲੋਡ ਟੁਕੜਿਆਂ ਵਿੱਚ ਨਹੀਂ ਵੰਡਿਆ ਜਾਂਦਾ ਉਸਦਾ ਵੱਧ ਤੋਂ ਵੱਧ ਆਕਾਰ 1472 ਬਾਈਟ ਹੈ, ਅਤੇ ਅੰਦਰਲਾ ਪੈਕਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਉਸ ਬਜਟ ਵਿੱਚੋਂ ਹੋਰ ਲੈ ਲੈਂਦੀ ਹੈ। ਦੂਜਾ ਐਪ-ਪੱਧਰ ਦੀ ਟ੍ਰਾਂਸਫਰ ਲਈ ਆਕਾਰ ਅਤੇ ਸਮਾਂ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਗਿਣਤੀ ਉਹੀ ਹੈ।
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
ਦੋਵੇਂ ਇਕੱਠੇ ਪੜ੍ਹੋ। ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਉੱਪਰ ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਪ੍ਰੋਬ ਅਤੇ ਉਸੇ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੇੜੇ ਰੁਕਣ ਵਾਲਾ ਅੱਪਲੋਡ — ਇਹ ਸੁਸੰਗਤ ਕਹਾਣੀ ਹੈ। ਸਾਰੇ ਪ੍ਰੋਬ ਸਫਲ ਹੋਣ ਪਰ ਅੱਪਲੋਡ ਉਸ ਬਾਈਟ ਗਿਣਤੀ 'ਤੇ ਰੁਕੇ ਜਿਸਨੂੰ ਪਾਥ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਢੋਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਐਪ ਜਾਂ ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ MTU ਦਾ ਕਿੰਨਾ ਵੀ ਕੰਮ ਇਸਨੂੰ ਨਹੀਂ ਬਦਲੇਗਾ। ਉਹ ਨਕਾਰਾਤਮਕ ਨਤੀਜਾ ਸਕਾਰਾਤਮਕ ਜਿੰਨਾ ਹੀ ਕੀਮਤੀ ਹੈ। ਇਹ ਜਾਂਚ ਦੀ ਸਭ ਤੋਂ ਮਹਿੰਗੀ ਸ਼ਾਖਾ ਹਟਾ ਦਿੰਦਾ ਹੈ।
ਫਿਰ ਟ੍ਰਾਂਸਫਰ ਦੌਰਾਨ ਸਥਿਰਤਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਵੱਡੇ ਅੱਪਲੋਡ ਦੇ ਵਿਚਕਾਰ ਕੁੰਜੀ ਨਵੀਨੀਕਰਨ ਕਰਨ ਵਾਲੀ ਟਨਲ ਆਕਾਰ-ਨਿਰਭਰ ਦਿਸਣ ਵਾਲੀ ਪਰ ਨਾ ਹੋਣ ਵਾਲੀ ਅਸਫਲਤਾ ਪੈਦਾ ਕਰਦੀ ਹੈ। ਅੱਪਟਾਈਮ ਪੜ੍ਹਨਾ ਇਸਨੂੰ ਸਿੱਧ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਸਸਤਾ ਤਰੀਕਾ ਹੈ।
ਮੁਰੰਮਤ ਅਤੇ ਵਿਕਲਪੀ ਹੱਲ ਵਿਚਕਾਰ ਫ਼ੈਸਲਾ ਕਰੋ
ਜੇ ਸਬੂਤ ਆਕਾਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਦੋ ਇਮਾਨਦਾਰ ਜਵਾਬ ਅਤੇ ਇੱਕ ਬੇਈਮਾਨ ਜਵਾਬ ਹੈ। ਇਮਾਨਦਾਰ ਇਹ ਹਨ: ਲੋੜੀਂਦੇ ICMP ਫੀਡਬੈਕ ਦੀ ਆਗਿਆ ਦੇ ਕੇ ਪਾਥ-MTU ਖੋਜ ਬਹਾਲ ਕਰਨਾ, ਜਾਂ ਘੋਸ਼ਿਤ ਸੈਗਮੈਂਟ ਆਕਾਰ ਸੀਮਿਤ ਕਰਨਾ ਤਾਂ ਜੋ ਸਾਥੀ ਛੋਟੇ ਸੈਗਮੈਂਟ ਭੇਜਣ। ਬੇਈਮਾਨ ਇਹ ਹੈ: ਫੋਰਮ ਤੋਂ ਨਕਲ ਕੀਤੇ ਮੁੱਲ ਤੱਕ ਇੰਟਰਫ਼ੇਸ MTU ਘਟਾਉਣਾ ਅਤੇ ਇਹ ਕਦੇ ਨਾ ਜਾਂਚਣਾ ਕਿ ਇਸਨੇ ਕੀ ਬਦਲਿਆ।
ਚੋਣ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ। ਜਿਸ ਨੈੱਟਵਰਕ ਨੂੰ ਤੁਸੀਂ ਚਲਾਉਂਦੇ ਹੋ, ਉੱਥੇ ICMP ਸੁਨੇਹਿਆਂ ਦੀ ਆਗਿਆ ਦੇਣਾ ਵਧੇਰੇ ਸਾਫ਼ ਸੁਧਾਰ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਵਿਧੀ ਚਾਲੂ ਰੱਖਦਾ ਹੈ। ਜਿਸ ਪਾਥ ਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ, ਉੱਥੇ ਸੀਮਿਤ ਕਰਨਾ ਵਿਹਾਰਕ ਵਿਕਲਪ ਹੈ, ਅਤੇ ਇਹ ਪੂਰੇ ਸਰਵਰ 'ਤੇ ਨਹੀਂ, ਸਗੋਂ ਸੰਕੀਰਣ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਸਬੂਤ ਐਪ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਐਪ ਜਾਂ ਉਸਦੀ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਠੀਕ ਕਰੋ। 413 ਜਵਾਬ ਅਤੇ ਲਟਕਦਾ ਜੁੜਾਅ ਵੱਖਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਹਨ, ਅਤੇ ਦੂਜੀ ਆਮ ਤੌਰ 'ਤੇ ਆਪਣੀਆਂ ਸੀਮਾਵਾਂ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਸਮੇਤ ਲੜੀ ਵਿੱਚ ਕਿਤੇ ਸਮਾਂ-ਸੀਮਾ ਹੁੰਦੀ ਹੈ।
ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਮੂਲ ਮੁੱਲ ਰੱਖੋ ਅਤੇ ਵਾਪਸ ਕਰਨ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਪਰਖੋ। ਸਫਲ ਟ੍ਰਾਂਸਫਰ ਨਾਲ ਮੇਲ ਖਾਣ ਵਾਲਾ ਬਦਲਾਅ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਉਹੀ ਕਾਰਨ ਸੀ, ਅਤੇ ਵਾਪਸ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੀ ਨਿਦਾਨ ਨੂੰ ਸੰਜੋਗ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ।
ਫ਼ੈਸਲਾ ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲੀ ਘਟਨਾ ਤੱਕ ਰਹੇ
ਚਾਰ ਤੱਥ ਕਾਫ਼ੀ ਹਨ: ਦੇਖਿਆ ਗਿਆ ਅਸਫਲਤਾ ਦਾ ਆਕਾਰ, ਪ੍ਰੋਬਾਂ ਦੇ ਨਤੀਜੇ, ਤੁਹਾਡਾ ਕੀਤਾ ਬਦਲਾਅ ਅਤੇ ਮੁੜ-ਪਰਖ ਦਾ ਨਤੀਜਾ। ਇਹਨਾਂ ਨਾਲ ਅਗਲਾ ਵਿਅਕਤੀ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਉਹੀ ਹੈ ਜਾਂ ਉਹੀ ਲੱਛਣ ਵਾਲੀ ਨਵੀਂ।
ਪਾਥ ਦਾ ਸੰਦਰਭ ਵੀ ਨੋਟ ਕਰੋ, ਕਿਉਂਕਿ MTU ਦਾ ਨਤੀਜਾ ਕਿਸੇ ਖਾਸ ਲਿੰਕ ਲਈ ਹੁੰਦਾ ਹੈ। ਘਰ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲਾ ਅਤੇ ਹੋਟਲ ਵਿੱਚ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਲੈਪਟਾਪ ਦੋ ਪਾਥ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਇੱਕ 'ਤੇ ਲਾਗੂ ਸੁਧਾਰ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਅਖ਼ੀਰ ਵਿੱਚ, "VPN ਨੇ ਅੱਪਲੋਡ ਤੋੜ ਦਿੱਤੇ" ਵਾਲੇ ਸਾਰ ਦਾ ਵਿਰੋਧ ਕਰੋ। ਟਨਲ ਕੰਮ ਕਰਨ ਅਤੇ ਅਸਫਲ ਹੋਣ ਦੋਵੇਂ ਹਾਲਤਾਂ ਵਿੱਚ ਮੌਜੂਦ ਸੀ; ਜੋ ਬਦਲਿਆ ਉਹ ਪਾਥ ਨੂੰ ਢੋਣ ਵਾਲੇ ਪੈਕਟ ਦਾ ਆਕਾਰ, ਜਾਂ ਉਹ ਥਾਂ ਜਿੱਥੇ ਟ੍ਰਾਂਸਫਰ ਰੋਕਿਆ ਗਿਆ। ਅਸਲ ਵਿਧੀ ਦਾ ਨਾਮ ਦੇਣਾ ਹੀ ਟਿੱਪਣੀ ਨੂੰ ਲਾਹੇਵੰਦ ਬਣਾਉਂਦਾ ਹੈ।