VPN MTU ਦੀਆਂ ਮਿੱਥਾਂ: ਤੁਹਾਡੇ ਪੈਕਟ ਕਿਉਂ ਛੋਟੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਥਾਂ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ

ਕੋਈ ਤੁਹਾਨੂੰ ਕਹਿੰਦਾ ਹੈ ਕਿ VPN "MTU ਕਾਰਨ ਪੈਕਟ ਗੁਆ ਰਿਹਾ ਹੈ", ਤੁਸੀਂ ਟਨਲ ਨੂੰ 1400 'ਤੇ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਅਤੇ ਟ੍ਰਾਂਸਫਰ ਦੁਬਾਰਾ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਹ ਨਤੀਜਾ ਨਿਦਾਨ ਵਾਂਗ ਲੱਗਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਗਣਿਤ ਦਾ ਸੰਜੋਗ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਅਜਿਹੀ ਸੰਖਿਆ ਚੁਣੀ ਜੋ ਉਸ ਹੱਦ ਹੇਠ ਫਿੱਟ ਹੋਣ ਲਈ ਕਾਫ਼ੀ ਛੋਟੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕਦੇ ਪਛਾਣਿਆ ਨਹੀਂ, ਅਤੇ ਅਗਲੇ ਨੈੱਟਵਰਕ 'ਤੇ ਵੱਖਰੇ ਬਜਟ ਨਾਲ ਤੁਸੀਂ ਦੁਬਾਰਾ ਉਹੀ ਹੱਦ ਮਿਲੋਗੇ।

ਇਸ ਵਿੱਚੋਂ ਬਹੁਤਾ ਹਿੱਸਾ ਦੋ ਮਿੱਥਾਂ ਕਰਕੇ ਹੁੰਦਾ ਹੈ। ਪਹਿਲੀ ਇਹ ਹੈ ਕਿ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਦਾ MTU ਮਾਰਗ ਦਾ MTU ਹੈ। ਦੂਜੀ ਇਹ ਹੈ ਕਿ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਦੀ ਕੀਮਤ "ਇੱਕ ਹੈਡਰ" ਹੈ ਅਤੇ PPPoE ਦੀ ਕੀਮਤ ਗਿਣਨ ਯੋਗ ਕੁਝ ਵੀ ਨਹੀਂ। ਦੋਵੇਂ ਇਸ ਤਰ੍ਹਾਂ ਗ਼ਲਤ ਹਨ ਕਿ ਤੁਹਾਡੀ ਚੁਣੀ ਸੰਖਿਆ ਮਨਮਾਨੀ ਲੱਗਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਨਿਰਧਾਰਿਤ ਹੈ।

ਪਹਿਲੀ ਮਿੱਥ: ਟਨਲ ਦਾ MTU ਮਾਰਗ ਦਾ MTU ਹੈ

ਟਨਲ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਤੁਸੀਂ ਜੋ ਮੁੱਲ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਉਹ ਸਭ ਤੋਂ ਵੱਡੇ ਅੰਦਰਲੇ ਪੈਕਟ ਬਾਰੇ ਸਥਾਨਕ ਵਾਅਦਾ ਹੈ ਜੋ ਲਾਗੂਕਰਨ ਹੇਠਾਂ ਸੌਂਪੇਗਾ। ਮਾਰਗ ਦੀ ਅਸਲ ਸਮਰੱਥਾ ਤੁਹਾਡੇ ਅਤੇ ਦੂਰ ਦੇ ਸਿਰੇ ਵਿਚਕਾਰ ਹਰ ਲਿੰਕ ਦਾ ਗੁਣ ਹੈ, ਅਤੇ ਇਹ ਬਦਲ ਸਕਦੀ ਹੈ ਜਦੋਂ ਮਾਰਗ ਬਦਲਦਾ ਹੈ, ਜਦੋਂ ਮੋਬਾਈਲ ਕਨੈਕਸ਼ਨ ਹੈਂਡਓਵਰ ਹੁੰਦਾ ਹੈ ਜਾਂ ਜਦੋਂ ਟ੍ਰੈਫ਼ਿਕ ਕੋਈ ਹੋਰ ਪੀਅਰਿੰਗ ਲੈਂਦਾ ਹੈ। ਸੈੱਟ ਕੀਤਾ 1500 ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਹੋਸਟ ਕੀ ਬਣਾਏਗਾ, ਇਹ ਨਹੀਂ ਕਿ ਨੈੱਟਵਰਕ ਕੀ ਢੋਵੇਗਾ।

ਮਾਰਗ-MTU ਖੋਜ ਦੋਹਾਂ ਵਿੱਚ ਤਾਲਮੇਲ ਲਈ ਹੈ, ਅਤੇ ਇਹ ਪ੍ਰਤੀਕਿਰਿਆ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ। IPv4 ਵਿੱਚ, ਜੋ ਰਾਊਟਰ ਪੂਰੇ ਆਕਾਰ ਦਾ ਪੈਕਟ ਅੱਗੇ ਨਹੀਂ ਭੇਜ ਸਕਦਾ ਉਸਨੂੰ ICMP "fragmentation needed" ਸੁਨੇਹਾ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਭੇਜਣ ਵਾਲਾ ਆਪਣਾ ਅੰਦਾਜ਼ਾ ਘਟਾਉਂਦਾ ਹੈ। IPv6 ਵਿੱਚ ਇਸਦਾ ਬਰਾਬਰ Packet Too Big ਸੁਨੇਹਾ ਹੈ, ਅਤੇ ਰਾਊਟਰ ਟ੍ਰਾਂਜ਼ਿਟ ਵਿੱਚ ਬਿਲਕੁਲ ਫ੍ਰੈਗਮੈਂਟ ਨਹੀਂ ਕਰਦੇ। ਜਦੋਂ ਉਹ ਪ੍ਰਤੀਕਿਰਿਆ ਫਿਲਟਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਭੇਜਣ ਵਾਲਾ ਅਜਿਹੇ ਪੈਕਟ ਬਣਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਮਾਰਗ ਢੋ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਕੋਈ ਉਸਨੂੰ ਕਾਰਨ ਨਹੀਂ ਦੱਸਦਾ।

ਦੂਜੀ ਮਿੱਥ: ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਦੀ ਕੀਮਤ ਇੱਕ ਹੈਡਰ ਹੈ

ਬਾਹਰੀ ਤਹਿਆਂ ਨੂੰ ਇਮਾਨਦਾਰੀ ਨਾਲ ਗਿਣੋ। ਬਾਹਰੀ IP ਹੈਡਰ IPv4 ਵਿੱਚ 20 ਬਾਈਟ ਜਾਂ IPv6 ਵਿੱਚ 40 ਹੈ। NAT ਪਾਰ ਕਰਨ ਲਈ UDP ਐਨਕੈਪਸੂਲੇਸ਼ਨ 8 ਜੋੜਦਾ ਹੈ। ਟਨਲ ਪ੍ਰੋਟੋਕੋਲ ਆਪਣਾ ਹੈਡਰ, ਇਨੀਸ਼ੀਅਲਾਈਜ਼ੇਸ਼ਨ ਵੈਕਟਰ ਜਾਂ ਨੌਨਸ, ਸਾਈਫ਼ਰ ਦੀ ਬਲਾਕ ਜਾਂ ਅਲਾਈਨਮੈਂਟ ਹੱਦ ਤੱਕ ਪੈਡਿੰਗ, ਟ੍ਰੇਲਰ ਅਤੇ ਇੰਟੈਗ੍ਰਿਟੀ ਜਾਂਚ ਮੁੱਲ ਜੋੜਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਸਾਈਫ਼ਰ ਅਨੁਸਾਰ, ਅੰਦਰਲਾ ਪੈਕਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਕੁੱਲ ਆਰਾਮ ਨਾਲ ਦਰਜਨਾਂ ਬਾਈਟਾਂ ਵਿੱਚ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ।

ਫਿਰ ਅੰਦਰਲੇ ਪੈਕਟ ਦੇ ਆਪਣੇ ਹੈਡਰਾਂ ਲਈ ਦੁਬਾਰਾ ਘਟਾਓ। ਟਨਲ ਅੰਦਰ TCP ਖੰਡ ਆਪਣਾ 20 ਬਾਈਟ IP ਹੈਡਰ ਅਤੇ 20 ਬਾਈਟ TCP ਹੈਡਰ ਢੋਂਦਾ ਹੈ, ਅਤੇ TCP ਦਾ MSS MTU ਤੋਂ ਨਿਕਲਦਾ ਹੈ, ਟਨਲ ਦੇ ਨਾਮਮਾਤਰ ਪੇਲੋਡ ਤੋਂ ਨਹੀਂ। ਇਸ ਲਈ ping ਛੋਟੇ ਪੇਲੋਡ ਨਾਲ ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਅਟਕ ਜਾਂਦਾ ਹੈ: ਸਾਧਨ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਜਾਂਚਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਪੂਰੇ ਆਕਾਰ ਦੀ TCP ਖੰਡ ਵਰਤਦਾ ਹੈ।

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

ਪਹਿਲਾ ਕਮਾਂਡ ਸੈੱਟ ਕੀਤਾ ਟਨਲ MTU ਦੱਸਦਾ ਹੈ। ਦੋਵੇਂ ਪ੍ਰੋਬ 1472 ਬਾਈਟ ਦਾ ਪੇਲੋਡ ਭੇਜਦੇ ਹਨ, ਜੋ IPv4 ਅਤੇ ICMP ਹੈਡਰਾਂ ਦੇ 28 ਬਾਈਟ ਨਾਲ 1500 ਬਾਈਟ ਦਾ ਪੈਕਟ ਹੈ, ਅਤੇ ਫਿਰ ਛੋਟਾ। ਜੇ ਵੱਡਾ ਪ੍ਰੋਬ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ ਹੋਵੇ ਅਤੇ ਛੋਟਾ ਸਫਲ ਹੋਵੇ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਆਕਾਰ-ਨਿਰਭਰ ਖਰਾਬੀ ਹੈ, ਆਮ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਨਹੀਂ।

ਤੀਜੀ ਮਿੱਥ: PPPoE ਅਜੇ ਵੀ ਤੁਹਾਨੂੰ ਸਾਫ਼ 1500 ਦਿੰਦਾ ਹੈ

ਰਵਾਇਤੀ PPPoE ਪਹੁੰਚ ਲਿੰਕ 1500 ਬਾਈਟ ਦਾ IP ਪੈਕਟ ਨਹੀਂ ਢੋਂਦਾ। PPPoE ਹੈਡਰ ਅਤੇ PPP ਪ੍ਰੋਟੋਕੋਲ ਖੇਤਰ ਈਥਰਨੈੱਟ ਫ੍ਰੇਮ ਅੰਦਰ 8 ਬਾਈਟ ਲੈਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ IP ਪੈਕਟ ਲਈ 1492 ਬਚਦਾ ਹੈ। ਇਹ RFC 2516 ਵਿੱਚ ਵਰਣਿਤ ਰਵਾਇਤੀ ਹੱਦ ਹੈ। ਜੇ ਤੁਸੀਂ ਅਜਿਹੇ ਲਿੰਕ 'ਤੇ VPN ਚਲਾਓ, ਤਾਂ ਟਨਲ ਦਾ ਓਵਰਹੈਡ ਉਸ 1492 ਵਿੱਚੋਂ ਆਉਂਦਾ ਹੈ, 1500 ਵਿੱਚੋਂ ਨਹੀਂ।

RFC 4638 ਵੱਡੇ PPP ਪੇਲੋਡ 'ਤੇ ਗੱਲਬਾਤ ਕਰਨ ਦਾ ਤਰੀਕਾ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਦੋਂ ਪਹੁੰਚ ਕੇਂਦਰ ਅਤੇ ਗਾਹਕ ਉਪਕਰਣ ਦੋਵੇਂ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ "ਇਹ ਕਨੈਕਸ਼ਨ PPPoE ਵਰਤਦਾ ਹੈ" ਇਕੱਲਾ ਕੋਈ ਖਾਸ ਸੰਖਿਆ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਸਥਾਨਕ ਸੈਟਿੰਗ ਵਿਚਕਾਰਲੇ ਯੰਤਰ ਨੂੰ ਅਜਿਹਾ ਪੈਕਟ ਮੰਨਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਸਕਦੀ ਜਿਸ ਲਈ ਉਹ ਕਦੇ ਕਨਫ਼ਿਗਰ ਨਹੀਂ ਸੀ ਕੀਤਾ ਗਿਆ, ਇਸ ਲਈ ਲਾਹੇਵੰਦ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਲਿੰਕ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਤੈਅ ਕੀਤਾ, ਲੇਬਲ ਕੀ ਕਹਿੰਦਾ ਹੈ ਇਹ ਨਹੀਂ।

ਅਸਫਲਤਾ ਚੋਣਵੀ ਕਿਉਂ ਲੱਗਦੀ ਹੈ

ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਸਫਲ ਹੋਣਾ ਅਤੇ ਵੱਡੇ ਟ੍ਰਾਂਸਫਰਾਂ ਦਾ ਅਟਕਣਾ ਮਾਰਗ-MTU ਕਾਲੇ ਪੁਲਾਂਘ ਦਾ ਕਲਾਸਿਕ ਚਿੰਨ੍ਹ ਹੈ। ਹੈਂਡਸ਼ੇਕ, DNS ਪੁੱਛਗਿੱਛ ਅਤੇ API ਕਾਲ ਸਾਰੇ ਫਿੱਟ ਹੁੰਦੇ ਹਨ; ਥੋਕ ਟ੍ਰਾਂਸਫਰ ਪੂਰੇ ਆਕਾਰ ਦੀਆਂ ਖੰਡਾਂ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਇੱਕ ਲਿੰਕ 'ਤੇ ਮਰ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ICMP ਸੁਨੇਹਾ ਜੋ ਸਮੱਸਿਆ ਦੱਸਣਾ ਚਾਹੀਦਾ ਸੀ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਕਨੈਕਸ਼ਨ ਠੀਕ ਦਿਸਦਾ ਹੈ ਅਤੇ ਡਾਊਨਲੋਡ ਲਟਕ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਲੋਕ ਮਾਰਗ ਦੀ ਥਾਂ ਸਰਵਰ ਵੱਲ ਦੇਖਦੇ ਹਨ।

ਦੂਜੀ, ਸੰਬੰਧਿਤ ਗ਼ਲਤੀ ਤਿੰਨ ਸੰਖਿਆਵਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣਾ ਹੈ: ਇੰਟਰਫ਼ੇਸ MTU, TCP MSS ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਆਪਣੀ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਜਾਂ ਪੈਡਿੰਗ ਸੈਟਿੰਗ। ਰਾਊਟਰ 'ਤੇ MSS ਕਲੈਂਪਿੰਗ ਘੋਸ਼ਿਤ MSS ਨੂੰ ਮੁੜ ਲਿਖਦੀ ਹੈ ਤਾਂ ਜੋ ਭੇਜਣ ਵਾਲਾ ਛੋਟੀਆਂ ਖੰਡਾਂ ਬਣਾਏ; ਇਹ ਟਨਲ MTU ਨਹੀਂ ਬਦਲਦੀ ਅਤੇ UDP ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਮਦਦ ਨਹੀਂ ਕਰਦੀ। ਸੰਬੰਧਿਤ ਦਿਸਣ ਕਰਕੇ ਤਿੰਨਾਂ ਨੂੰ ਇੱਕੋ ਸੰਖਿਆ ਦੇਣਾ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਚੰਗੇ ਇਰਾਦੇ ਦੀ ਤਬਦੀਲੀ ਕੰਮ ਕਰਦਾ ਸੈੱਟਅੱਪ ਤੋੜ ਦਿੰਦੀ ਹੈ।

ਕੀ ਬਦਲਣਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਕ੍ਰਮ ਵਿੱਚ

ਸਬੂਤ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ। ਉੱਪਰਲੇ ਪ੍ਰੋਬ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਖਰਾਬੀ ਆਕਾਰ-ਨਿਰਭਰ ਹੈ, ਫਿਰ ਸਭ ਤੋਂ ਛੋਟਾ ਆਕਾਰ ਜੋ ਪਾਸ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਵੱਡਾ ਜੋ ਫੇਲ ਹੁੰਦਾ ਹੈ ਲੱਭੋ। ਟਨਲ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਪਹੁੰਚ ਲਿੰਕ ਦਾ ਅਸਲ MTU ਜਾਂਚੋ; PPPoE ਲਿੰਕ ਤੁਹਾਡੇ VPN ਦੇ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਜਟ ਸੀਮਤ ਕਰ ਦਿੰਦਾ ਹੈ। ਮੂਲ ਮੁੱਲ ਨੋਟ ਕਰੋ ਤਾਂ ਜੋ ਤਬਦੀਲੀ ਵਾਪਸ ਲਈ ਜਾ ਸਕੇ।

ਫਿਰ ਕਲਾਇੰਟ ਜੋ ਸਭ ਤੋਂ ਛੋਟਾ ਸਮਾਯੋਜਨ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਲਾਗੂ ਕਰੋ। ਕਈ ਕਲਾਇੰਟ ਟਨਲ MTU ਨਾਲ MSS ਸੁਧਾਰ ਵਿਕਲਪ ਦਿੰਦੇ ਹਨ, ਅਤੇ MSS ਵਿਕਲਪ ਅਕਸਰ TCP ਲਈ ਵਧੀਆ ਲੀਵਰ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ ਪੈਕਟ ਛੋਟਾ ਕੀਤੇ ਬਿਨਾਂ ਭੇਜਣ ਵਾਲੇ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਉਹੀ ਮੰਜ਼ਿਲ ਅਤੇ ਉਹੀ ਟ੍ਰਾਂਸਫਰ ਦੁਬਾਰਾ ਜਾਂਚੋ, ਅਤੇ ਜਿਨ੍ਹਾਂ ਸੰਖਿਆਵਾਂ 'ਤੇ ਤੁਸੀਂ ਟਿਕੇ ਉਹ ਨੋਟ ਕਰੋ। ਇੱਕ ਪਹੁੰਚ ਨੈੱਟਵਰਕ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਟਨਲ ਮੁੱਲ ਸਰਵਵਿਆਪੀ ਸਥਿਰਾਂਕ ਨਹੀਂ ਹੈ, ਅਤੇ ਅਗਲੀ ਸਾਈਟ ਦਾ ਆਪਣਾ ਬਜਟ ਹੋਵੇਗਾ।