TCP ਰੀਸੈਟ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਤੁਹਾਡਾ VPN ਬਲੌਕ ਹੋ ਰਿਹਾ ਹੈ

ਕਲਾਇੰਟ ਲੌਗ ਵਿੱਚ “ਕਨੈਕਸ਼ਨ ਰੀਸੈਟ, ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ” ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਿੱਟਾ ਸਬੂਤ ਤੋਂ ਪਹਿਲਾਂ ਆ ਜਾਂਦਾ ਹੈ। ਕੋਈ ਫ਼ੈਸਲਾ ਕਰ ਲੈਂਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ VPN ਬਲੌਕ ਕਰ ਰਿਹਾ ਹੈ, ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਗ਼ਲਤ ਹੈ, ਜਾਂ ਕੋਈ ਖ਼ਾਸ ਦੇਸ਼ ਦਖ਼ਲ ਦੇ ਰਿਹਾ ਹੈ। ਰੀਸੈਟ ਇੱਕ TCP ਪੈਕੇਟ ਹੈ ਜੋ ਕਨੈਕਸ਼ਨ ਖ਼ਤਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਲੌਗ ਲਾਈਨ ਦਰਜ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਮਿਲਿਆ। ਇਹ ਭੇਜਣ ਵਾਲੇ ਯੰਤਰ ਜਾਂ ਕਾਰਨ ਦਾ ਨਾਮ ਨਹੀਂ ਦੱਸਦਾ।

ਰੀਸੈਟ ਇੱਕ ਪੈਕੇਟ ਹੈ, ਫ਼ੈਸਲਾ ਨਹੀਂ

TCP ਰੀਸੈਟ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ: RST ਫਲੈਗ ਵਾਲਾ ਸੈਗਮੈਂਟ ਕਨੈਕਸ਼ਨ ਨੂੰ ਤੁਰੰਤ ਖ਼ਤਮ ਕਰਦਾ ਹੈ। ਪ੍ਰਾਪਤਕਰਤਾ ਗੱਲਬਾਤ ਨਹੀਂ ਕਰਦਾ, ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਕਿਉਂ ਨਹੀਂ ਪੁੱਛਦਾ। ਇਹ ਰੀਸੈਟ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਅਤੇ ਅੱਗੇ ਵਧਦਾ ਹੈ।

ਕਲਾਇੰਟ ਨੂੰ ਇੰਨਾ ਹੀ ਪਤਾ ਹੈ। RST ਸਰਵਰ, ਪ੍ਰੌਕਸੀ, ਫਾਇਰਵਾਲ ਜਾਂ ਸਥਿਤੀ ਗੁਆ ਚੁੱਕੇ ਲੋਡ ਬੈਲੰਸਰ ਤੋਂ ਆ ਸਕਦਾ ਹੈ।

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਿਹੜਾ ਕਨੈਕਸ਼ਨ ਰੀਸੈਟ ਹੋਇਆ

ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਸਰਗਰਮ ਪ੍ਰੋਫ਼ਾਈਲ ਸੱਚਮੁੱਚ TCP ਵਰਤਦੀ ਹੈ। UDP ਟਨਲ 'ਤੇ ਰੀਸੈਟ ਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ, ਅਤੇ HTTP ਪ੍ਰੌਕਸੀ ਦਾ ਲੌਗ VPN ਤੋਂ ਵੱਖਰੇ TCP ਹਿੱਸੇ ਨਾਲ ਸਬੰਧਤ ਹੋ ਸਕਦਾ ਹੈ।

ਮੰਜ਼ਿਲ, ਪੋਰਟ, ਕੋਸ਼ਿਸ਼ ਦਾ ਸਮਾਂ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਪਹੁੰਚੇ ਪੜਾਅ ਨੂੰ ਦਰਜ ਕਰੋ।

ਪੜਾਅ ਸਭ ਤੋਂ ਲਾਹੇਵੰਦ ਖੇਤਰ ਹੈ। TLS ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ ਰੀਸੈਟ ਇੱਕ ਸ਼ੱਕੀ ਸਮੂਹ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ; ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਬਾਅਦ ਦਾ ਰੀਸੈਟ ਦੂਜੇ ਵੱਲ। ਪੜਾਅ ਤੋਂ ਬਿਨਾਂ ਹਰ ਸਿਧਾਂਤ ਫਿੱਟ ਬੈਠਦਾ ਹੈ।

ਮਾਰਗ ਦੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਦੋਵਾਂ 'ਤੇ ਕੈਪਚਰ ਕਰੋ। ਜੋ ਰੀਸੈਟ ਕਲਾਇੰਟ 'ਤੇ ਦਿਖਦਾ ਹੈ ਪਰ ਸਰਵਰ 'ਤੇ ਨਹੀਂ, ਉਹ ਸਰਵਰ 'ਤੇ ਪੈਦਾ ਨਹੀਂ ਹੋਇਆ।

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ RST ਸੈਗਮੈਂਟਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

ਨਿਯੰਤਰਿਤ ਤੁਲਨਾ ਨਾਲ ਸੀਮਤ ਕਰੋ

ਦੂਜਾ ਮਨਜ਼ੂਰ ਨੈੱਟਵਰਕ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਅਸਫਲਤਾ ਕਲਾਇੰਟ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ ਜਾਂ ਮਾਰਗ ਦਾ। ਜੇ ਉਹੀ ਪ੍ਰੋਫ਼ਾਈਲ ਕਿਤੇ ਹੋਰ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਸੰਭਵ ਤੌਰ 'ਤੇ ਠੀਕ ਹੈ ਅਤੇ ਵੇਰੀਏਬਲ ਮਾਰਗ ਹੈ।

ਇਹ ਅਜੇ ਵੀ ਇੱਕ ਖ਼ਾਸ ਵਿਚਕਾਰਲੇ ਯੰਤਰ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਦਾਇਰੇ ਨੂੰ ਇੱਕ ਰੂਟ ਤੱਕ ਸੀਮਤ ਕਰਦਾ ਹੈ, ਜੋ ਲਾਹੇਵੰਦ ਅਤੇ ਇਮਾਨਦਾਰ ਨਤੀਜਾ ਹੈ।

“ਇਹ ਮਾਰਗ ਅਸਫਲ ਹੁੰਦਾ ਹੈ” ਅਤੇ “ਇਸ ਨਾਮਿਤ ਧਿਰ ਨੇ ਇਹ ਕੀਤਾ” ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਕਾਇਮ ਰੱਖੋ। ਪਹਿਲਾ ਜਾਂਚਯੋਗ ਹੈ; ਦੂਜਾ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕਲਾਇੰਟ ਤੋਂ ਨਹੀਂ।

ਭਰੋਸੇ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਬਦਲੇ ਬਿਨਾਂ ਸੁਧਾਰ ਦੀ ਜਾਂਚ ਕਰੋ

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

ਪਛਾਣੇ ਗਏ ਹਿੱਸੇ ਨੂੰ ਉਸਦੇ ਮਾਲਕ ਰਾਹੀਂ ਠੀਕ ਕਰੋ, ਫਿਰ ਉਹੀ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਉਹੀ ਨਿਰੀਖਣ ਦੁਹਰਾਓ:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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