jueves, 22 de junio de 2017

Apuntes sobre el error de Squid / SquidGuard en Debian: Solucionado

La nueva versión de Debian ha salido el sábado pasado. Y me aventuré a probar que se hubiera solucionado el problema con redirector protocol que detuvo tan mal a mi proyecto de firewall.

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=3
Pero 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.

Otros apuntes interesantes

Otros apuntes interesantes