ਕਿਸੇ ਗਾਈਡ ਵਿੱਚ ਕਿਤੇ ਇੱਕ ਸੰਖਿਆ ਹੁੰਦੀ ਹੈ, ਆਮ ਤੌਰ ਉੱਤੇ ਸੱਠ ਤੋਂ ਅੱਸੀ ਬਾਈਟ ਵਿਚਕਾਰ, ਜੋ ਕਿਸੇ ਨੇ 1500 ਵਿੱਚੋਂ ਘਟਾ ਕੇ ਇੰਟਰਫ਼ੇਸ MTU ਲਈ ਸੀ। ਉਹ ਸੰਖਿਆ ਇੱਕ ਖ਼ਾਸ ਰਸਤੇ ਉੱਤੇ ਇੱਕ ਖ਼ਾਸ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ। ਮੋਡ, ਬਾਹਰੀ ਪਤਾ ਪਰਿਵਾਰ, ਸਾਈਫ਼ਰ ਜਾਂ NAT ਦੀ ਮੌਜੂਦਗੀ ਬਦਲੋ, ਅਤੇ ਗਣਿਤ ਹੁਣ ਤੁਹਾਡੀ ਟਨਲ ਉੱਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ।

ਉਹ ਸੰਖਿਆ ਕਿਸੇ ਹੋਰ ਟਨਲ ਤੋਂ ਆਈ ਸੀ

ਓਵਰਹੈੱਡ ਅਮੂਰਤ ਅਰਥ ਵਿੱਚ IPsec ਦਾ ਗੁਣ ਨਹੀਂ ਹੈ। ਇਹ ਉਸ ਪੈਕਟ ਦਾ ਗੁਣ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਬਣਦਾ ਹੈ: ਸਹਿਮਤ ਮੋਡ, ਬਾਹਰੀ ਹੈਡਰ, ਸੁਰੱਖਿਆ ਹੈਡਰ, ਪੈਡਿੰਗ, ਇਕਸਾਰਤਾ ਖੇਤਰ ਅਤੇ ਸ਼ਾਇਦ ਵਾਧੂ UDP ਆਵਰਣ।

IPv4 ਨਾਲ ਅਤੇ NAT ਤੋਂ ਬਿਨਾਂ ਟਰਾਂਸਪੋਰਟ ਮੋਡ ਲਈ ਦੱਸੀ ਗਈ ਸੰਖਿਆ NAT ਟ੍ਰਾਵਰਸਲ ਹੇਠ IPv6 ਵਾਲੀ ਟਨਲ ਮੋਡ ਨਾਲੋਂ ਛੋਟੇ ਪੈਕਟ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਆਪੋ-ਆਪਣੇ ਕੇਸ ਲਈ ਸਹੀ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਕਿਸੇ ਹੋਰ ਡਿਪਲਾਇਮੈਂਟ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਹੀ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਲੋਕ ਅਜਿਹੀ MTU ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਜੋ ਵੱਡੇ ਟ੍ਰਾਂਸਫ਼ਰ ਤੋੜ ਦਿੰਦੀ ਹੈ। ਨਾਕਾਮੀ ਚੁੱਪ ਹੈ, ਕਿਉਂਕਿ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਚੱਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।

ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਪਰਤਾਂ ਜੋੜੋ

ਬਾਹਰੀ IP ਹੈਡਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਅੰਦਰ ਵੱਲ ਵਧੋ। ਟਨਲ ਮੋਡ ਵਿੱਚ ਮੂਲ ਪੈਕਟ ਅੰਦਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਬਾਹਰੀ ਹੈਡਰ ਬਦਲ ਨਹੀਂ ਸਗੋਂ ਵਾਧਾ ਹੈ। RFC 4303 ESP ਹੈਡਰ, ਪੈਡਿੰਗ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲੇ ਇਕਸਾਰਤਾ ਡੇਟਾ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

LayerWhat it addsWhen it applies
Outer IP header20 bytes for IPv4, 40 for IPv6Always, and 40 rather than 20 if the outer path is v6
ESP header8 bytes of SPI and sequence numberAlways
Block cipher IV8 to 16 bytes depending on the transformWhen the negotiated cipher uses one
Padding and trailerPadding to the block size, plus two trailer bytesAlways, and the amount varies with payload length
Integrity data12 to 16 bytes for common authenticated ciphersWhen integrity protection is negotiated
UDP encapsulation8 bytesNAT traversal on port 4500, which is common for clients behind NAT

ਉਨ੍ਹਾਂ ਲਾਈਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਡਿਪਲਾਇਮੈਂਟਾਂ ਵਿਚਕਾਰ ਸਥਿਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਪੈਡਿੰਗ ਵਾਲੀ ਲਾਈਨ ਇੱਕੋ ਡਿਪਲਾਇਮੈਂਟ ਦੇ ਅੰਦਰ ਵੀ ਸਥਿਰ ਨਹੀਂ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਇੱਕੋ ਓਵਰਹੈੱਡ ਸੰਖਿਆ ਨਿਰਾਸ਼ ਕਰਦੀ ਹੈ, ਇਸਦਾ ਪੂਰਾ ਕਾਰਨ ਇਹੀ ਹੈ।

ਦੋ ਸਾਈਟਾਂ ਇੱਕੋ ਟਨਲ ਬਾਰੇ ਅਸਹਿਮਤ ਹੋ ਸਕਦੀਆਂ ਹਨ

ਸੁਰੱਖਿਅਤ ਪੈਕਟ ਨੂੰ ਅਜੇ ਵੀ ਬਾਹਰੀ ਰਸਤਾ ਪਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਬਾਹਰੀ ਰਸਤਾ ਹਰ ਜਗ੍ਹਾ ਇੱਕੋ ਨਹੀਂ ਹੁੰਦਾ। PPPoE ਐਕਸੈਸ ਲਿੰਕ ਸਾਫ਼ Ethernet ਹਿੱਸੇ ਨਾਲੋਂ ਘੱਟ ਢੋਂਦਾ ਹੈ। ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਹੋਰ ਸੁੰਗੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਆਪਣਾ ਟ੍ਰੈਫ਼ਿਕ ਟਨਲ ਕਰਨ ਵਾਲਾ ਪ੍ਰਦਾਤਾ ਇੱਕ ਹੋਰ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਜੋੜਦਾ ਹੈ ਜਿਸਦਾ ਕਿਸੇ ਨੇ ਜ਼ਿਕਰ ਨਹੀਂ ਕੀਤਾ। ਜੋ ਟਨਲ ਇੱਕ ਲਿੰਕ ਉੱਤੇ ਚੱਲਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਉੱਤੇ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਉਹ ਦੂਜੇ ਲਿੰਕ ਦਾ ਵਰਣਨ ਕਰ ਰਹੀ ਹੈ, ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਨਹੀਂ।

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੀ ਵੱਖਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਅਸਮਮਿਤ ਰਸਤਾ ਤੁਹਾਨੂੰ ਚੱਲਦਾ ਅੱਪਲੋਡ ਅਤੇ ਰੁਕਿਆ ਡਾਊਨਲੋਡ ਦੇ ਸਕਦਾ ਹੈ, ਜੋ ਪਹੁੰਚਯੋਗਤਾ ਦੀ ਥਾਂ ਪੈਕਟ ਦੇ ਆਕਾਰ ਵੇਖਣ ਤੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਜਾਪਦਾ ਹੈ। ਛੋਟਾ ping ਸਫਲ ਹੋਣਾ ਪੂਰੇ ਆਕਾਰ ਦੇ ਜਵਾਬ ਬਾਰੇ ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ।

ਘਟਾਉਣ ਦੀ ਥਾਂ ਮਾਪੋ

ਰਸਤੇ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲਾ ਸਭ ਤੋਂ ਵੱਡਾ ਡੇਟਾਗ੍ਰਾਮ ਲੱਭੋ। ਫਿਰ ਇੰਟਰਫ਼ੇਸ ਜੋ ਮੁੱਲ ਦੱਸਦਾ ਹੈ ਉਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ:

ip link show eth0 | grep -o 'mtu [0-9]*'
ip xfrm state list
ping -M do -s 1400 198.51.100.7
ping -M do -s 1372 198.51.100.7
tcpdump -ni any -c 20 'esp or udp port 4500'

ਜਵਾਬ ਆਉਣ ਤੱਕ ping ਦਾ ਆਕਾਰ ਘਟਾਉਂਦੇ ਜਾਓ, ਅਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਚੱਲਣ ਵਾਲੇ ਮੁੱਲ ਨੂੰ ਉਸ ਰਸਤੇ ਦਾ ਬਜਟ ਮੰਨੋ। xfrm ਦਾ ਆਉਟਪੁੱਟ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਮੋਡ ਅਤੇ ਕਿਹੜੇ ਐਲਗੋਰਿਦਮ ਸਹਿਮਤ ਹੋਏ, ਅਤੇ ਇਹੀ ਕਿਸੇ ਵੀ ਇਮਾਨਦਾਰ ਗਣਨਾ ਦਾ ਇਨਪੁੱਟ ਹੈ। ਕੈਪਚਰ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਤਾਰ ਉੱਤੇ ESP ਹੈ ਜਾਂ UDP ਵਿੱਚ ਲਪੇਟਿਆ ESP, ਅਤੇ ਇਸ ਨਾਲ NAT ਦਾ ਸਵਾਲ ਅੰਦਾਜ਼ੇ ਤੋਂ ਬਿਨਾਂ ਹੱਲ ਹੋ ਜਾਂਦਾ ਹੈ।

ਕੰਟਰੋਲ ਪਲੇਨ ਲਈ ਵੀ ਇੱਕ ਮੁੱਲ ਰੱਖੋ। IKE ਹੈਂਡਸ਼ੇਕ ਪੈਕਟ ਦੀ ਬਣਾਵਟ ਡੇਟਾ ਪੈਕਟ ਨਾਲੋਂ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਹੈਂਡਸ਼ੇਕ ਕੈਪਚਰ ਤੋਂ ਕੱਢਿਆ ਆਕਾਰ ਡੇਟਾ ਪਲੇਨ ਦਾ MTU ਨਹੀਂ ਹੈ।

ਸੰਖਿਆ ਨੂੰ ਉਸਦੀ ਥਾਂ ਰੱਖੋ

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

ਟਿਕਟ ਵਿੱਚ ਸਹਿਮਤ ਮੋਡ, ਬਾਹਰੀ ਪਰਿਵਾਰ, NAT ਸਥਿਤੀ ਅਤੇ ਦੁਹਰਾਉਣਯੋਗ ਲੱਛਣ ਇਕੱਠੇ ਰੱਖੋ। ਚਾਰ ਤੱਥਾਂ ਦਾ ਦਰਜ ਸਮੂਹ ਯਾਦ ਰੱਖੇ ਸਥਿਰਾਂਕ ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ, ਅਤੇ ਅਗਲੇ ਕਲਾਇੰਟ ਅੱਪਗ੍ਰੇਡ ਤੱਕ ਟਿਕਣ ਵਾਲਾ ਇਹੀ ਇੱਕੋ ਸੰਸਕਰਣ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ