Linux IPsec ਗੇਟਵੇ 'ਤੇ TCP MSS ਕਲੈਂਪਿੰਗ: ਇਹ ਕੀ ਠੀਕ ਕਰਦੀ ਹੈ

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

ਉਹ ਲੱਛਣ ਜੋ MSS ਵੱਲ ਸੰਕੇਤ ਕਰਦਾ ਹੈ

TCP ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਹਿੱਸੇ ਦੇ ਆਕਾਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਜੇ ਉਹ ਮੁੱਲ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਮਾਰਗ ਜਿੰਨਾ ਲੈ ਕੇ ਜਾ ਸਕਦਾ ਹੈ, ਉਸ ਤੋਂ ਵੱਡਾ ਹੈ, ਤਾਂ ਭੇਜਣ ਵਾਲਾ ਐਸੇ ਹਿੱਸੇ ਬਣਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਅਤੇ ਪਹਿਲੇ ਦੌਰ ਤੋਂ ਬਾਅਦ ਕਨੈਕਸ਼ਨ ਅਟਕ ਜਾਂਦਾ ਹੈ। ਛੋਟੇ ਜਵਾਬ ਫਿੱਟ ਹੁੰਦੇ ਹਨ; ਵੱਡੇ ਨਹੀਂ।

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

TCPMSS ਨਿਯਮ ਕੀ ਕਰਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

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

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

ਨਿਯਮ ਨੂੰ ਅੰਦਰੂਨੀ TCP ਮਾਰਗ 'ਤੇ ਰੱਖੋ

ਨੀਤੀ-ਆਧਾਰਿਤ Linux ਗੇਟਵੇ 'ਤੇ, ਫਾਇਰਵਾਲ ਜਦੋਂ ਅੱਗੇ ਭੇਜਿਆ ਪੈਕੇਟ ਵੇਖਦਾ ਹੈ ਤਾਂ ਵੀ ਉਹ ਆਮ TCP ਵਰਗਾ ਦਿਸਦਾ ਹੈ। IPsec ਨੀਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਪੈਕੇਟ ਸੁਰੱਖਿਅਤ ਹੋਵੇਗਾ; ਫਾਇਰਵਾਲ ਅੰਦਰੂਨੀ ਪ੍ਰਵਾਹ ਲਈ ESP ਹੈਡਰ ਨਹੀਂ ਵੇਖਦਾ, ਇਸ ਲਈ ਇੱਥੇ ESP ਨਾਲ ਮਿਲਾਉਣਾ ਬਿਲਕੁਲ ਹੋਰ ਪੈਕੇਟ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਇਹੀ ਅਸੰਗਤੀ ਕਾਰਨ ਹੈ ਕਿ ਕੁਝ ਨਿਯਮ ਸਹੀ ਦਿਸਦੇ ਹਨ ਅਤੇ ਕਦੇ ਨਹੀਂ ਮਿਲਦੇ।

iptables ਦੀਆਂ ਸ਼ਰਤਾਂ ਵਿੱਚ ਨਿਯਮ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਮਾਰਗ ਦੀ mangle ਸਾਰਣੀ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਹੈਂਡਸ਼ੇਕ ਪੈਕੇਟਾਂ ਤੱਕ ਸੀਮਿਤ: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270। ਸੰਖਿਆ ਇੱਕ ਉਦਾਹਰਨ ਹੈ, ਸਰਵਵਿਆਪੀ ਸਥਿਰਾਂਕ ਨਹੀਂ; ਇਸਨੂੰ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਓਵਰਹੈੱਡ ਅਤੇ ਮਾਰਗ ਦੇ ਅਸਲ MTU ਤੋਂ ਲਓ। nftables ਦਾ ਬਰਾਬਰ forward ਜਾਂ postrouting ਚੇਨ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਹਿੱਸੇ ਦਾ ਆਕਾਰ ਸੈੱਟ ਕਰਦਾ ਹੈ।

IKE ਅਤੇ ESP ਲਈ ਬਾਹਰੀ ਸੁਣਨ ਵਾਲੇ ਨਿਯਮਾਂ ਨੂੰ ਅੰਦਰੂਨੀ ਅੱਗੇ ਭੇਜਣ ਵਾਲੇ ਨਿਯਮਾਂ ਤੋਂ ਵੱਖ ਰੱਖੋ। ਇੱਕੋ ਨਿਯਮ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਵਾਹ ਅਤੇ ਬਾਹਰੀ ਪ੍ਰੋਟੋਕਾਲ ਦੋਵਾਂ ਨੂੰ ਅਧਿਕਾਰ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਅੰਤ ਵਿੱਚ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨਾਲ ਵੀ ਭਰੋਸੇਯੋਗ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।

ਫਾਇਰਵਾਲ ਦੇ ਮਾਲਕ ਅਤੇ NAT ਕ੍ਰਮ ਦਾ ਸਤਿਕਾਰ ਕਰੋ

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

ਸਰੋਤ ਅਨੁਵਾਦ ਇੱਕ ਵੱਖਰਾ ਫ਼ੈਸਲਾ ਹੈ ਜੋ ਅਕਸਰ ਇਸ ਨਾਲ ਪਰਸਪਰ ਕਿਰਿਆ ਕਰਦਾ ਹੈ। ਆਮ masquerade ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਰੱਖੀ ਛੋਟ ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਉਸ ਸਰੋਤ ਨੂੰ ਗੁਆਉਣ ਤੋਂ ਰੋਕਦੀ ਹੈ ਜੋ ਇਸਦੀ ਨੀਤੀ ਮੰਗਦੀ ਹੈ; ਇਹ ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਠੀਕ ਨਹੀਂ ਕਰਦੀ, ਅਤੇ ਆਕਾਰ ਦਾ ਨਿਯਮ ਅਨੁਵਾਦ ਦੀ ਸਮੱਸਿਆ ਠੀਕ ਨਹੀਂ ਕਰਦਾ।

ਸੰਗਵਾ ਜਾਂਚੋ, ਫਿਰ ਰੁਕੋ

ਫੇਲ੍ਹ ਹੋ ਰਹੀ ਸੇਵਾ ਲਈ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਨਿਯਮ ਦੇ ਕਾਊਂਟਰ ਦੋਵੇਂ ਵੇਖੋ। ਜੇ ਅਟਕਾਅ ਦੂਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਉਸ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਨਾਲ ਉਸ TCP ਮਾਰਗ ਬਾਰੇ ਸਬੂਤ ਹੈ। ਤੁਹਾਡੇ ਕੋਲ ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਹਰ VPN ਪ੍ਰੋਟੋਕਾਲ ਫਿੱਟ ਹੁੰਦਾ ਹੈ, ਹਰ UDP ਐਪਲੀਕੇਸ਼ਨ ਠੀਕ ਹੋ ਗਈ ਹੈ, ਜਾਂ ਕੋਈ ਖ਼ਾਸ ਅੱਪਸਟ੍ਰੀਮ ਸੇਵਾ ਮੂਲ ਕਾਰਨ ਸੀ।

ਜਿੱਥੇ ਨੀਤੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਉੱਥੇ ICMP ਆਕਾਰ-ਪ੍ਰਤੀਕਿਰਿਆ ਕੰਮ ਕਰਨ ਦਿਓ, ਅਤੇ ਜਦੋਂ ਬਾਹਰੀ IPsec ਮਾਰਗ ਅੰਦਰੂਨੀ ਰੂਟ ਰਾਹੀਂ ਦਰਸਾਇਆ ਨਹੀਂ ਜਾਂਦਾ ਤਾਂ ਰੂਟ-MTU ਆਧਾਰਿਤ ਆਪਣੇ-ਆਪ ਕਲੈਂਪਿੰਗ ਨਾਲ ਸਾਵਧਾਨੀ ਵਰਤੋ। ਨਤੀਜਾ ਜਿੰਨਾ ਸੰਕਰਾ, ਅਗਲੀ ਘਟਨਾ ਦਾ ਨਿਦਾਨ ਓਨਾ ਹੀ ਸੌਖਾ।