OpenVPN ਲਈ SOCKS5 ਪ੍ਰੌਕਸੀ: TCP ਟਨਲ ਜਾਂ ਐਪਾਂ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕਰਨਾ?

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

ਇੱਕ ਰੋਕ ਡਿਜ਼ਾਈਨ ਤੈਅ ਕਰਦੀ ਹੈ

SOCKS5 ਸੱਚਮੁੱਚ UDP ਐਸੋਸੀਏਸ਼ਨ ਮੋਡ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ। ਫਿਰ ਵੀ OpenVPN ਕਲਾਇੰਟ ਦੀ ਪ੍ਰੌਕਸੀ ਸਹਾਇਤਾ ਸਟ੍ਰੀਮਾਂ ਦੁਆਲੇ ਬਣੀ ਹੈ: socks-proxy TCP ਪ੍ਰੋਫ਼ਾਈਲਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਹੈ, ਅਤੇ HTTP CONNECT ਪ੍ਰੌਕਸੀ ਕੋਲ ਡੇਟਾਗ੍ਰਾਮ ਲਈ ਕੋਈ ਰਾਹ ਨਹੀਂ ਹੈ। ਦਸਤਾਵੇਜ਼ ਦੀ ਇੱਕ ਲਾਈਨ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਆਰਕੀਟੈਕਚਰ ਤੈਅ ਕਰ ਦਿੰਦੀ ਹੈ।

ਇਸ ਲਈ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜੀ ਪ੍ਰੌਕਸੀ ਚੁਣੀਏ। ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਟਨਲ ਸਟ੍ਰੀਮ ਬਣਦੀ ਹੈ, ਜਾਂ ਡੇਟਾਗ੍ਰਾਮ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਕੁਝ ਹੋਰ ਪ੍ਰੌਕਸੀਿੰਗ ਨੂੰ ਸੋਖ ਲੈਂਦਾ ਹੈ।

ਵਿਕਲਪ A: ਟਨਲ ਨੂੰ ਸਟ੍ਰੀਮ ਬਣਾਓ

ਇਸ ਲਈ TCP ਸਰੋਤਾ ਵਾਲਾ ਸਰਵਰ ਅਤੇ ਪ੍ਰੌਕਸੀ ਦਾ ਨਾਂ ਦੱਸਣ ਵਾਲੀ ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਚਾਹੀਦੀ ਹੈ। ਦੋਵੇਂ ਹਿੱਸੇ ਜ਼ਰੂਰੀ ਹਨ, ਅਤੇ ਲੋਕ ਜੋ ਭੁੱਲਦੇ ਹਨ ਉਹ ਸਰਵਰ ਵਾਲਾ ਪਾਸਾ ਹੈ:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

ਆਖ਼ਰੀ ਲਾਈਨ ਨੂੰ http-proxy proxy.internal 8080 ਨਾਲ ਬਦਲੋ ਜਦੋਂ ਪ੍ਰੌਕਸੀ HTTP ਬੋਲਦੀ ਹੈ, ਅਤੇ ਜੇ ਮੰਗੇ ਤਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਫਾਈਲ ਜੋੜੋ। ਪ੍ਰੌਕਸੀ ਨੂੰ ਤੁਹਾਡੇ VPN ਪੋਰਟ 'ਤੇ CONNECT ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਨੂੰ TCP 'ਤੇ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ; ਸਿਰਫ਼ UDP ਸਰੋਤਾ ਉਸ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ। 443 ਚੁਣਨਾ ਵਿਹਾਰਕ ਕਦਮ ਹੈ, ਕਿਉਂਕਿ ਕਈ ਪਾਬੰਦੀਸ਼ੁਦਾ ਨੈੱਟਵਰਕ ਇਸ ਨੂੰ ਅਤੇ ਥੋੜ੍ਹਾ ਹੋਰ ਮਨਜ਼ੂਰ ਕਰਦੇ ਹਨ।

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

ਵਿਕਲਪ B: ਟਨਲ ਨੂੰ ਇਕੱਲੀ ਛੱਡ ਦਿਓ

ਜਦੋਂ ਟਨਲ ਨੂੰ UDP 'ਤੇ ਹੀ ਰਹਿਣਾ ਹੋਵੇ, ਤਾਂ ਟਨਲ ਉਹ ਜਗ੍ਹਾ ਨਹੀਂ ਜਿੱਥੇ ਤੁਸੀਂ ਕੁਝ ਕਨਫਿਗਰ ਕਰਦੇ ਹੋ। ਇਸ ਦੀ ਬਜਾਏ ਐਪਾਂ ਤੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲਾ TCP ਸਥਾਨਕ SOCKS ਸਰੋਤੇ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਐਪਾਂ ਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਪ੍ਰੌਕਸੀ ਮੌਜੂਦ ਹੈ। Linux 'ਤੇ ਇਹ ਆਮ ਤੌਰ 'ਤੇ redsocks ਅਤੇ nat ਟੇਬਲ ਵਿੱਚ NAT REDIRECT ਨਿਯਮ ਹੁੰਦਾ ਹੈ।

ਫਿਰ ਵੀ ਸਿਰਫ਼ TCP। privoxy ਵਰਗੀ ਸਿਰਫ਼-HTTP ਪ੍ਰੌਕਸੀ ਮਨਮਾਨੇ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਭੇਜ ਸਕਦੀ, ਅਤੇ ਇਹ ਡਿਜ਼ਾਈਨ ਐਪਾਂ ਲਈ ਕੋਈ ਡੇਟਾਗ੍ਰਾਮ ਸਹਾਇਤਾ ਵੀ ਨਹੀਂ ਜੋੜਦਾ।

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

ਹਰ ਵਿਕਲਪ ਕਿੱਥੇ ਫੇਲ ਹੁੰਦਾ ਹੈ

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

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

ਕੋਈ ਵੀ ਵਿਕਲਪ ਡਿਵਾਈਸ ਦੀ ਲੋੜ ਨਹੀਂ ਬਦਲਦਾ। ਕਰਨਲ ਦੇ ਰਾਊਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕਟਾਂ ਨੂੰ ਅਜੇ ਵੀ TUN ਜਾਂ TAP ਨੋਡ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਅਜੇ ਵੀ /dev/net/tun 'ਤੇ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ। ਰੈਪਰ ਉਹ ਬਦਲਦਾ ਹੈ ਜੋ ਉਸ ਨੋਡ ਦੇ ਖੁੱਲ੍ਹਣ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਇਸ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਨਹੀਂ।

ਸਾਬਤ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਰਾਹ ਬਣਾਇਆ

ਟਰੇ ਆਈਕਨ ਦੀ ਬਜਾਏ ਸਾਕਟ ਵੇਖੋ। VPN ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪ੍ਰੌਕਸੀ ਪਤੇ ਨਾਲ ਸਥਾਪਿਤ ਕਨੈਕਸ਼ਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੌਕਸੀ ਨੇ ਉਹ ਨਿਸ਼ਾਨਾ ਲੌਗ ਕੀਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਕਿਹਾ ਗਿਆ ਸੀ:

ss -tnp | grep openvpn

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

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