Proxychains através do Squid: restrições CONNECT na porta 80
Distinga pedidos HTTP proxy comuns dos túneis HTTP CONNECT do proxychains quando a porta 80 de destino é negada.
O navegador carrega uma página HTTP através do Squid. O mesmo destino falha sob o proxychains. Isso não significa necessariamente que um dos dois programas escolheu um IP de proxy errado.
Um cliente comum que entende HTTP pode enviar o pedido web ao proxy de encaminhamento na forma de proxy HTTP. Um invólucro de socket genérico, em vez disso, precisa de um túnel de bytes para a ligação que a aplicação queria abrir. Para um proxy HTTP na sua cadeia, o proxychains usa CONNECT.
Isso significa que um site de texto simples na porta 80 pode gerar um pedido CONNECT para a porta 80. Uma política do Squid que só permite CONNECT para a sua lista aprovada de portas TLS pode rejeitar esse túnel, ainda que os pedidos HTTP normais para a porta 80 sejam permitidos.
Compare pedidos, não apenas nomes de host
A documentação do proxychains-ng descreve o seu suporte a HTTP CONNECT. As regras de acesso do Squid conseguem distinguir método e porta de destino. São caminhos de pedido diferentes para o mesmo site.
Leia a rejeição e a política pretendida antes de a alterar. Alargar o acesso CONNECT a todas as portas é uma mudança substancial; não deve ser a resposta predefinida a uma incompatibilidade de invólucro.
Se a aplicação tiver suporte nativo de proxy HTTP, usá-lo pode evitar um túnel genérico desnecessário para HTTP de texto simples. Se precisar realmente de um túnel TCP em bruto, escolha um protocolo de proxy e uma política de portas aprovados que o forneçam.
Um pedido de navegador bem-sucedido é uma prova útil sobre a acessibilidade do proxy e sobre um modo de pedido suportado. Não prova que todos os métodos de tunelização, portas de destino ou protocolos de aplicação sejam permitidos através desse proxy.