VPN ਗੇਟਵੇ 'ਤੇ MSS ਕਲੈਂਪਿੰਗ: ਇਹ ਕੀ ਠੀਕ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਕਲੈਂਪਿੰਗ TCP ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ MSS ਮੁੜ ਲਿਖਦੀ ਹੈ ਤਾਂ ਜੋ ਸੈਗਮੈਂਟ ਟਨਲ ਵਿੱਚ ਫਿੱਟ ਹੋਣ। ਇਹ ਕਦੇ ਵੀ UDP ਜਾਂ ਖਰਾਬ path-MTU ਜਾਂਚ ਠੀਕ ਨਹੀਂ ਕਰਦੀ। ਤਿੰਨ ਜਾਂਚਾਂ, ਕ੍ਰਮ ਵਿੱਚ।
ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਵੱਡੇ ਡਾਊਨਲੋਡ ਅਟਕ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੋਈ MSS ਕਲੈਂਪਿੰਗ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ। ਉਹ ਸੁਝਾਅ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਅਜ਼ਮਾਉਣ ਯੋਗ ਕਾਫ਼ੀ ਵਾਰ ਸਹੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅੱਖਾਂ ਮੀਟ ਕੇ ਲਾਗੂ ਕਰਨ 'ਤੇ ਅੱਧਾ ਦਿਨ ਬਰਬਾਦ ਕਰਨ ਯੋਗ ਕਾਫ਼ੀ ਵਾਰ ਗ਼ਲਤ ਹੁੰਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਤਿੰਨ ਜਾਂਚਾਂ ਅਸਲ TCP ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਨੂੰ UDP ਸਮੱਸਿਆ, ਖਰਾਬ path-MTU ਖੋਜ, ਅਤੇ ਉਸ ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਕਦੇ ਨਾ ਦੇਖਣ ਵਾਲੀ ਕਲੈਂਪ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ ਜਿਸਨੂੰ ਮੁੜ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ।
ਨਾਕਾਮੀ ਦੇ ਆਕਾਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
ਆਕਾਰ ਦੀ ਨਾਕਾਮੀ ਦਾ ਇੱਕ ਦਸਤਖ਼ਤ ਹੁੰਦਾ ਹੈ: ਕਨੈਕਸ਼ਨ ਬਣਦਾ ਹੈ, ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਛੋਟੇ ਜਵਾਬ ਸਫਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਫਿਰ ਪੂਰੇ ਆਕਾਰ ਦਾ ਸੈਗਮੈਂਟ ਲੋੜੀਂਦਾ ਹੋਣ ਸਾਰ ਟ੍ਰਾਂਸਫਰ ਅਨਿਸ਼ਚਿਤ ਸਮੇਂ ਲਈ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਜੋ ਪੰਨੇ ਟੈਕਸਟ ਲੋਡ ਕਰਦੇ ਹਨ ਪਰ ਤਸਵੀਰ ਕਦੇ ਪੂਰੀ ਨਹੀਂ ਕਰਦੇ, ਉਹ ਛੋਟੇ ਪੈਮਾਨੇ 'ਤੇ ਉਹੀ ਨਾਕਾਮੀ ਹਨ। ਜੇ ਕੁਝ ਵੀ ਕਨੈਕਟ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਸਮੱਸਿਆ ਰਸਤੇ ਵਿੱਚ ਪਹਿਲਾਂ ਹੈ ਅਤੇ ਕਲੈਂਪਿੰਗ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ। ਕਲੈਂਪ ਉਸ ਹੈਂਡਸ਼ੇਕ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੀ ਜੋ ਕਦੇ ਆਇਆ ਹੀ ਨਹੀਂ।
ਇਹ ਦਸਤਖ਼ਤ ਇਸ ਲਈ ਹੈ ਕਿ ਸੈਗਮੈਂਟ ਦਾ ਆਕਾਰ ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਹੀ ਤੈਅ ਹੁੰਦਾ ਹੈ। ਹਰ ਧਿਰ TCP ਵਿਕਲਪ ਵਜੋਂ ਵੱਧ ਤੋਂ ਵੱਧ ਸੈਗਮੈਂਟ ਆਕਾਰ ਦਾ ਐਲਾਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਭੇਜਣ ਵਾਲੇ ਦੂਜੀ ਧਿਰ ਦੇ ਐਲਾਨ ਦਾ ਸਤਿਕਾਰ ਕਰਦੇ ਹਨ। ਜੇ ਰਸਤਾ ਇੰਨਾ ਵੱਡਾ ਸੈਗਮੈਂਟ ਲਿਜਾ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਨਾਕਾਮੀ ਬਾਅਦ ਵਿੱਚ, ਜਦੋਂ ਭੇਜਣ ਵਾਲਾ ਆਖ਼ਰ ਇੱਕ ਅਜ਼ਮਾਉਂਦਾ ਹੈ, ਦਿਖਦੀ ਹੈ।
ਇਸ ਲੱਛਣ ਨੂੰ ਪੜ੍ਹਦਿਆਂ ਆਵਾਜਾਈ ਨੂੰ ਨਜ਼ਰੋਂ ਨਾ ਓਹਲੇ ਕਰੋ। ਕਲੈਂਪਿੰਗ TCP ਵਿਕਲਪ ਦੀ ਮੁੜ ਲਿਖਤ ਹੈ, ਇਸ ਲਈ ਉਸੇ ਟਨਲ ਹੇਠ ਅਟਕਣ ਵਾਲੀ ਵੌਇਸ ਜਾਂ ਵੀਡੀਓ ਕਾਲ MSS ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਨਾਲ ਸੁਧਰੇਗੀ ਨਹੀਂ। TCP ਵਿਕਲਪ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਆਵਾਜਾਈ ਲਿਖ ਲਓ।
ਰਸਤੇ ਦੀ ਕੀਮਤ ਪਾਓ, ਫਿਰ ਟਨਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ
ਦੋ ਸੰਖਿਆਵਾਂ ਮਹੱਤਵਪੂਰਨ ਹਨ ਅਤੇ ਉਹ ਅਕਸਰ ਰਲ-ਗਲ ਜਾਂਦੀਆਂ ਹਨ। path-MTU ਉਹ ਸਭ ਤੋਂ ਵੱਡਾ ਪੈਕਟ ਹੈ ਜੋ ਰਸਤਾ ਖੰਡਨ ਤੋਂ ਬਿਨਾਂ ਲਿਜਾਂਦਾ ਹੈ, ਅਤੇ IPv4 ਲਈ ਐਲਾਨਿਆ MSS ਉਹ ਮੁੱਲ ਘਟਾ ਕੇ IP ਅਤੇ TCP ਹੈਡਰਾਂ ਦੇ 40 ਬਾਈਟ ਹੈ, ਜਾਂ IPv6 ਲਈ 60 ਘਟਾ ਕੇ। ਟਨਲ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਅੰਦਰਲਾ ਪੈਕਟ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਜਟ ਦਾ ਕੁਝ ਹਿੱਸਾ ਖਾ ਜਾਂਦਾ ਹੈ।
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20do-not-fragment ਬਿੱਟ ਵਾਲਾ ping ਦੱਸਦਾ ਹੈ ਕਿ ਉਸ ਪੇਲੋਡ ਆਕਾਰ ਦਾ ਪੈਕਟ ਬਚਦਾ ਹੈ ਕਿ ਨਹੀਂ; ਆਕਾਰ ਬਦਲਦੇ ਰਹੋ ਜਦੋਂ ਤੱਕ ਇਹ ਫੇਲ੍ਹ ਨਾ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਰਸਤੇ ਦੀ ਹੱਦ ਤਜਰਬੇ ਨਾਲ ਲੱਭ ਲਈ। tracepath ਦਾ ਆਉਟਪੁੱਟ ਰਸਤੇ ਭਰ ਲੱਭਿਆ MTU ਦੱਸਦਾ ਹੈ, ਜੋ ਚੱਲਣ 'ਤੇ ਤੇਜ਼ ਅਤੇ ਵਿਚਕਾਰਲਾ ਹੌਪ ਪ੍ਰੋਬ ਫਿਲਟਰ ਕਰਨ 'ਤੇ ਘੱਟ ਭਰੋਸੇਯੋਗ ਹੁੰਦਾ ਹੈ।
ਹੁਣ ਟਨਲ ਦਾ ਓਵਰਹੈੱਡ ਘਟਾਓ। ਬਾਹਰੀ IP ਹੈਡਰ, UDP ਹੈਡਰ ਅਤੇ ਟਨਲ-ਖ਼ਾਸ ਹੈਡਰ ਸਭ ਉਸੇ 1500 ਬਾਈਟ ਵਿੱਚੋਂ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਆਮ ਈਥਰਨੈੱਟ ਆਧਾਰ 'ਤੇ ਵਰਤੋਂਯੋਗ ਅੰਦਰਲਾ MTU ਭੌਤਿਕ ਲਿੰਕ ਦੇ ਸੰਕੇਤ ਤੋਂ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਜੇ ਗਿਣਿਆ ਅੰਦਰਲਾ MTU ਤੁਹਾਡੇ ਸਾਥੀਆਂ ਦੇ ਐਲਾਨ ਤੋਂ ਘੱਟ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਸਗੋਂ ਅਸਲ ਕਲੈਂਪ ਉਮੀਦਵਾਰ ਲੱਭਿਆ ਹੈ। ਜੇ ਗਿਣਿਆ ਮੁੱਲ ਪਹਿਲਾਂ ਹੀ ਸਾਥੀਆਂ ਦੇ ਐਲਾਨ ਤੋਂ ਉੱਪਰ ਹੈ, ਤਾਂ ਇੱਥੇ ਰੁਕੋ ਅਤੇ ਹੋਰ ਕਿਤੇ ਵੇਖੋ।
ਕਲੈਂਪ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੋਂ ਹੈਂਡਸ਼ੇਕ ਲੰਘਦਾ ਹੈ
ਕਲੈਂਪ ਗੇਟਵੇ ਪਾਰ ਕਰਦਿਆਂ SYN ਅਤੇ SYN-ACK ਪੈਕਟਾਂ ਵਿੱਚ MSS ਵਿਕਲਪ ਮੁੜ ਲਿਖ ਕੇ ਕੰਮ ਕਰਦੀ ਹੈ। ਜੇ ਨਿਯਮ ਅਜਿਹੇ ਇੰਟਰਫੇਸ 'ਤੇ ਹੈ ਜਿਸ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦਿਸ਼ਾ ਕਦੇ ਨਹੀਂ ਲੰਘਦੀ, ਤਾਂ ਗੱਲਬਾਤ ਬਿਨਾਂ ਬਦਲਾਅ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਲੱਛਣ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਮੁੱਲ ਨਾਲੋਂ ਰੱਖਣ ਦੀ ਥਾਂ ਨਤੀਜਾ ਤੈਅ ਕਰਦੀ ਹੈ।
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
ਦਿਸ਼ਾ ਦੂਜਾ ਅੱਧ ਹੈ। ਇੱਕ ਦਿਸ਼ਾ ਦੀ ਕਲੈਂਪਿੰਗ ਅੱਧੇ ਪ੍ਰਵਾਹ ਠੀਕ ਕਰਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਨੂੰ ਵਿਚ-ਵਿਚਕਾਰ ਦਿਖਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੋਣ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਅੱਗੇ ਭੇਜੀ ਜਾਂਦੀ ਟ੍ਰੈਫ਼ਿਕ ਦੀਆਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ 'ਤੇ ਲਾਗੂ ਕਰੋ। ਟਨਲ ਇੰਟਰਫੇਸ ਲਈ Linux ਦਾ ਰਵਾਇਤੀ ਰੂਪ SYN ਪੈਕਟਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ mangle ਨਿਯਮ ਹੈ:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtuਧਿਆਨ ਦਿਓ --clamp-mss-to-pmtu ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ: ਇਹ ਮੁੱਲ ਰਸਤੇ ਦੇ MTU ਵਿੱਚੋਂ ਕੱਢਦਾ ਹੈ, ਜੋ ਹਮੇਸ਼ਾ ਟਨਲ ਦਾ ਅਸਲ ਪੇਲੋਡ ਬਜਟ ਨਹੀਂ ਹੁੰਦਾ। ਰਸਤਾ-ਆਧਾਰਿਤ ਟਨਲ ਵਿੱਚ ਜਿੱਥੇ ਅੰਦਰਲਾ ਰਸਤਾ ਅਤੇ ਬਾਹਰੀ ਰਾਹ ਵੱਖਰੇ ਹਨ, ਪਿਛਲੀ ਜਾਂਚ ਵਿੱਚ ਗਿਣਿਆ ਸਪੱਸ਼ਟ ਮੁੱਲ ਸਵੈਚਾਲਿਤ ਨਾਲੋਂ ਵੱਧ ਅਨੁਮਾਨਯੋਗ ਹੁੰਦਾ ਹੈ।
ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਨਾਲ ਤਸਦੀਕ ਕਰੋ ਅਤੇ ਫੀਡਬੈਕ ਜੀਵਤ ਰੱਖੋ
ਸਥਾਪਿਤ ਕਨੈਕਸ਼ਨ ਆਪਣਾ ਬਣਿਆ MSS ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਉਸੇ ਸੈਸ਼ਨ ਵਿੱਚ ਜਾਂਚ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ ਅਤੇ ਬਣਿਆ ਮੁੱਲ ਸਿੱਧਾ ਪੜ੍ਹੋ, ਸੰਜੋਗ ਨਾਲ ਪੂਰਾ ਹੋਣ ਵਾਲੇ ਟ੍ਰਾਂਸਫਰ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ।
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSਪਹਿਲਾ ਕਮਾਂਡ ਸਾਕਟ ਦਾ MSS ਉਸਦੀ ਭੀੜ ਸਥਿਤੀ ਨਾਲ ਦੱਸਦਾ ਹੈ, ਜੋ ਕਲੈਂਪ ਅਸਰ ਕਰਨ ਦੀ ਸਭ ਤੋਂ ਤੇਜ਼ ਪੁਸ਼ਟੀ ਹੈ। ਦੂਜਾ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਜੋੜਿਆ ਸਮਝਿਆ ਨਿਯਮ ਹੀ ਮੌਜੂਦ ਨਿਯਮ ਹੈ, ਉਸੇ ਸਾਰਣੀ ਵਿੱਚ ਜਿੱਥੇ ਉਹ ਰੱਖਿਆ ਗਿਆ।
ਫਿਰ ਜੋ ਤੰਤਰ ਤੁਸੀਂ ਠੀਕ ਨਹੀਂ ਕੀਤਾ ਉਸ ਦੀ ਰੱਖਿਆ ਕਰੋ। path-MTU ਖੋਜ ਇਸ 'ਤੇ ਨਿਰਭਰ ਹੈ ਕਿ ICMP fragmentation-needed ਸੁਨੇਹੇ ਭੇਜਣ ਵਾਲੇ ਤੱਕ ਪਹੁੰਚਣ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਸੁੱਟਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਸਹੀ ਕਲੈਂਪ ਹੋਣ 'ਤੇ ਵੀ ਵੱਡੇ ਟ੍ਰਾਂਸਫਰ ਤੋੜਦਾ ਰਹੇਗਾ। ਟਨਲ ਰਾਹ ਲਈ ਉਹਨਾਂ ਸੁਨੇਹਿਆਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਜਾਂ ਮੰਨੋ ਕਿ ਕਲੈਂਪਿੰਗ ਤੁਹਾਡੀ ਚੁਣੀ ਨੀਤੀ ਦੀ ਭਰਪਾਈ ਕਰ ਰਹੀ ਹੈ।
ਅੰਤ ਵਿੱਚ, ਕਲੈਂਪ ਨੂੰ ਟਿਊਨਿੰਗ ਨੋਬ ਸਮਝਣ ਦੇ ਲਾਲਚ ਦਾ ਵਿਰੋਧ ਕਰੋ। ਇਹ ਸੈਗਮੈਂਟ ਦਾ ਆਕਾਰ ਸੀਮਤ ਕਰਦੀ ਹੈ, ਜੋ ਉਹਨਾਂ ਰਾਹਾਂ 'ਤੇ ਥ੍ਰੂਪੁਟ ਖਰਚਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇਸਦੀ ਕਦੇ ਲੋੜ ਨਹੀਂ ਸੀ। ਤਿੰਨ ਜਾਂਚਾਂ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਕਰਨ 'ਤੇ ਇਹ ਟਾਰਗਿਟ ਮੁਰੰਮਤ ਹੈ; ਪਹਿਲਾਂ ਲਾਗੂ ਕਰਨ 'ਤੇ ਇਹ ਮੂਲ ਦੋਸ਼ ਲੁਕਾਉਣ ਵਾਲਾ ਅਤੇ ਹਰ ਅਗਲੀ ਜਾਂਚ ਵਿੱਚ ਦੂਜਾ ਵੇਰੀਏਬਲ ਜੋੜਨ ਵਾਲਾ ਬਦਲਾਅ ਹੈ। ਉਹ ਸੌਦਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਕਰਨ ਯੋਗ ਹੈ, ਡਿਫਾਲਟ ਨਾਲ ਨਹੀਂ।
ਤੁਸੀਂ ਮਾਪਿਆ path-MTU, ਘਟਾਇਆ ਟਨਲ ਓਵਰਹੈੱਡ, ਜੋੜਿਆ ਨਿਯਮ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਵੇਖਿਆ MSS ਲਿਖ ਲਓ। ਚਾਰ ਸੰਖਿਆਵਾਂ ਅਗਲੀ ਘਟਨਾ ਨੂੰ ਜਾਂਚ ਦੀ ਥਾਂ ਖੋਜ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ।