ਸਾਰੇ ICMP ਨੂੰ ਬਲਾਕ ਕਰਨਾ ਕੰਮ ਕਰ ਰਹੇ VPN ਰਾਹ ਨੂੰ ਕਿਉਂ ਤੋੜਦਾ ਹੈ
ਆਕਾਰ ਬਾਰੇ ਫੀਡਬੈਕ ਸੁਨੇਹੇ ping ਦੇ ਜਵਾਬ ਨਹੀਂ ਹਨ। ਜਦੋਂ ਉਹ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਛੋਟੇ ਪੈਕੇਟ ਲੰਘ ਜਾਂਦੇ ਹਨ, ਵੱਡੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਟਨਲ ਕੰਬਦੀ ਹੋਈ ਦਿਸਦੀ ਹੈ।
ਜੋ ਟਨਲ ਪ੍ਰਮਾਣਿਕਤਾ ਪਾਸ ਕਰਦੀ ਹੈ, ping ਢੋਂਦੀ ਹੈ ਅਤੇ ਫਿਰ ਪਹਿਲੇ ਵੱਡੇ ਤਬਾਦਲੇ 'ਤੇ ਅਟਕ ਜਾਂਦੀ ਹੈ, ਉਹ ਟੁੱਟੇ VPN ਦੀ ਨਹੀਂ ਬਲਕਿ ਗੁੰਮ ICMP ਸੁਨੇਹੇ ਦੀ ਕਲਾਸਿਕ ਨਿਸ਼ਾਨੀ ਹੈ। ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਪੈਕੇਟ ਬਹੁਤ ਵੱਡਾ ਸੀ, ਉਹੀ ਆਕਾਰ ਦੁਹਰਾਉਂਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਉਡੀਕਦੀ ਹੈ। ਇਸਨੂੰ ਠੀਕ ਕਰਨਾ ਫਾਇਰਵਾਲ ਨੀਤੀ ਦਾ ਫੈਸਲਾ ਹੈ, ਕਲਾਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਨਾ ਨਹੀਂ। ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਮਾਪੋ ਕਿ ਆਕਾਰ ਦੀ ਸੀਮਾ ਕਿੱਥੇ ਹੈ, ਫਿਰ ਉਸ ਨਿਯਮ ਨੂੰ ਤੰਗ ਕਰੋ ਜਿਸਨੇ ਰਿਪੋਰਟ ਨੂੰ ਨਿਗਲ ਲਿਆ।
ਇਸ ਰਾਹ 'ਤੇ ICMP ਅਸਲ ਵਿੱਚ ਕੀ ਢੋਂਦਾ ਹੈ
IPv4 ਰਾਹ MTU ਖੋਜ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਰਾਊਟਰ ਦੱਸੇ ਕਿ don't-fragment ਬਿੱਟ ਵਾਲਾ ਪੈਕੇਟ ਅੱਗੇ ਨਹੀਂ ਭੇਜਿਆ ਜਾ ਸਕਿਆ। ਉਹ ਰਿਪੋਰਟ ICMP Fragmentation Needed ਸੁਨੇਹਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ ਭੇਜਣ ਵਾਲੇ ਕੋਲ ਆਪਣੇ ਹਿੱਸੇ ਦਾ ਆਕਾਰ ਘਟਾਉਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ। IPv6 ਵਧੇਰੇ ਸਖ਼ਤ ਹੈ: ਰਾਊਟਰ ਟਰਾਂਜ਼ਿਟ ਵਿੱਚ ਵੰਡ ਨਹੀਂ ਕਰਦੇ, ਇਸ ਲਈ ICMPv6 Packet Too Big ਸੁਨੇਹਾ ਹੀ ਇੱਕੋ ਇੱਕ ਸੰਕੇਤ ਹੈ ਜੋ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਛੋਟਾ ਕਰਦਾ ਹੈ।
ਦੋਵੇਂ ਸੁਨੇਹੇ ਕੰਟਰੋਲ-ਤਲ ਦੇ ਫੀਡਬੈਕ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਨਿਦਾਨਕ ਗੂੰਜ ਨਹੀਂ। ping ਨੂੰ ਬਲਾਕ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਅਤੇ ਸਾਰੇ ICMP ਨੂੰ ਬਲਾਕ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਨਿਯਮਾਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ ਪਰ ਨੈੱਟਵਰਕ 'ਤੇ ਬਹੁਤ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀਆਂ ਹਨ। ਦੂਜੀ ਸਹੀ ਆਕਾਰ ਵਾਲੀ ਟਨਲ ਨੂੰ ਜ਼ੰਜੀਰ ਦੀ ਸਭ ਤੋਂ ਛੋਟੀ ਕੜੀ ਤੋਂ ਵੱਡੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਇੱਕਤਰਫ਼ਾ ਰਾਹ ਬਣਾ ਸਕਦੀ ਹੈ।
ਕੁਝ ਆਵਾਜਾਈ ਆਪਣੀ ਖੋਜ ਪ੍ਰੋਬ ਪੈਕੇਟ ਨਾਲ ਲਾਗੂ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ RFC 4821 ਦੱਸਦਾ ਹੈ, ਅਤੇ ਉਹ ਇਸ ਫੀਡਬੈਕ 'ਤੇ ਘੱਟ ਨਿਰਭਰ ਹਨ। ਇਹ ਜਾਂਚਣ ਦੀ ਦਲੀਲ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਆਵਾਜਾਈ ਚਲਾਉਂਦੇ ਹੋ, ਇਹ ਮੰਨਣ ਦੀ ਨਹੀਂ ਕਿ ਹਰ ਟਨਲ ਸੁਰੱਖਿਅਤ ਹੈ।
| ਸੁਨੇਹਾ | ਰਾਹ 'ਤੇ ਮਕਸਦ | ਜੇ ਬਲਾਕ ਹੋਵੇ |
|---|---|---|
| ICMPv4 ਕਿਸਮ 3 ਕੋਡ 4 | ਪੈਕੇਟ ਅਗਲੀ ਕੜੀ ਲਈ ਬਹੁਤ ਵੱਡਾ ਸੀ | ਭੇਜਣ ਵਾਲਾ ਦੁਹਰਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਅਟਕ ਜਾਂਦਾ ਹੈ |
| ICMPv6 ਕਿਸਮ 2 | Packet Too Big, IPv6 ਦਾ ਬਰਾਬਰ | ਉਹੀ ਅਟਕਾਅ, ਵੰਡ ਦੇ ਕਿਸੇ ਬਦਲ ਤੋਂ ਬਿਨਾਂ |
| ICMP ਕਿਸਮ 11 | ਸਮਾਂ ਲੰਘ ਗਿਆ, traceroute ਵਰਤਦਾ ਹੈ | ਨਿਦਾਨ ਹੌਪ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਵਹਿੰਦਾ ਹੈ |
| ICMP ਗੂੰਜ ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ | ਪਹੁੰਚ ਪਰਖ | ping ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਰਾਹ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ |
ਅਸਫਲਤਾ ਆਕਾਰ 'ਤੇ ਨਿਰਭਰ ਹੈ
ਪੁੱਛੋ ਕਿ ਕੀ ਅਸਫਲਤਾ ਪੈਕੇਟ ਦੇ ਆਕਾਰ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ। ਲੌਗਇਨ ਪੰਨਾ, DNS ਪੁੱਛਗਿੱਛ ਅਤੇ ਛੋਟੀ API ਕਾਲ ਸਫਲ ਹੁੰਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਫਾਇਲ ਅੱਪਲੋਡ, ਵੱਡਾ ਜਵਾਬ ਜਾਂ ਤਸਵੀਰ ਡਾਊਨਲੋਡ ਅਟਕ ਜਾਂਦਾ ਹੈ। ਇਹ ਪੈਟਰਨ ਦੋਵਾਂ ਸਿਰਿਆਂ ਵਿਚਕਾਰ ਕਿਤੇ ਆਕਾਰ ਦੀ ਸੀਮਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਰਾਊਟਿੰਗ ਵੱਲ ਨਹੀਂ। ਸਫਲ ਛੋਟਾ ping ਉਸ ਸੀਮਾ ਦੇ ਸਥਾਨ ਬਾਰੇ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।
ਟਨਲ ਦੇ ਅੰਦਰ ਦੋ ਪਰਤਾਂ ਵਿਚਾਰਨੀਆਂ ਹਨ: ਪੇਲੋਡ ਪੈਕੇਟ ਅਤੇ ਬਾਹਰੀ ਐਨਕੈਪਸੁਲੇਟਿਡ ਪੈਕੇਟ। ਅੰਦਰਲਾ ਭੇਜਣ ਵਾਲਾ ਸਹੀ ਵਿਵਹਾਰ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਬਾਹਰੀ ਰਾਹ ਟਨਲ ਦੀ ਧਾਰਨਾ ਤੋਂ ਛੋਟਾ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਟਨਲ ਦੀ ਆਪਣੀ MTU ਸੈਟਿੰਗ ਅਤੇ ਉਸ ਹੇਠਲੀ ਭੌਤਿਕ ਕੜੀ ਦੋਵੇਂ ਮਹੱਤਵਪੂਰਨ ਹਨ।
ਨਿਯਮ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਪੋ
don't-fragment ਬਿੱਟ ਅਤੇ ਆਪਣੇ ਚੁਣੇ ਪੇਲੋਡ ਆਕਾਰ ਨਾਲ ਪਰਖੋ, ਅਸਫਲ ਕਲਾਇੰਟ ਤੋਂ ਸੁਰੱਖਿਅਤ ਪਤੇ ਵੱਲ:
ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.71472 ਬਾਈਟ ਪੇਲੋਡ ਅਤੇ 28 ਬਾਈਟ ਹੈਡਰ ਮਿਲ ਕੇ 1500 ਬਾਈਟ ਦਾ ਪੈਕੇਟ ਬਣਦੇ ਹਨ। ਜੇ ਵੱਡਾ ਪ੍ਰੋਬ ਵੰਡ ਦੀਆਂ ਗਲਤੀਆਂ ਨਾਲ ਅਸਫਲ ਹੋਵੇ ਅਤੇ ਛੋਟਾ ਲੰਘ ਜਾਵੇ, ਤਾਂ ਤੁਸੀਂ ਸੀਮਾ ਲੱਭ ਲਈ ਹੈ; ਟਨਲ ਦੇ ਵਾਧੂ ਭਾਰ ਲਈ ਸਮਾਯੋਜਿਤ ਕਰੋ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਆਕਾਰ ਸਥਿਰ ਹੋਣ ਤੱਕ ਦੁਹਰਾਓ।
ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਖਾਲੀ ਥਾਂ ਰਿਪੋਰਟ ਹੀ ਹੈ। ਜੇ ਪ੍ਰੋਬ ਚੁੱਪਚਾਪ ਅਸਫਲ ਹੋਵੇ, ਬਿਨਾਂ ਗਲਤੀ ਅਤੇ ਜਵਾਬ ਦੇ, ਤਾਂ ਸੁਨੇਹਾ ਪਹੁੰਚਾਉਣ ਦੀ ਬਜਾਏ ਸੁੱਟਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਸ਼ੱਕੀ ਨਿਯਮ ਹੈ।
ਨਿਯਮ ਤੰਗ ਕਰੋ, ਫਿਰ ਕੰਮ ਦੁਬਾਰਾ ਪਰਖੋ
ਸੁਧਾਰ ਨੂੰ ਖਾਸ ਕੰਟਰੋਲ ਸੁਨੇਹਿਆਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਪੂਰੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਨਹੀਂ। iptables ਹੋਸਟ 'ਤੇ ਰੂਪ ਕਿਸਮ-ਖਾਸ ਮਨਜ਼ੂਰੀ ਹੈ; ਵਾਕ ਰਚਨਾ ਨੂੰ ਉਸ ਅਨੁਸਾਰ ਢਾਲੋ ਜੋ ਤੁਹਾਡੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਫਾਇਰਵਾਲ ਦਾ ਪ੍ਰਬੰਧ ਕਰਦਾ ਹੈ:
iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPTਜੇ ਇਹ ਸਥਾਨਕ ਨੀਤੀ ਹੈ ਤਾਂ ਗੂੰਜ ਜਵਾਬ ਬਲਾਕ ਰੱਖੋ, ਕਿਉਂਕਿ ਰਾਹ ਨੂੰ ਉਹਨਾਂ ਦੀ ਲੋੜ ਨਹੀਂ। ਫਿਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਸਫਲ ਹੋਏ ਤਬਾਦਲੇ ਨੂੰ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਤੋਂ ਦੁਬਾਰਾ ਪਰਖੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਿਯਮ ਦੇ ਕਾਊਂਟਰ ਸੁਨੇਹੇ ਆਉਂਦੇ ਦਿਖਾ ਰਹੇ ਹਨ।
ਜੇ ਸੁਨੇਹਿਆਂ ਦੀ ਇਜਾਜ਼ਤ ਤੋਂ ਬਾਅਦ ਵੀ ਵੱਡਾ ਤਬਾਦਲਾ ਅਟਕਦਾ ਹੈ, ਤਾਂ ਬਾਕੀ ਸੀਮਾ ਕਿਤੇ ਹੋਰ ਹੈ: ਬਹੁਤ ਉੱਚੀ ਸੈੱਟ ਕੀਤੀ ਟਨਲ MTU, ਪੈਕੇਟ ਦੁਬਾਰਾ ਲਿਖਣ ਵਾਲਾ ਪ੍ਰੌਕਸੀ, ਜਾਂ ਦੱਸਣ ਦੀ ਬਜਾਏ ਸੁੱਟਣ ਵਾਲਾ ਵਿਚਕਾਰਲਾ ਬਕਸਾ। ICMP ਨਿਯਮ ਲਾਜ਼ਮੀ ਸੀ, ਕਾਫ਼ੀ ਨਹੀਂ।