Ler um erro SO_ORIGINAL_DST do Squid
Verifique se um cliente configurado explicitamente chegou a um ouvinte de interceção antes de diagnosticar uma falha na procura do destino original no Squid.
NF getsockopt(SO_ORIGINAL_DST) aponta para uma procura do destino original. Numa configuração de interceção, o Squid tem de recuperar para onde a ligação redirecionada se dirigia originalmente.
Um navegador configurado explicitamente envia os seus pedidos ao proxy de propósito. Essa ligação não adquire histórico de interceção NAT só porque intercept está escrito ao lado da porta do ouvinte do Squid.
Por isso, esta discordância pode falhar antes de o certificado do destino ser relevante.
Comece por como a ligação chegou
- Se a aplicação tem um endereço de proxy configurado, identifique o ouvinte normal de proxy de encaminhamento que deve utilizar.
- Se um gateway redireciona tráfego que de outra forma seria direto, verifique se chega ao ouvinte de interceção pretendido e se o desenho NAT suportado preserva a informação de destino necessária.
- Se ambos os modos existirem, verifique que endereço e porta o cliente que falha contactou realmente.
A documentação de http_port do Squid torna a distinção explícita: omitir um sinalizador de modo seleciona o modo de proxy de encaminhamento; intercept espera interceção NAT ao nível de IP.
Depois trate a segurança do transporte em separado. Um proxy HTTP pode transportar HTTPS através de CONNECT. Uma ligação TLS ao proxy exige um ouvinte e uma configuração de cliente compatíveis. Decifrar o tráfego para o destino é ainda outra capacidade opcional.
Não copie uma antiga “solução HTTPS” que ativa a geração de certificados só porque o URL de destino começa por HTTPS. Corrija primeiro o entendimento entre o cliente e o ouvinte. Se depois restar um erro TLS real, será um erro mais útil de investigar.