Proxychains a través de Squid: restricións de CONNECT no porto 80
Distinga as peticións HTTP proxy normais dos túneles HTTP CONNECT de proxychains cando se denega o porto 80 de destino.
O navegador carga unha páxina HTTP a través de Squid. O mesmo destino falla baixo proxychains. Iso non significa necesariamente que un dos dous programas escollese un IP de proxy incorrecto.
Un cliente normal que entende HTTP pode enviar a petición web ao proxy de reenvío en forma de proxy HTTP. Pola contra, un envoltorio de sockets xenérico necesita un túnel de bytes para a conexión que a aplicación quería abrir. Para un proxy HTTP da súa cadea, proxychains usa CONNECT.
Iso significa que un sitio web de texto simple no porto 80 pode xerar unha petición CONNECT para o porto 80. Unha política de Squid que só permite CONNECT cara á súa lista aprobada de portos TLS pode rexeitar ese túnel aínda que as peticións HTTP normais ao porto 80 estean permitidas.
Compare peticións, non só nomes de host
A documentación de proxychains-ng describe o seu soporte de HTTP CONNECT. As regras de acceso de Squid poden distinguir o método e o porto de destino. Son camiños de petición distintos cara ao mesmo sitio web.
Lea o rexeitamento e a política prevista antes de cambiala. Ampliar o acceso CONNECT a todos os portos é un cambio substancial; non debería ser a resposta predeterminada ante unha discrepancia do envoltorio.
Se a aplicación ten soporte nativo de proxy HTTP, usalo pode evitar un túnel xenérico innecesario para HTTP de texto simple. Se de verdade necesita un túnel TCP en bruto, escolla un protocolo de proxy e unha política de portos aprobados que o fornezan.
Unha petición de navegador exitosa é unha proba útil sobre a accesibilidade do proxy e sobre un modo de petición admitido. Non demostra que todos os métodos de tunelización, portos de destino ou protocolos de aplicación estean permitidos a través dese proxy.