Pues resulta que no, el problema seguía siendo tal, pero esta vez tenía un poco más de tiempo disponible que la última vez (Y un problema más serio, al estar dos lanzamientos atrasados con el sistema base).
Lo quiero resumir de esta forma: El problema no era tal.
Básicamente porque es un problema que es posible resolver con un cambio en la configuración, no se debía (No del todo, al menos) a un falta de actualización en la forma en que squidGuard entendía el redirector protocol, como yo pensé en mi primer post
El truco está en la configuración del redirector en Squid. Por defecto, yo tenía
url_rewrite_children 15 startup=0 idle=1 concurrency=3Pero según la documentación en Squid configuration directive url_rewrite_children:
concurrency= The number of requests each redirector helper can handle in parallel. Defaults to 0 which indicates the redirector is a old-style single threaded redirector. When this directive is set to a value >= 1 then the protocol used to communicate with the helper is modified to include an ID in front of the request/response. The ID from the request must be echoed back with the response to that request.
La cuestión es que al programa configurado como redirector le debe llegar una petición por parte de squid de la siguiente forma:
"http://www.google.com.sv/ 10.168.3.5/10.168.3.5 - GET myip=10.168.3.1 myport=3128";Pero configurado concurrency, tal como lo ha dicho la documentación, se le antepone un identificador, de modo que la consulta queda de la siguiente forma.
"0 http://www.google.com.sv/ 10.168.3.5/10.168.3.5 - GET myip=10.168.3.1 myport=3128";Lo que pasa es que lo interpreta mal: Para el, la URL que se solicita es 0 y el identificador del cliente es la URL; de hecho, toma a http: como la dirección IP del cliente, es decir, la primera parte de ip_cliente/fqdn...
La solución es algo tan sencillo como retirar concurrency:
url_rewrite_children 15 startup=0 idle=1 concurrency=0
Si bien squidGuard debería ser capaz de manejar este problema, pues no, no voy a reclamarle tanto a la única opción viable frente a cosas como e2guardian.
Yo mismo he intentando parchear el paquete en Debian, intentando quitar el ID de la petición antes de que squidGuard lo siguiera parseando, pero tampoco, es que aunque ha funcionado parece que todo va mal, las respuestas hacia el cliente ralentizan la navegación. Que ni siquiera revisé los log de Squid con mayor detenimiento, es que tampoco tengo todo el tiempo del mundo.
