ਪਾਰਦਰਸ਼ੀ TCP-ਤੋਂ-SOCKS ਫਾਰਵਰਡਿੰਗ ਵਿੱਚ ਮੂਲ ਟਿਕਾਣੇ

ਫਾਇਰਵਾਲ ਬਦਲ ਸਕਦਾ ਹੈ ਕਿ TCP ਕਨੈਕਸ਼ਨ ਕਿੱਥੇ ਪਹੁੰਚਦਾ ਹੈ। ਪਰ ਸਿਰਫ਼ ਉਸ ਬਦਲਾਅ ਨਾਲ ਇਹ ਮੂਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ SOCKS ਬੋਲਣਾ ਨਹੀਂ ਸਿਖਾ ਸਕਦਾ।

ਆਮ SOCKS ਸਰਵਰ ਬੇਨਤੀ ਕੀਤੇ ਟਿਕਾਣੇ ਦਾ ਵਰਣਨ ਕਰਨ ਵਾਲੀ ਗੱਲਬਾਤ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਪਰਾਕਸੀ ਤੋਂ ਅਣਜਾਣ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਦੀ ਬਜਾਇ ਤੁਰੰਤ ਆਪਣੇ ਪ੍ਰੋਟੋਕੋਲ ਬਾਈਟ ਭੇਜਦੀ ਹੈ। ਉਹ ਬਾਈਟ ਸਿੱਧੇ SOCKS ਸਰੋਤੇ ਵੱਲ ਭੇਜੋ ਅਤੇ ਦੋਵੇਂ ਧਿਰਾਂ ਪਹਿਲੇ ਸੁਨੇਹੇ ਉੱਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋਣਗੀਆਂ।

ਗੁੰਮ ਹਿੱਸਾ ਇੱਕ ਅਨੁਵਾਦਕ ਹੈ

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

ਇਸ ਦੇ Linux iptables ਰਾਹ ਉੱਤੇ, redsocks ਸਰੋਤ ਸੁਰੱਖਿਅਤ ਟਿਕਾਣਾ SO_ORIGINAL_DST ਰਾਹੀਂ ਲੈਂਦਾ ਹੈ। ਹੋਰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅਤੇ ਰੀਡਾਇਰੈਕਸ਼ਨ ਢੰਗ ਵੱਖਰੇ ਕਾਰਜ-ਵਿਧੀਆਂ ਵਰਤਦੇ ਹਨ। ਇਹ ਰੀਡਾਇਰੈਕਟਰ ਅਤੇ ਨੈੱਟਵਰਕ ਸੈੱਟਅਪ ਦਾ ਗੁਣ ਹੈ, ਆਮ SOCKS ਕਲਾਇੰਟ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ।

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

ਅਨੁਵਾਦਕ ਦਾ ਘੇਰਾ ਸਪਸ਼ਟ ਰੱਖੋ। ਕੰਮ ਕਰਦਾ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ TCP ਕਨੈਕਸ਼ਨ ਕਿਸੇ ਵੀ UDP, ICMP ਜਾਂ ਹਰ ਰਿਜ਼ੋਲਵਰ ਰਾਹ ਲਈ ਸਮਰਥਨ ਸਿੱਧ ਨਹੀਂ ਕਰਦਾ। ਅਪਸਟਰੀਮ ਪਰਾਕਸੀ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਅਨੁਵਾਦਕ ਦਾ ਲਾਗੂਕਰਨ ਅਜੇ ਵੀ ਸਮਰਥਿਤ ਕਾਰਵਾਈਆਂ ਤੈਅ ਕਰਦੇ ਹਨ।

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