Tor ਦੇ SOCKS ਪੋਰਟ ਰਾਹੀਂ UDP: ਕੀ ਲੰਘਦਾ ਨਹੀਂ

ਕਿਸੇ ਐਪ ਨੂੰ SOCKS ਪੋਰਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨਾ ਬ੍ਰਾਊਜ਼ਰ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਗੇਮ ਲਈ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਾਰਨ ਕਨਫਿਗਰੇਸ਼ਨ ਨਹੀਂ ਹੈ। SOCKS5 ਕਈ ਕਮਾਂਡ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਲਾਗੂਆਤ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਨੂੰ ਹੀ ਸਮਰਥਨ ਕਰਨ ਲਈ ਸੁਤੰਤਰ ਹੈ; Tor ਦਾ ਇੰਟਰਫੇਸ ਸਟ੍ਰੀਮ ਕਨੈਕਸ਼ਨ ਅਤੇ ਨਾਮ ਹੱਲ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਮਨਮਾਨੀ ਡੇਟਾਗ੍ਰਾਮ ਫਾਰਵਰਡਿੰਗ ਨਹੀਂ। ਜੋ ਕਲਾਇਟ UDP ਭੇਜਦਾ ਹੈ ਅਤੇ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਪ੍ਰੌਕਸੀ ਇਸਨੂੰ ਰੀਲੇਅ ਕਰੇਗੀ, ਉਹ ਅਜਿਹੀ ਕਮਾਂਡ ਮੰਗਦਾ ਹੈ ਜੋ ਸਰਵਰ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ। ਹੇਠਾਂ ਦਿੱਤੀ ਗਾਈਡ ਇਸਨੂੰ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਜਾਂਚਦੀ ਹੈ ਅਤੇ ਫਿਰ ਅਜਿਹਾ ਟਰਾਂਸਪੋਰਟ ਚੁਣਦੀ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।

ਜਾਂਚੋ ਕਿ ਐਪ ਅਸਲ ਵਿੱਚ ਕੀ ਭੇਜਦਾ ਹੈ

ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਨਾਮ ਦੀ ਬਜਾਏ ਟਰਾਂਸਪੋਰਟ ਦੀ ਪਛਾਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਵਾਇਸ ਕਲਾਇਟ HTTPS ਰਾਹੀਂ ਸਾਈਨ ਇਨ ਕਰਕੇ ਫਿਰ UDP ਰਾਹੀਂ ਮੀਡੀਆ ਲੈ ਜਾ ਸਕਦਾ ਹੈ; ਗੇਮ TCP ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਕੇ UDP ਰਾਹੀਂ ਖੇਡ ਸਕਦੀ ਹੈ; ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਨਿਯੰਤਰਣ ਲਈ TCP ਅਤੇ ਖੋਜ ਲਈ UDP ਵਰਤ ਸਕਦਾ ਹੈ। ਪਹਿਲੇ ਦੋ ਵਿਵਹਾਰ ਉਦੋਂ ਤੱਕ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਲੌਗਇਨ ਸਫਲ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਕਾਲ ਅਜੇ ਵੀ ਅਸਫਲ ਰਹਿੰਦੀ ਹੈ, ਇਸ ਲਈ “ਕਨੈਕਟ ਹੋ ਗਿਆ” ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਪੂਰੀ ਐਪ ਕੰਮ ਕਰਦੀ ਹੈ। ਕੁਝ ਕਲਾਇਟ ਆਪਣੇ ਆਪ UDP ਤੋਂ TCP ਵੱਲ ਮੁੜ ਜਾਂਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਅੰਸ਼ਕ ਤੌਰ ’ਤੇ ਕੰਮ ਕਰ ਰਿਹਾ ਸੈਸ਼ਨ ਰੁਕੇ ਹੋਏ ਟਰਾਂਸਪੋਰਟ ਦੀ ਬਜਾਏ ਅਸਥਿਰ ਨੈੱਟਵਰਕ ਵਰਗਾ ਦਿਸਦਾ ਹੈ।

ਜੋ ਹਿੱਸਾ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਉਸ ਲਈ ਮੰਜ਼ਿਲ ਪੋਰਟ ਅਤੇ ਟਰਾਂਸਪੋਰਟ ਲਿਖੋ। ਉਹੀ ਇੱਕ ਲਾਈਨ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਪ੍ਰੌਕਸੀ ਬਿਲਕੁਲ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।

Tor ਦਾ SOCKS ਇੰਟਰਫੇਸ ਕੀ ਸਵੀਕਾਰ ਕਰੇਗਾ

Tor ਸਟ੍ਰੀਮ ਕਨੈਕਸ਼ਨ ਲਈ SOCKS5 CONNECT ਕਮਾਂਡ ਅਤੇ ਨਾਮ ਹੱਲ ਕਰਨ ਲਈ ਐਕਸਟੈਂਸ਼ਨ ਕਮਾਂਡ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਬਿਨਾਂ ਬਦਲਾਅ ਦੇ ਇਸ ਰਾਹੀਂ ਕੰਮ ਕਰਦਾ ਹੈ। UDP ASSOCIATE, ਜੋ ਕਮਾਂਡ ਕਲਾਇਟ ਨੂੰ ਫਾਰਵਰਡਿੰਗ ਲਈ ਪ੍ਰੌਕਸੀ ਨੂੰ ਡੇਟਾਗ੍ਰਾਮ ਸੌਂਪਣ ਦਿੰਦੀ, Tor ਜੋ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਉਸਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੈ। ਐਕਸਟੈਂਸ਼ਨਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਪ੍ਰੋਜੈਕਟ ਦੀ SOCKS ਐਕਸਟੈਂਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾ ਵਿੱਚ ਹੈ, ਅਤੇ ਇਹ ਸੰਖੇਪ ਹੈ। ਡੇਟਾਗ੍ਰਾਮ ਕਮਾਂਡ ਦੀ ਗੈਰਹਾਜ਼ਰੀ ਜਾਣਬੁੱਝ ਕੇ ਹੈ: ਮਨਮਾਨੀ UDP ਰੀਲੇਅ ਕਰਨ ਨਾਲ ਨੈੱਟਵਰਕ ਨੂੰ ਉਹ ਫਾਰਵਰਡਿੰਗ ਭੂਮਿਕਾ ਮਿਲ ਜਾਂਦੀ ਜਿਸ ਲਈ ਇਹ ਕਦੇ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ।

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

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

ਜਾਂਚ ਕ੍ਰਮ ਵਿੱਚ ਚਲਾਓ

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

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

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

ਪਿੱਛੇ ਮੁੜੋ ਅਤੇ ਸਹੀ ਸਾਧਨ ਚੁਣੋ

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

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