Ler un erro SO_ORIGINAL_DST de Squid
Comprobe se un cliente configurado explicitamente chegou a un oínte de interceptación antes de diagnosticar un fallo na busca do destino orixinal en Squid.
NF getsockopt(SO_ORIGINAL_DST) apunta a unha busca do destino orixinal. Nunha configuración de interceptación, Squid debe recuperar cara a onde ía orixinalmente a conexión redirixida.
Un navegador configurado explicitamente envía as súas peticións ao proxy a propósito. Ese conexión non adquire historial de interceptación NAT só porque xunto ao porto do oínte de Squid apareza intercept.
Por iso este desaxuste pode fallar antes de que o certificado do destino sexa relevante.
Empece por como chegou a conexión
- Se a aplicación ten configurada unha dirección de proxy, identifique o oínte de proxy de reenvío habitual que debería usar.
- Se unha pasarela redirixe tráfico que doutro xeito sería directo, comprobe que chega ao oínte de interceptación previsto e que o deseño NAT compatible conserva a información de destino necesaria.
- Se existen ambos os modos, comprobe a que dirección e porto se conectou realmente o cliente que falla.
A documentación de http_port de Squid marca a distinción con claridade: omitir unha marca de modo selecciona o modo de proxy de reenvío; intercept espera interceptación NAT na capa IP.
Despois trate a seguridade do transporte por separado. Un proxy HTTP pode transportar HTTPS mediante CONNECT. Unha conexión TLS ao proxy require un oínte e unha configuración de cliente compatibles. Descifrar o tráfico cara ao destino é outra capacidade opcional distinta.
Non copie unha vella “solución HTTPS” que activa a xeración de certificados só porque o URL de destino comeza por HTTPS. Primeiro repare o acordo entre o cliente e o oínte. Se despois queda un erro TLS real, será un erro máis útil que investigar.