El navegador carrega una pàgina HTTP a través de Squid. La mateixa destinació falla sota proxychains. Això no vol dir necessàriament que un dels dos programes hagi triat una IP de proxy incorrecta.

Un client normal que entén HTTP pot enviar la petició web al proxy directe en forma de proxy HTTP. En canvi, un embolcall de sòcols genèric necessita un túnel de bytes per a la connexió que l'aplicació volia obrir. Per a un proxy HTTP de la seva cadena, proxychains fa servir CONNECT.

Això vol dir que un lloc web de text pla al port 80 pot generar una petició CONNECT per al port 80. Una política de Squid que només permet CONNECT cap a la seva llista aprovada de ports TLS pot rebutjar aquest túnel tot i que les peticions HTTP normals al port 80 sí que estan permeses.

Compareu peticions, no només noms d'amfitrió

La documentació de proxychains-ng descriu el seu suport d'HTTP CONNECT. Les regles d'accés de Squid poden distingir el mètode i el port de destinació. Són camins de petició diferents cap al mateix lloc web.

Llegiu el rebuig i la política prevista abans de canviar-la. Ampliar l'accés CONNECT a tots els ports és un canvi substancial; no hauria de ser la resposta per defecte a una discrepància d'embolcall.

Si l'aplicació té suport natiu de proxy HTTP, usar-lo pot evitar un túnel genèric innecessari per a HTTP de text pla. Si de debò necessita un túnel TCP cru, trieu un protocol de proxy i una política de ports aprovats que el proporcionin.

Una petició de navegador reeixida és una prova útil sobre l'abast del proxy i sobre un mode de petició suportat. No demostra que tots els mètodes de tunelatge, ports de destinació o protocols d'aplicació estiguin permesos a través d'aquell proxy.

Articles relacionats