Squid ਰਾਹੀਂ Proxychains: ਪੋਰਟ 80 'ਤੇ CONNECT ਪਾਬੰਦੀਆਂ

ਬ੍ਰਾਊਜ਼ਰ Squid ਰਾਹੀਂ HTTP ਪੰਨਾ ਲੋਡ ਕਰਦਾ ਹੈ। ਉਹੀ ਟਾਰਗੇਟ proxychains ਹੇਠ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਪ੍ਰੋਗਰਾਮ ਨੇ ਗਲਤ ਪ੍ਰਾਕਸੀ IP ਚੁਣੀ ਹੈ।

ਆਮ HTTP ਸਮਝਣ ਵਾਲਾ ਕਲਾਇੰਟ ਵੈੱਬ ਬੇਨਤੀ ਨੂੰ HTTP ਪ੍ਰਾਕਸੀ ਰੂਪ ਵਿੱਚ ਫਾਰਵਰਡ ਪ੍ਰਾਕਸੀ ਨੂੰ ਭੇਜ ਸਕਦਾ ਹੈ। ਪਰ ਆਮ ਸਾਕਟ ਆਵਰਣ ਨੂੰ ਉਸ ਕਨੈਕਸ਼ਨ ਲਈ ਬਾਈਟ ਸੁਰੰਗ ਚਾਹੀਦੀ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਖੋਲ੍ਹਣਾ ਚਾਹੁੰਦੀ ਸੀ। ਆਪਣੀ ਚੇਨ ਵਿੱਚ HTTP ਪ੍ਰਾਕਸੀ ਲਈ proxychains CONNECT ਵਰਤਦਾ ਹੈ।

ਭਾਵ ਪੋਰਟ 80 'ਤੇ ਸਾਦਾ ਪਾਠ ਵੈੱਬਸਾਈਟ ਪੋਰਟ 80 ਲਈ CONNECT ਬੇਨਤੀ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ। ਸਿਰਫ਼ ਮਨਜ਼ੂਰ TLS ਪੋਰਟ ਸੂਚੀ ਵੱਲ CONNECT ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੀ Squid ਨੀਤੀ ਉਸ ਸੁਰੰਗ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰ ਸਕਦੀ ਹੈ, ਭਾਵੇਂ ਪੋਰਟ 80 'ਤੇ ਆਮ HTTP ਬੇਨਤੀਆਂ ਦੀ ਆਗਿਆ ਹੈ।

ਸਿਰਫ਼ ਹੋਸਟਨਾਮ ਨਹੀਂ, ਬੇਨਤੀਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

proxychains-ng ਦਾ ਦਸਤਾਵੇਜ਼ ਇਸ ਦੇ HTTP CONNECT ਸਮਰਥਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। Squid ਦੇ ਪਹੁੰਚ ਨਿਯਮ ਵਿਧੀ ਅਤੇ ਟਾਰਗੇਟ ਪੋਰਟ ਵਿੱਚ ਫ਼ਰਕ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਇੱਕੋ ਵੈੱਬਸਾਈਟ ਵੱਲ ਜਾਣ ਵਾਲੇ ਵੱਖਰੇ ਬੇਨਤੀ ਮਾਰਗ ਹਨ।

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

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

ਸਫਲ ਬ੍ਰਾਊਜ਼ਰ ਬੇਨਤੀ ਪ੍ਰਾਕਸੀ ਦੀ ਪਹੁੰਚ ਅਤੇ ਇੱਕ ਸਮਰਥਿਤ ਬੇਨਤੀ ਢੰਗ ਬਾਰੇ ਲਾਭਦਾਇਕ ਸਬੂਤ ਹੈ। ਪਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਹਰ ਸੁਰੰਗ ਢੰਗ, ਟਾਰਗੇਟ ਪੋਰਟ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਉਸ ਪ੍ਰਾਕਸੀ ਰਾਹੀਂ ਮਨਜ਼ੂਰ ਹੈ।