ਕੀ ਛੋਟਾ VPN MTU ਤੇਜ਼ ਹੈ? ਅਸਲ ਸਬੂਤ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਘੱਟ MTU ਰਾਹ ਦੀ ਸੀਮਾ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਥ੍ਰੂਪੁਟ ਦੀ ਕੀਮਤ ਚੁਕਾ ਸਕਦਾ ਹੈ। ਤਬਦੀਲੀ ਰੱਖਣ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲ ਰੁਕਾਵਟ, ਪੈਕਟ ਓਵਰਹੈੱਡ ਅਤੇ ਕੰਮ ਦਾ ਭਾਰ ਤੁਲਨਾ ਕਰੋ।
ਟਨਲ ਵੱਡੀਆਂ ਤਬਦੀਲੀਆਂ ਛੱਡ ਦਿੰਦਾ ਹੈ ਪਰ ਪਿੰਗ ਲੰਘਣ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਸਲਾਹ ਜਲਦੀ ਆਉਂਦੀ ਹੈ: MTU ਘਟਾਓ। ਸੁਧਾਰ ਕਦੇ-ਕਦੇ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਇਹ ਹਰ ਨੈੱਟਵਰਕ ਦੇ ਹਰ ਪ੍ਰੋਫਾਈਲ ’ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉੱਥੇ ਹੀ ਨਿਸ਼ਾਨੇਬਾਜ਼ ਮੁਰੰਮਤ ਸਥਾਈ ਕਾਰਗੁਜ਼ਾਰੀ-ਟੈਕਸ ਬਣ ਜਾਂਦੀ ਹੈ। ਜੋ ਤੁਲਨਾ ਕਰਨੀ ਹੈ ਉਹ ਰਾਹ ਦੀ ਅਸਲ ਸੀਮਾ ਅਤੇ ਉਸ ਤੋਂ ਹੇਠਾਂ ਹਰ ਪੈਕਟ ਛੋਟਾ ਕਰਨ ਦੀ ਲਾਗਤ ਵਿਚਕਾਰ ਹੈ।
MTU ਘਟਾਉਣ ’ਤੇ ਅਸਲ ਵਿੱਚ ਕੀ ਸੁੰਗੜਦਾ ਹੈ
ਹਰ ਪੈਕਟ ਤੁਹਾਡੇ ਡੇਟਾ ਨੂੰ ਲੈ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹੈਡਰ ਲੈ ਜਾਂਦਾ ਹੈ। 1500 ਬਾਈਟ ਦੇ ਈਥਰਨੈੱਟ ਰਾਹ ’ਤੇ IPv4 ਅਤੇ TCP 40 ਬਾਈਟ ਲੈਂਦੇ ਹਨ ਅਤੇ ਪੇਲੋਡ ਲਈ 1460 ਛੱਡਦੇ ਹਨ; ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਉੱਪਰ ਬਾਹਰੀ IP, UDP ਅਤੇ ਟਨਲ ਹੈਡਰ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਪੇਲੋਡ ਬਜਟ ਫਿਰ ਘਟਦਾ ਹੈ। ਇੰਟਰਫੇਸ ਦਾ MTU ਘਟਾਉਣਾ ਉਸ ਬਜਟ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਛੋਟਾ ਕਰਦਾ ਹੈ।
ਲਾਗਤ ਬਾਈਟਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਨਹੀਂ, ਪੈਕਟਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਆਨੁਪਾਤਿਕ ਹੈ। ਉਹੀ ਫਾਈਲ ਹੋਰ ਪੈਕਟਾਂ ਵਿੱਚ ਵੰਡੀ ਜਾਣ ’ਤੇ ਰਾਹ ਦੇ ਹਰ ਜੰਤਰ ’ਤੇ ਵੱਧ ਰੁਕਾਵਟਾਂ, ਵੱਧ ਰੂਟਿੰਗ ਫੈਸਲੇ ਅਤੇ ਪ੍ਰਤੀ ਪੈਕਟ ਵੱਧ ਪ੍ਰੋਸੈਸਿੰਗ ਚਾਹੀਦੀ ਹੈ। ਜੋ ਰਾਊਟਰ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਤੀ ਸਕਿੰਟ ਪੈਕਟ ਸੀਮਾ ਦੇ ਨੇੜੇ ਹੈ, ਉੱਥੇ ਇਹ ਗੋਲਾਈ ਦੀ ਗਲਤੀ ਨਹੀਂ, ਅਸਲ ਧੀਮਾਪਣ ਹੈ। ਤਬਦੀਲੀ ਆਪ ਸਫਲ ਹੋਣ ’ਤੇ ਵੀ ਲਾਗਤ ਦਿਖਦੀ ਹੈ।
ਇਸ ਲਈ ਛੋਟਾ MTU ਰੁਕਾਵਟ ਦੁਆਲੇ ਘੁੰਮਣ ਦਾ ਰਾਹ ਹੈ, ਆਮ ਅਨੁਕੂਲਣ ਨਹੀਂ। ਇਹ ਵੱਡਾ ਫਰੇਮ ਨਾ ਲੈ ਜਾ ਸਕਣ ਵਾਲੇ ਰਾਹ ਦੇ ਮੁਕਾਬਲੇ ਭਰੋਸੇਯੋਗਤਾ ਖਰੀਦਦਾ ਹੈ ਅਤੇ ਜਿਨ੍ਹਾਂ ਪੈਕਟਾਂ ਨੂੰ ਘਟਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ ਉਨ੍ਹਾਂ ਤੋਂ ਓਵਰਹੈੱਡ ਵਸੂਲਦਾ ਹੈ।
ਛੋਟਾ MTU ਕਦੋਂ ਸਹੀ ਸੁਧਾਰ ਹੈ
ਕਲਾਸਿਕ ਲੱਛਣ ਖਾਸ ਹੈ: TCP ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੁੰਦਾ ਹੈ, ਛੋਟੇ ਜਵਾਬ ਆਉਂਦੇ ਹਨ, ਅਤੇ ਵੱਡਾ ਡਾਊਨਲੋਡ ਅਟਕ ਜਾਂਦਾ ਹੈ ਜਾਂ ਰੀਸੈਟ ਹੁੰਦਾ ਹੈ। 1472 ਬਾਈਟ ’ਤੇ ਨਾ-ਵੰਡ ਬਿੱਟ ਵਾਲਾ ਪਿੰਗ ਫੇਲ ਹੁੰਦਾ ਹੈ ਜਦਕਿ 1400 ਬਾਈਟ ਦਾ ਪਿੰਗ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਜੋ ਪੂਰੇ ਆਕਾਰ ਦਾ ਪੈਕਟ ਨਾ ਲੈ ਜਾ ਸਕਣ ਵਾਲੇ ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਘਟਾਉਣ ਲਈ ਕਹਿਣ ਵਾਲਾ ICMP ਸੁਨੇਹਾ ਨਾ ਪਹੁੰਚਾਉਣ ਵਾਲੇ ਰਾਹ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਰਾਹ ਦੇ MTU ਦੀ ਖੋਜ ਉਨ੍ਹਾਂ ICMP ਵੰਡ-ਲੋੜ ਸੁਨੇਹਿਆਂ ’ਤੇ ਨਿਰਭਰ ਹੈ। ਜਦੋਂ ਫਾਇਰਵਾਲ ਉਨ੍ਹਾਂ ਨੂੰ ਸੁੱਟਦਾ ਹੈ, ਭੇਜਣ ਵਾਲਾ ਵੱਡਾ ਪੈਕਟ ਵਾਰ-ਵਾਰ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਲਟਕਦਾ ਦਿਸਦਾ ਹੈ। ਟਨਲ ਵਾਲੇ ਪਾਸੇ MTU ਘਟਾਉਣਾ ਦੁਹਰਾਓ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਨੈੱਟਵਰਕ ਲਈ ਜਾਇਜ਼ ਮੁਰੰਮਤ ਹੈ।
ਪਹੁੰਚ ਤਕਨੀਕਾਂ ਵੀ ਆਪਣੀਆਂ ਸੀਮਾਵਾਂ ਰੱਖਦੀਆਂ ਹਨ: PPPoE ਆਮ ਤੌਰ ’ਤੇ 1492 ’ਤੇ ਸੀਮਿਤ ਹੁੰਦਾ ਹੈ, ਕੁਝ ਮੋਬਾਈਲ ਅਤੇ DSL ਰਾਹ ਹੇਠਾਂ ਹਨ, ਅਤੇ ਨੈਸਟਡ ਟਨਲ ਓਵਰਹੈੱਡ ਦੋ ਵਾਰ ਘਟਾਉਂਦੇ ਹਨ। ਗਾਈਡ ਤੋਂ ਸੰਖਿਆ ਨਕਲ ਕਰਨ ਦੀ ਥਾਂ ਅਸਲ ਰਾਹ ਮਾਪੋ, ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ IPv6 ਇਸ ਨੂੰ ਲੈ ਜਾਣ ਵਾਲੇ ਹਰ ਲਿੰਕ ’ਤੇ ਘੱਟੋ-ਘੱਟ 1280 ਬਾਈਟ MTU ਮੰਗਦਾ ਹੈ, ਜਿਵੇਂ RFC 8200 ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ।
ਇੱਕ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਨਿਯੰਤਰਣਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ
MTU, MSS ਅਤੇ ਵੰਡ ਵੱਖ-ਵੱਖ ਪਰਤਾਂ ਦੇ ਵੱਖ-ਵੱਖ ਨਿਯੰਤਰਣ ਹਨ, ਅਤੇ ਗਲਤ ਬਦਲਣ ਨਾਲ ਲੱਛਣ ਆਪਣੀ ਥਾਂ ’ਤੇ ਰਹਿ ਜਾਂਦਾ ਹੈ।
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS ਸੀਮਤ ਕਰਨਾ ਅਕਸਰ ਸਭ ਤੋਂ ਘੱਟ ਦਖਲਅੰਦਾਜ਼ੀ ਵਾਲੀ ਮੁਰੰਮਤ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ TCP ’ਤੇ ਅਸਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੰਟਰਫੇਸ ਨੂੰ ਹੋਰ ਟ੍ਰੈਫਿਕ ਲਈ ਖੁੱਲ੍ਹਾ ਛੱਡਦਾ ਹੈ। ਘੱਟ ਇੰਟਰਫੇਸ MTU ਵਧੇਰੇ ਵਿਆਪਕ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਸੌਖਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਖਪਤਕਾਰ ਰਾਊਟਰਾਂ ’ਤੇ ਆਮ ਹੈ, ਪਰ ਇਹ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਸਮੱਸਿਆ ਦਾ ਬਿੱਲ ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਤੋਂ ਵਸੂਲਦਾ ਹੈ।
ਨਾ-ਵੰਡ ਵਿਵਹਾਰ ਬੰਦ ਕਰਨਾ ਵੰਡ ਦੀ ਆਗਿਆ ਦੇ ਕੇ ਲੱਛਣ ਲੁਕਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਆਮ ਤੌਰ ’ਤੇ ਦੇਰੀ ਨੂੰ ਹੋਰ ਖਰਾਬ ਕਰਦਾ ਹੈ ਜਦਕਿ ਸਹੀ ਆਕਾਰ ਲੱਭਣ ਵਾਲੇ ਫੀਡਬੈਕ ਨੂੰ ਤੋੜਦਾ ਹੈ। ਸਥਾਈ ਹੱਲ ਵਜੋਂ ਇਸ ਤੋਂ ਬਚੋ।
ਇੱਕ ਸੰਖਿਆ ਦੀ ਥਾਂ ਸਮਝੌਤਾ ਮਾਪੋ
ਨਾ-ਵੰਡ ਪ੍ਰੋਬ ਨਾਲ ਰਾਹ ਦੀ ਸੀਮਾ ਲੱਭੋ, ਉੱਚਾਈ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਜਵਾਬ ਆਉਣ ਤੱਕ ਹੇਠਾਂ ਆਓ:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10ਫਿਰ ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ’ਤੇ ਅਸਲ ਕੰਮ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਉਹੀ ਫਾਈਲ ਤਬਦੀਲੀ, ਉਹੀ ਐਂਡਪਾਇੰਟ ਅਤੇ ਉਹੀ ਨੈੱਟਵਰਕ। ਪੂਰਾ ਹੋਣ ਦਾ ਸਮਾਂ ਅਤੇ ਮੁੜ-ਭੇਜਣ ਦਰਜ ਕਰੋ, ਉਦਾਹਰਣ ਲਈ nstat -az TcpRetransSegs ਨਾਲ, ਅਤੇ ਜੇ ਟਨਲ ਛੋਟੇ ਰਾਊਟਰ ’ਤੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ ਤਾਂ ਜੰਤਰ ਦਾ CPU ਵੇਖੋ। ਛੋਟੀ ਕ੍ਰਿਤਰਿਮ ਥ੍ਰੂਪੁਟ ਜਾਂਚ ਕੁਝ ਮੈਗਾਬਾਈਟ ਤੋਂ ਬਾਅਦ ਹੀ ਦਿਸਣ ਵਾਲਾ ਅਟਕਾਅ ਖੁੰਝਾ ਸਕਦੀ ਹੈ।
ਘਟਾਉਣ ਤੋਂ ਬਾਅਦ ਪੈਕਟ ਕਾਊਂਟਰ ਵਧਣਗੇ, ਕਿਉਂਕਿ ਉਹੀ ਤਬਦੀਲੀ ਹੁਣ ਹੋਰ ਪੈਕਟ ਵਰਤਦੀ ਹੈ। ਇਹ ਉਮੀਦਯੋਗ ਹੈ ਅਤੇ ਉੱਚੇ ਥ੍ਰੂਪੁਟ ਦਾ ਸਬੂਤ ਨਹੀਂ। ਪੂਰਾ ਹੋਇਆ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ, ਮੁੜ-ਭੇਜਣ ਦੀ ਗਿਣਤੀ ਅਤੇ ਜਵਾਬਦੇਹੀ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਸਿਰਫ਼ ਪੈਕਟ ਦਰ ਦੀ ਨਹੀਂ।
ਤਬਦੀਲੀ ਨੂੰ ਪੜਾਵਾਂ ਵਿੱਚ ਲਿਆਓ ਅਤੇ ਸੀਮਿਤ ਰੱਖੋ
ਮੂਲ ਮੁੱਲ ਦਰਜ ਕਰੋ, ਇੱਕ ਨਿਯੰਤਰਣ ਬਦਲੋ, ਅਤੇ ਇਸਨੂੰ ਸਥਾਈ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪ ਦੁਹਰਾਓ। ਜੇ ਸਬੂਤ ਲਾਭ ਨਹੀਂ ਦਿਖਾਉਂਦੇ, ਤਾਂ ਪਿਛਲਾ ਮੁੱਲ ਉਸੇ ਇੰਟਰਫੇਸ ਕਮਾਂਡ ਨਾਲ ਬਹਾਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਇਸਨੂੰ ਸੈੱਟ ਕਰਨ ਲਈ ਵਰਤੀ ਸੀ:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500ਨਤੀਜੇ ਨੂੰ ਉਸੇ ਨੈੱਟਵਰਕ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ ਜਿਸਨੂੰ ਇਸਦੀ ਲੋੜ ਸੀ। ਜਿਸ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਹੋਟਲ Wi-Fi, ਮੋਬਾਈਲ ਹਾਟਸਪਾਟ ਅਤੇ ਦਫ਼ਤਰ LAN ’ਤੇ ਚੱਲਣਾ ਹੈ, ਉਸਨੂੰ, ਜਦੋਂ ਤੱਕ ਕਲਾਇੰਟ ਰਾਹ ਪਛਾਣ ਨਹੀਂ ਸਕਦਾ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦੁਆਰਾ ਮੰਗਿਆ ਸਭ ਤੋਂ ਘੱਟ ਮੁੱਲ ਨਹੀਂ ਮਿਲਣਾ ਚਾਹੀਦਾ।
ਸਹੀ ਮੁੱਲ ਉਹ ਸਭ ਤੋਂ ਵੱਡਾ MTU ਹੈ ਜੋ ਰਾਹ ’ਤੇ ਟਿਕਦਾ ਹੈ, ਲੱਛਣ ਮਿਟਾਉਣ ਵਾਲਾ ਸਭ ਤੋਂ ਛੋਟਾ ਨਹੀਂ। ਰਾਹ, ਪ੍ਰੋਬ ਦਾ ਨਤੀਜਾ ਅਤੇ ਵਾਪਸੀ ਦਰਜ ਕਰੋ, ਅਤੇ ਪਹੁੰਚ ਨੈੱਟਵਰਕ ਬਦਲਣ ’ਤੇ ਸੈਟਿੰਗ ਮੁੜ ਵੇਖੋ।