Redsocks ਲੂਪਬੈਕ 'ਤੇ ਸੁਣਦਾ ਹੈ ਪਰ VPN ਟ੍ਰੈਫਿਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ

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

ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਪੈਕੇਟ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਉਤਰਦਾ ਹੈ

ਗੇਟਵੇ 'ਤੇ ਪਾਰਦਰਸ਼ੀ ਪ੍ਰੌਕਸੀ PREROUTING ਵਿੱਚ nat ਸਾਰਣੀ ਦੇ REDIRECT ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਉਂਦੇ ਕਨੈਕਸ਼ਨ ਦੀ ਮੰਜ਼ਿਲ ਨੂੰ ਸਥਾਨਕ ਪੋਰਟ 'ਤੇ ਦੁਬਾਰਾ ਲਿਖਦੀ ਹੈ। ਦੁਬਾਰਾ ਲਿਖੀ ਮੰਜ਼ਿਲ ਉਹ ਸਥਾਨਕ ਪਤਾ ਹੈ ਜੋ ਪੈਕੇਟ ਜਿਸ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਆਇਆ ਉਸ ਨੂੰ ਦਿਸਦਾ ਹੈ, ਨਾ ਕਿ ਕਿਤੇ ਹੋਰ ਸ਼ੁਰੂ ਹੋਈ ਪ੍ਰਕਿਰਿਆ ਦਾ ਲੂਪਬੈਕ ਪਤਾ। ਸਿਰਫ਼ 127.0.0.1 ਨਾਲ ਬੱਝਾ ਸਰੋਤਾ ਉਹ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਹੋਸਟ 'ਤੇ ਸਥਾਨਕ ਸਨ, ਅਤੇ ਟਨਲ ਟ੍ਰੈਫਿਕ ਫੇਲ੍ਹ ਹੋਣ ਵੇਲੇ ਕੰਮ ਜਾਰੀ ਰੱਖਣ ਵਾਲਾ ਮਾਮਲਾ ਠੀਕ ਇਹੀ ਹੈ। ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਲੂਪਬੈਕ ਤੀਜਾ ਪਤਾ ਹੈ ਅਤੇ ਇਹ ਕਦੇ ਵੀ ਗੇਟਵੇ ਦੇ ਨਿਯਮ ਦਾ ਟਾਰਗਿਟ ਨਹੀਂ ਹੁੰਦਾ।

ਇਸ ਲਈ ਉੱਪਰਲੇ ਪੱਧਰ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਤੱਥ ਸਥਾਪਿਤ ਕਰੋ: ਨਿਯਮ ਕਿਸ ਸਥਾਨਕ ਪਤੇ 'ਤੇ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੌਕਸੀ ਸਾਕੇਟ ਕਿਸ ਪਤੇ ਨਾਲ ਬੱਝਾ ਹੈ।

ਸਰੋਤਾ ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ ਇਕੱਠੇ ਪੜ੍ਹੋ

ਸਾਕੇਟ ਸਾਰਣੀ ਅਤੇ nat ਨਿਯਮ ਇੱਕੋ ਪਾਸ ਵਿੱਚ ਛਾਪੋ, ਕਿਉਂਕਿ ਜਿਸ ਪੋਰਟ ਦਾ ਕੋਈ ਮਾਲਕ ਨਹੀਂ ਉਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਗਲਤ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਨਿਯਮ ਵਰਗਾ ਹੀ ਦਿਸਦਾ ਹੈ। sudo ss -ltnp | grep redsocks ਬਾਈਂਡ ਪਤਾ ਅਤੇ ਮਾਲਕ ਪ੍ਰਕਿਰਿਆ ਦਿਖਾਉਂਦਾ ਹੈ। sudo iptables -t nat -S PREROUTING REDIRECT ਟਾਰਗਿਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ sudo iptables -t nat -L PREROUTING -v -n ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਸ ਨਾਲ ਕੁਝ ਮੇਲ ਖਾਧਾ ਕਿ ਨਹੀਂ।

REDSOCKS ਨਾਂ ਦੀ ਵਰਤੋਂਕਾਰ ਸੰਜ਼ੀਰ ਵਿੱਚ ਛਾਲ ਮਾਰਨਾ ਕੁਝ ਨਹੀਂ ਸਾਧਦਾ ਜਦ ਤੱਕ ਉਹ ਸੰਜ਼ੀਰ ਮੌਜੂਦ ਨਹੀਂ ਅਤੇ ਇੱਛਿਤ ਛੋਟਾਂ ਤੇ REDIRECT ਕਿਰਿਆ ਨਹੀਂ ਲੈ ਜਾਂਦੀ। ਨਾਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਮੰਨਣ ਦੀ ਬਜਾਏ sudo iptables -t nat -S REDSOCKS ਨਾਲ ਜਿਸ ਸੰਜ਼ੀਰ ਵਿੱਚ ਇਹ ਛਾਲ ਮਾਰਦਾ ਹੈ ਉਹ ਪੜ੍ਹੋ।

ਫਿਰ ਦੋਵਾਂ ਮੁੱਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਨਿਯਮ ਪੋਰਟ 12345 'ਤੇ ਗੇਟਵੇ ਪਤੇ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ ਅਤੇ ਸਰੋਤਾ 127.0.0.1:12345 ਦੱਸਦਾ ਹੈ, ਤਾਂ ਬੇਮੇਲ ਕਿਸੇ ਹੋਰ ਨਿਦਾਨ ਤੋਂ ਬਿਨਾਂ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ।

ਸੰਕਰਾ ਬੱਧੋ, ਫਿਰ ਸੀਮਿਤ ਕਰੋ ਕਿ ਇਸ ਤੱਕ ਕੀ ਪਹੁੰਚ ਸਕਦਾ ਹੈ

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

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

ਕਲਾਇੰਟ ਤੋਂ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਨਾਲ ਇਹ ਸਾਬਤ ਕਰੋ

ਗੇਟਵੇ ਦੇ ਸ਼ੈੱਲ ਤੋਂ ਨਹੀਂ, ਅਸਲ VPN ਕਲਾਇੰਟ ਤੋਂ ਨਵੇਂ TCP ਕਨੈਕਸ਼ਨ ਨਾਲ ਜਾਂਚ ਕਰੋ। ਕਲਾਇੰਟ 'ਤੇ curl -sS -o /dev/null -w '%{http_code}\n' http://example.com ਰੀਡਾਇਰੈਕਟ ਕੀਤੇ ਮਾਰਗ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਚਲਾਉਂਦਾ ਹੈ।

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

ਅੰਤ ਵਿੱਚ ਯਾਦ ਰੱਖੋ ਇਹ ਮਾਰਗ ਕੀ ਨਹੀਂ ਢਕਦਾ। ਆਮ redsocks TCP ਰੀਡਾਇਰੈਕਟ UDP, QUIC ਜਾਂ DNS ਨੂੰ SOCKS ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਨਿੱਜੀ ਮੰਜ਼ਿਲਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਛੋਟਾਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਸਫਲ ਸਥਾਨਕ ਜਾਂਚ ਸਿਰਫ਼ ਉਹ ਲੂਪਬੈਕ ਮਾਰਗ ਸਾਬਤ ਕਰਦੀ ਹੈ ਜੋ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ।