Intercepción de Squid frente a la autenticación de proxy explícita
Explique por qué la autenticación de proxy explícita habitual no puede añadirse sin más a un oyente de interceptación de Squid.
Un cliente de proxy explícito sabe que habla con un proxy. Un navegador interceptado cree que se ha conectado al sitio web. Esa diferencia es central para la autenticación.
La autenticación de proxy normal utiliza un desafío de proxy y una respuesta de autorización de proxy. Un cliente que no eligió un proxy no debería enviar sin más credenciales de proxy a un intermediario inesperado.
Por eso la guía de interceptación de Squid no admite combinar sin más proxy_auth con el modo de interceptación. Un auxiliar de autenticación Basic que funcione no cambia lo que el navegador cree que es el extremo remoto.
Si los usuarios identificados necesitan un proxy de reenvío autenticado normal, configure los clientes explícitamente, ya sea directamente o mediante una configuración de proxy administrada adecuada. Mantenga ese oyente y su política de autenticación separados de un oyente de interceptación.
Un portal de autenticación, un sistema de identidad a nivel de red o una disposición de interceptación TLS son otro diseño con requisitos de confianza y despliegue distintos. No es una reparación de una línea para el intercambio de proxy explícito que falta.
No resuelva la ausencia de una solicitud haciendo público el servicio interceptado ni permitiendo todos los clientes. Decida primero si el requisito es la autenticación explícita de usuarios o la interceptación de tráfico que nunca se configuró para un proxy. Requieren supuestos distintos.