Proxychains via Squid : restrictions CONNECT sur le port 80
Distinguez les requêtes HTTP proxy ordinaires des tunnels HTTP CONNECT de proxychains lorsque le port 80 de destination est refusé.
Le navigateur charge une page HTTP via Squid. La même destination échoue sous proxychains. Cela ne signifie pas forcément que l'un des deux programmes a choisi une mauvaise IP de proxy.
Un client ordinaire qui comprend HTTP peut envoyer la requête web au proxy direct sous la forme d'un proxy HTTP. Un enrobage de socket générique a en revanche besoin d'un tunnel d'octets pour la connexion que l'application voulait ouvrir. Pour un proxy HTTP de sa chaîne, proxychains utilise CONNECT.
Cela signifie qu'un site en texte clair sur le port 80 peut produire une requête CONNECT pour le port 80. Une règle Squid qui n'autorise CONNECT que vers sa liste approuvée de ports TLS peut rejeter ce tunnel alors même que les requêtes HTTP ordinaires vers le port 80 sont autorisées.
Comparez les requêtes, pas seulement les noms d'hôte
La documentation de proxychains-ng décrit sa prise en charge de HTTP CONNECT. Les règles d'accès de Squid savent distinguer la méthode et le port de destination. Ce sont des chemins de requête différents vers le même site.
Lisez le refus et la règle visée avant de la modifier. Étendre l'accès CONNECT à tous les ports est un changement important ; ce ne devrait pas être la réponse par défaut à une incompatibilité d'enrobage.
Si l'application prend nativement en charge le proxy HTTP, l'utiliser peut éviter un tunnel générique inutile pour du HTTP en clair. Si elle a vraiment besoin d'un tunnel TCP brut, choisissez un protocole de proxy et une règle de ports approuvés qui en fournissent un.
Une requête de navigateur réussie est une preuve utile de l'accessibilité du proxy et d'un mode de requête pris en charge. Elle ne prouve pas que toutes les méthodes de tunnellisation, ports de destination ou protocoles applicatifs sont autorisés à travers ce proxy.