Lire une erreur SO_ORIGINAL_DST de Squid

NF getsockopt(SO_ORIGINAL_DST) indique une recherche de la destination d'origine. Dans une configuration d'interception, Squid doit retrouver où la connexion redirigée se rendait à l'origine.

Un navigateur explicitement configuré envoie ses requêtes au proxy volontairement. Cette connexion n'acquiert pas un historique d'interception NAT simplement parce que intercept figure à côté du port de l'écouteur Squid.

Ce décalage peut donc échouer avant même que le certificat de la destination n'entre en jeu.

Commencez par la façon dont la connexion est arrivée

• Si l'application dispose d'une adresse de proxy, identifiez l'écouteur de proxy de transfert ordinaire qu'elle doit utiliser.
• Si une passerelle redirige un trafic qui serait sinon direct, vérifiez qu'elle atteint l'écouteur d'interception prévu et que la conception NAT prise en charge conserve les informations de destination nécessaires.
• Si les deux modes existent, vérifiez quelle adresse et quel port le client en échec a réellement contactés.

La documentation http_port de Squid rend la distinction explicite : omettre un indicateur de mode sélectionne le mode proxy de transfert ; intercept attend une interception NAT au niveau IP.

Traitez ensuite la sécurité du transport séparément. Un proxy HTTP peut transporter HTTPS via CONNECT. Une connexion TLS vers le proxy exige un écouteur et une configuration client compatibles. Déchiffrer le trafic vers la destination est encore une autre capacité facultative.

Ne copiez pas un ancien “correctif HTTPS” qui active la génération de certificats simplement parce que l'URL de destination commence par HTTPS. Réparez d'abord l'accord entre le client et l'écouteur. S'il reste ensuite une véritable erreur TLS, ce sera une erreur plus utile à examiner.