Ping ਸਬੂਤ ਨਹੀਂ ਹੈ: ਦੋ ਸਾਈਟਾਂ ਵਿਚਕਾਰਲਾ ਰਾਹ ਜਾਂਚੋ

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

ਸੇਵਾ ਲੋੜੀਂਦੇ ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

ਦਸਤਾਵੇਜ਼ੀ ਹੋਸਟ ਨਾਮ ਅਜ਼ਮਾਓ ਅਤੇ, ਜਿੱਥੇ ਸੇਵਾ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਉਸੇ ਪੋਰਟ ਦੀ ਸਿੱਧੀ ਪਤਾ ਜਾਂਚ ਵੀ ਕਰੋ। ਫੇਲ੍ਹ ਨਾਮ ਖੋਜ ਅਤੇ ਨਾ ਪਹੁੰਚਣ ਯੋਗ ਹੱਲ ਹੋਇਆ ਪਤਾ ਤੁਹਾਨੂੰ ਵੱਖਰੇ ਰਾਹਾਂ 'ਤੇ ਲੈ ਜਾਂਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਹੋਸਟ ਨਾਮ ਦੀ ਥਾਂ IP ਪਾਉਂਦੇ ਹੋ, ਤਾਂ ਇਸ ਨੂੰ ਚਲਾਉਣ ਲਈ HTTPS ਪਛਾਣ ਜਾਂਚ ਬੰਦ ਨਾ ਕਰੋ; ਸਰਟੀਫਿਕੇਟ ਦੀ ਚੇਤਾਵਨੀ ਜਾਣਕਾਰੀ ਹੈ, ਰੁਕਾਵਟ ਨਹੀਂ।

ਹਰ ਕੰਢੇ 'ਤੇ ਰਾਹ ਚੱਲੋ

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

ਜੇ ਬੇਨਤੀ ਦੂਰ ਵਾਲੇ ਕੰਢੇ 'ਤੇ ਦਿਸਦੀ ਹੈ ਪਰ ਉਸ ਪਿੱਛੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ, ਸਮੱਸਿਆ ਪਾਰਲੇ ਪਾਸੇ ਹੈ: ਫਾਇਰਵਾਲ, ਗੁੰਮ ਵਾਪਸੀ ਰੂਟ, ਜਾਂ ਅਜਿਹਾ ਹੋਸਟ ਜੋ ਸਰੋਤ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਬੇਨਤੀ ਕਦੇ ਦਿਸਦੀ ਹੀ ਨਹੀਂ, ਤਾਂ ਸਥਾਨਕ ਰੂਟ ਜਾਂ ਟਨਲ ਚੋਣਕਾਰ ਉਸ ਨੂੰ ਨਹੀਂ ਲੈ ਗਏ, ਅਤੇ ਪਾਰਲਾ ਪਾਸਾ ਹਾਲੇ ਜਾਂਚ ਦੇ ਯੋਗ ਨਹੀਂ।

ਐਪ ਜੋ ਪ੍ਰੋਟੋਕੋਲ ਵਰਤਦਾ ਹੈ ਉਹੀ ਵਰਤੋ

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

ਜਿਸ ਹਾਲਤ ਵਿੱਚ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਉਹ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ

ਸਿਰਫ਼ ਵੱਡੇ ਟ੍ਰਾਂਸਫਰਾਂ ਵਿੱਚ ਦਿਸਣ ਵਾਲੀਆਂ ਅਸਫਲਤਾਵਾਂ ਆਕਾਰ ਦੀ ਸਮੱਸਿਆ ਹਨ, ਕਨੈਕਟੀਵਿਟੀ ਦੀ ਨਹੀਂ। don't-fragment ਬਿੱਟ ਸੈੱਟ ਕਰਕੇ ਵੱਡਾ ਪੈਕੇਟ ਭੇਜੋ ਅਤੇ ਵੇਖੋ ਕਿ ਉਹ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ। ਜੇ ਛੋਟੀ ਬੇਨਤੀ ਸਫਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਵੱਡੀ ਅਟਕ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਟਨਲ ਦਾ MTU ਅਤੇ ਗੇਟਵੇ 'ਤੇ MSS ਸੰਭਾਲ ਅਗਲੇ ਸ਼ੱਕੀ ਹਨ।

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ ਉਹੀ ਜਾਂਚ ਦੁਬਾਰਾ ਕਰੋ

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

ਚਾਰ ਆਧਾਰ ਮੁੱਲ ਅਤੇ ਨਤੀਜਾ ਦਰਜ ਕਰੋ। ਉਸੇ ਲੱਛਣ ਦੀ ਅਗਲੀ ਰਿਪੋਰਟ ਫਿਰ ਪਿੰਗ ਦੀ ਥਾਂ ਸਬੂਤ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਸਕੇਗੀ।