ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ SOCKS ਚਾਹੀਦਾ ਹੈ। ਤੁਹਾਡੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਅਪਸਟ੍ਰੀਮ ਸੇਵਾ HTTP CONNECT ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਦੇ SOCKS ਖੇਤਰ ਵਿੱਚ HTTP ਐਂਡਪੁਆਇੰਟ ਰੱਖਣ ਨਾਲ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿਚਕਾਰ ਅਨੁਵਾਦ ਨਹੀਂ ਹੁੰਦਾ।

ਗੇਟਵੇ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ SOCKS ਲੈ ਸਕਦਾ ਹੈ, ਮੰਗਿਆ ਗਿਆ ਮੰਜ਼ਿਲ ਪੜ੍ਹ ਸਕਦਾ ਹੈ ਅਤੇ ਉਸ ਮੰਜ਼ਿਲ ਲਈ HTTP ਪੈਰੈਂਟ ਕੋਲੋਂ CONNECT ਸੁਰੰਗ ਮੰਗ ਸਕਦਾ ਹੈ। ਫਿਰ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਧਾਰਾ ਨੂੰ ਸੁਰੰਗ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ।

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

ਹਰ ਇੰਟਰਫੇਸ ਨੂੰ ਸਪਸ਼ਟ ਕਰੋ

ਇਸ ਬੰਦੋਬਸਤ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੇ ਗੇਟਵੇ ਲਈ ਇਸਦੀ ਪੈਰੈਂਟ ਕਿਸਮ ਮਹੱਤਵਪੂਰਨ ਹੈ। 3proxy ਦਾ ਦਸਤਾਵੇਜ਼ connect ਪੈਰੈਂਟ ਨੂੰ ਆਮ HTTP ਫਾਰਵਰਡਿੰਗ ਪ੍ਰੌਕਸੀ ਵਜੋਂ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਪੈਰੈਂਟ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

ਮੌਜੂਦਾ 3proxy ਵਰਤੋਂਕਾਰ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਨਾਲ, ਸਿਰਫ਼-ਸਥਾਨਕ ਰਾਊਟਿੰਗ ਟੁਕੜਾ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦਾ ਹੈ:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

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

ਐਪਲੀਕੇਸ਼ਨ ਸਥਾਨਕ SOCKS ਐਂਡਪੁਆਇੰਟ ਵਰਤਦਾ ਹੈ। ਗੇਟਵੇ ਪੈਰੈਂਟ ਵੱਲ HTTP CONNECT ਵਰਤਦਾ ਹੈ। ਮੰਗਿਆ ਗਿਆ ਮੰਜ਼ਿਲ ਹੋਸਟ ਅਤੇ ਪੋਰਟ ਮਨਜ਼ੂਰ ਹਨ ਜਾਂ ਨਹੀਂ, ਇਹ ਹਾਲੇ ਵੀ ਪੈਰੈਂਟ ਹੀ ਤੈਅ ਕਰਦਾ ਹੈ।

ਇੱਥੇ ਲਾਭਦਾਇਕ ਦਾਇਰਾ ਆਮ TCP ਧਾਰਾ ਸੁਰੰਗ ਹੈ। ਅੱਗੇ ਵਾਲਾ ਸਰੋਤਾ SOCKS5 ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਸਿਰਫ਼ ਇਸ ਕਰਕੇ SOCKS5 UDP ਸਾਂਝ ਸਮਰਥਿਤ ਨਹੀਂ ਹੁੰਦੀ। HTTP CONNECT ਪੈਰੈਂਟ ਲੋੜੀਂਦਾ UDP ਰਿਲੇ ਆਪਣੇ ਆਪ ਨਹੀਂ ਦਿੰਦਾ।

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

ਸੰਬੰਧਿਤ ਲੇਖ