Llegir un error SO_ORIGINAL_DST de Squid

NF getsockopt(SO_ORIGINAL_DST) apunta a una cerca de la destinació original. En una configuració d'intercepció, Squid ha de recuperar cap a on anava originalment la connexió redirigida.

Un navegador configurat explícitament envia les seves peticions al proxy a propòsit. Aquesta connexió no adquireix historial d'intercepció NAT només perquè hi hagi intercept escrit al costat del port de l'oient de Squid.

Així, aquest desajust pot fallar abans que el certificat de la destinació sigui rellevant.

Comenceu per com ha arribat la connexió

• Si l'aplicació té una adreça de proxy configurada, identifiqueu l'oient de proxy directe habitual que hauria d'utilitzar.
• Si una passarel·la redirigeix trànsit que d'altra manera seria directe, comproveu que arriba a l'oient d'intercepció previst i que el disseny NAT compatible conserva la informació de destinació necessària.
• Si existeixen tots dos modes, comproveu a quina adreça i port s'ha connectat realment el client que falla.

La documentació de http_port de Squid ho distingeix clarament: ometre un indicador de mode selecciona el mode de proxy directe; intercept espera intercepció NAT a la capa IP.

Després tracteu la seguretat del transport per separat. Un proxy HTTP pot transportar HTTPS mitjançant CONNECT. Una connexió TLS al proxy requereix un oient i una configuració de client compatibles. Desxifrar el trànsit de destinació és una altra capacitat opcional.

No copieu una antiga “solució HTTPS” que activa la generació de certificats només perquè l'URL de destinació comença per HTTPS. Primer repareu l'acord entre el client i l'oient. Si després queda un error TLS real, serà un error més útil d'investigar.