Cómo leer un error SO_ORIGINAL_DST de Squid

NF getsockopt(SO_ORIGINAL_DST) apunta a una búsqueda del destino original. En una configuración de interceptación, Squid debe recuperar hacia dónde iba originalmente la conexión redirigida.

Un navegador configurado explícitamente envía sus peticiones al proxy a propósito. Esa conexión no adquiere historial de interceptación NAT solo porque junto al puerto del oyente de Squid aparezca intercept.

Por eso este desajuste puede fallar antes de que el certificado del destino sea relevante.

Empiece por cómo llegó la conexión

• Si la aplicación tiene configurada una dirección de proxy, identifique el oyente de proxy de reenvío habitual que debería usar.
• Si una puerta de enlace redirige tráfico que de otro modo sería directo, compruebe que llega al oyente de interceptación previsto y que el diseño NAT compatible conserva la información de destino necesaria.
• Si existen ambos modos, compruebe a qué dirección y puerto se conectó realmente el cliente que falla.

La documentación de http_port de Squid marca la distinción con claridad: omitir una marca de modo selecciona el modo de proxy de reenvío; intercept espera interceptación NAT en la capa IP.

Después trate la seguridad del transporte por separado. Un proxy HTTP puede transportar HTTPS mediante CONNECT. Una conexión TLS al proxy requiere un oyente y una configuración de cliente compatibles. Descifrar el tráfico hacia el destino es otra capacidad opcional distinta.

No copie una vieja “solución HTTPS” que activa la generación de certificados solo porque la URL de destino empiece por HTTPS. Primero repare el acuerdo entre el cliente y el oyente. Si después queda un error TLS real, será un error más útil que investigar.