VPN ਦਾ ਪਿੰਗ ਚੱਲਦਾ ਹੈ ਪਰ ਵੈੱਬਸਾਈਟ ਅਟਕਦੀ ਹੈ: ਆਕਾਰ ਜਾਂਚੋ

ਪਿੰਗ ਜਵਾਬ ਆਉਂਦੇ ਹਨ, ਰਿਮੋਟ ਡੈਸਕਟਾਪ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਹਾਰ ਮੰਨਣ ਤੱਕ ਖਾਲੀ ਸਫ਼ੇ ’ਤੇ ਬੈਠਾ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਨਮੂਨੇ ਨਾਲ ਦੋ ਵਿਆਖਿਆਵਾਂ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਉਹ ਇੱਕੋ ਸਮੱਸਿਆ ਦੀਆਂ ਕਿਸਮਾਂ ਨਹੀਂ: ਅਜਿਹੀ ਨੀਤੀ ਜਿਸ ਨੇ ਸੇਵਾ ਨੂੰ ਕਦੇ ਮਨਜ਼ੂਰੀ ਨਹੀਂ ਦਿੱਤੀ, ਜਾਂ ਅਜਿਹੇ ਪੈਕਟ ਜੋ ਟ੍ਰਾਂਸਫ਼ਰ ਵੱਡਾ ਹੋਣ ’ਤੇ ਫਿੱਟ ਹੋਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਈਕੋ ਜਵਾਬ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ ਨਹੀਂ ਨਕਾਰਦਾ।

ਸਭ ਤੋਂ ਛੋਟੇ ਸਵਾਲ ਤੋਂ ਸਭ ਤੋਂ ਵੱਡੇ ਵੱਲ ਜਾਓ, ਅਤੇ ਲਿਖੋ ਕਿ ਹਰ ਕਦਮ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕੀਤਾ।

ਈਕੋ ਜਵਾਬ ਬਹੁਤ ਛੋਟੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ

ਈਕੋ ਜਵਾਬ ਕਹਿੰਦਾ ਹੈ ਕਿ ਮੰਜ਼ਿਲ ਦਾ IP ਸਟੈਕ ਤੁਹਾਡੇ ਸਰੋਤ ਤੋਂ ਆਏ ICMP ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਦਿੱਤਾ। ਇਹ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੇ ਪੋਰਟ ’ਤੇ TCP ਸਰੋਤਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਕੋਈ ਨੀਤੀ ਉਸ ਪੋਰਟ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਜਾਂ ਮੰਜ਼ਿਲ ਹੋਸਟ ਗੇਟਵੇ ਤੋਂ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਟ੍ਰੈਫ਼ਿਕ ਫ਼ਿਲਟਰ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੋ ਗੇਟਵੇ ਇੱਕ ਸੇਵਾ ਦੀ ਮਨਜ਼ੂਰੀ ਦਿੰਦਾ ਹੈ ਉਹ ਦੂਜੀ ਨੂੰ ਡੇਗ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਦੋਵੇਂ ਟਾਰਗਿਟ ਪਿੰਗ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਜਵਾਬ ਨੂੰ ਇੱਕ ਪੈਕਟ ਅਤੇ ਇੱਕ ਦਿਸ਼ਾ ਬਾਰੇ ਇੱਕੋ ਤੱਥ ਵਜੋਂ ਪੜ੍ਹੋ।

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

ਪਤਾ ਲਗਾਓ ਕਿ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਹੋਇਆ ਜਾਂ ਨਹੀਂ

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU ਸੈਟਿੰਗਾਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਉਨ੍ਹਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਸਥਿਤੀ ਤੁਸੀਂ ਦੇਖੀ। ਰੱਦ ਹੋਏ ਕਨੈਕਸ਼ਨ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਟਨਲ ਦਾ ਆਕਾਰ ਬਦਲਣਾ ਉਹ ਬਦਲਾਅ ਵਿਅਰਥ ਕਰਦਾ ਹੈ ਅਤੇ ਅਸਲ ਕਾਰਨ ਨੂੰ ਕੁਝ ਸਮੇਂ ਲਈ ਲੁਕਾ ਦਿੰਦਾ ਹੈ।

ਦੱਸੀ ਸੰਖਿਆ ਨਾਲ ਆਕਾਰ ਮਾਪੋ

ਜਦੋਂ ਭਾਰ ਹੇਠ ਅਟਕਣਾ ਦਿਸਦਾ ਹੈ, ਤਾਂ ਟੁਕੜੇ ਨਾ ਕਰਨ ਵਾਲਾ ਬਿੱਟ ਲਾ ਕੇ ਇੱਕ ਪੈਕਟ ਆਕਾਰ ਜਾਂਚੋ ਅਤੇ ਨਤੀਜੇ ਦਾ ਅਰਥ ਰਹਿਣ ਲਈ ਗਣਿਤ ਦੱਸੋ। iputils ਵਾਲੇ Linux ’ਤੇ, 1392 ਬਾਈਟ ਦਾ ਪੇਲੋਡ ਅਤੇ 8 ਬਾਈਟ ਦਾ ICMP ਹੈਡਰ ਤੇ 20 ਬਾਈਟ ਦਾ IPv4 ਹੈਡਰ ਮਿਲ ਕੇ ਠੀਕ 1420 ਬਾਈਟ ਦਾ ਅੰਦਰੂਨੀ ਪੈਕਟ ਬਣਦਾ ਹੈ। ਉਹ ਗਣਿਤ ਟਿਕਟ ਵਿੱਚ ਲਿਖੋ, ਕਿਉਂਕਿ ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਨਿਰਾ ping ਐਪਲੀਕੇਸ਼ਨ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

ਦੋਵੇਂ ਜਾਂਚਾਂ ਮਾਪ ਦੇ ਬਿੰਦੂ ਹਨ, ਟਨਲ ਦੇ ਆਕਾਰ ਲਈ ਸਿਫ਼ਾਰਸ਼ਾਂ ਨਹੀਂ। ਜੇ ਰਸਤੇ ’ਤੇ ਕਿਤੇ ICMP ਫ਼ਿਲਟਰ ਹੋਵੇ, ਤਾਂ ਸਮਾਂ-ਸੀਮਾ ਆਕਾਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਪਾਸਿਓਂ ਫ਼ਿਲਟਰਿੰਗ ਅਤੇ ਬਹੁਤ ਵੱਡਾ ਪੈਕਟ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ। ਸਫ਼ਲਤਾ ਵੀ ਉਲਟ ਦਿਸ਼ਾ ਜਾਂ ਕਿਸੇ ਹੋਰ ਮੰਜ਼ਿਲ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।

ਬਾਹਰਲੇ ਰਸਤੇ ਦਾ ਹਿਸਾਬ ਰੱਖੋ

ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਆਪਣੇ ਹੈਡਰ ਜੋੜਦਾ ਹੈ, ਇਸ ਲਈ ਤਾਰ ’ਤੇ ਪੈਕਟ ਟਨਲ ਦੇ ਅੰਦਰ ਮਾਪੇ ਪੈਕਟ ਤੋਂ ਵੱਡਾ ਹੁੰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਦੋਹਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੀ ਇੱਕੋ ਸਮੇਂ ਚੱਲਣ ਵਾਲੀ ਛੋਟੀ ਬੇਨਤੀ ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਵੱਡੀ ਬੇਨਤੀ ਨੂੰ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ।

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

ਇੱਕ ਸੰਖਿਆ ਬਦਲੋ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਮੁੜ ਜਾਂਚੋ

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

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

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