Proxychains a través de Squid: restricciones de CONNECT en el puerto 80
Distinga las peticiones HTTP normales a través del proxy de los túneles HTTP CONNECT de proxychains cuando se deniega el puerto 80 de destino.
El navegador carga una página HTTP a través de Squid. El mismo destino falla con proxychains. Eso no significa necesariamente que uno de los dos programas haya elegido una IP de proxy incorrecta.
Un cliente normal que entiende HTTP puede enviar la petición web al proxy de reenvío en forma de proxy HTTP. En cambio, un envoltorio de sockets genérico necesita un túnel de bytes para la conexión que la aplicación quería abrir. Para un proxy HTTP de su cadena, proxychains usa CONNECT.
Eso significa que un sitio web de texto plano en el puerto 80 puede generar una petición CONNECT para el puerto 80. Una política de Squid que solo permite CONNECT hacia su lista aprobada de puertos TLS puede rechazar ese túnel aunque las peticiones HTTP normales al puerto 80 estén permitidas.
Compare peticiones, no solo nombres de host
La documentación de proxychains-ng describe su compatibilidad con HTTP CONNECT. Las reglas de acceso de Squid pueden distinguir el método y el puerto de destino. Son rutas de petición distintas hacia el mismo sitio web.
Lea el rechazo y la política prevista antes de cambiarla. Ampliar el acceso CONNECT a todos los puertos es un cambio sustancial; no debería ser la respuesta predeterminada ante una discrepancia del envoltorio.
Si la aplicación tiene compatibilidad nativa con proxy HTTP, usarla puede evitar un túnel genérico innecesario para HTTP de texto plano. Si de verdad necesita un túnel TCP en bruto, elija un protocolo de proxy y una política de puertos aprobados que lo proporcionen.
Una petición de navegador exitosa es una prueba útil sobre el alcance del proxy y sobre un modo de petición admitido. No demuestra que todos los métodos de tunelización, puertos de destino o protocolos de aplicación estén permitidos a través de ese proxy.