SQUID como Proxy Transparente

Siguiendo con las FAQ's de SQUID, esta vez voy a cubrir las notas para transformar a squid en un proxy transparente o un Interception Cache en mi laboratorio.

1 Conceptos de Interception Caching 
  Interception Caching, es el proceso por el cual las conexiones HTTP proveniente de clientes remotos son redireccionadas a un servidor de cache, sin conocimiento o configuraciones explicitas.
Hay buenas razones por las que se puede esperar usar esta técnica:

• No es necesario configurar a los clientes. Esta es la razón mas popular para investigar esta opción.
• Puedes implementar mejor y mas seguras estrategias para mantener el acceso de los clientes en caso de que la infraestructura de chache quede fuera de servicio.

También hay desventajas de esta estrategia

• La intercepción HTTP rompe el estándar TCP/IP por que el user-agents piensan que están hablando directamente con el servidor.
• Requiere IPV4 con NAT.
• Esto causa que el path MUT (PMTU) falle, haciendo posiblemente algunos sites inaccesibles. Esto no es usualmente un problema si las clientes clientes están conectadas via Ethernet o DSL PPPo, donde el MTU de todos los enlaces entre los clientes y la cache es 1500 o mas. 
• EL Proxy authentication no trabaja, y la autenticación basada en IP falla conceptualmente por que los usuarios son todos vistos como provenientes desde la ip propia del proxy.
• Interception Caches solamente soporta el protocolo HTTP, ni Gopher, SSL, ni FTP. No puedes configurar reglas de redirección al servidor proxy para otros protocolos que no sean HTTP ya que este no conocera como tratar con esto.
• Interception Cache es incompatible con IP filtering, diseñado para prevenir la suplantación de direcciones ( address spoofing).

2 Requerimientos y métodos para el Interception Cache

• Es necesario un buen entendiemiento de los que estas haciendo antes de comenzar. Esto involucra entendimiento de las capas TCP (TCP layers) de que esta sucediendo en las conexiones.
• Muy probablemente necesitaras un dispositivo de red el cual pueda redireccionar el trafico a tu cache.
• Si estas usando routers y switches Cisco en tu red puedes estar interesado en investigar el uso de WCCP.

3 Pasos involucrados en la configuración del Interception Caching

• Construir un Squid con las opciones correctas en ./configure para soportar la redireccion y el manejo de clientes de forma correcta.
• Rutear el trafico desde el puerto 80 al puerto de tu Squid es configurado para aceptar las conexiones.
• Desencapsular el trafico que los dispositivos de red envían al Squid (solamente si tu estas usando GRE o WCCP para interceptar el trafico).
• Configurar los dispositivos de red para redireccionar el trafico del puerto 80.

Los dos primeros pasos son requeridos y los dos últimos pueden no ser requeridos dependiendo de como intentas rutear el trafico HTTP a tu cache.

Es critico leer todos los comentarios en el archivo squid.conf y en este documento antes de comenzar. Lograr que el Interception Caching trabaje con Squid no es trivial y requiere de muchos subsistemas (servicios) de la red y de Squid sean configurados correctamente, sino encontraras que esto trabaja y tus usuarios no serán capaz de navegar del todo. Tú DEBES probar la configuración en un ambiente no productivo antes habilitar esta característica a los usuarios.

3.1 Compilar una version de Squid la cual acepte conexiones desde otras direcciones

  Primeramente necesitamos preparar Squid con las opciones correctas en ./configure y luego configurar squid.conf para soportar Intercepting Caching.

3.1.1 Elegir las opciones correctas para pasarle a ./configure

  Todas las versiones soportadas de Squid corrientemente disponibles soportan Interception Caching, sin embargo para que esto trabaje correctamente tu sistema operativo y red, también necesitan ser configurados. Para algunos sistemas operativos, necesitas tener configurado y construir una versión de Squid que pueda reconocer las conexiones hijacked y dicernir la direccion de destino.

• Para Linux configurar Squid con la opción: --enable-linux-netfilter
• Para sistemas basados en BSD configuar Squid con la opcion: --enable-ipfw-transparent.
• Si estas usando OpenBSD's PF configurar Squid con --enable-pf-transparent

Hacer un "make clean" si previamente has configurado Squid sin estas opciones o las confguraciones pueden no presentarse.

Squid2.6+ y Squid3.0+ soportan WCCPv1 y WCCPv2 por defecto.

3.1.2 Configurar SQUID para aceptar y procesar las conexiones redirigidas del puerto 80
  Tienes que cambiar las configuraciones de Squid para reconocer las conexiones hijacked y identificar las direcciones de destino.
Un numero de métodos de intercepción y sus especificas configuraciones es detallada en ConfigExamples/Intercept.
3.2 Recibiendo el trafico sobre el verdadero puerto de Squid

  Tienes que configurar el host cache para aceptar los paquetes redirigidos (cuaqluier dirección IP en el puerto 80) y entregarlos a la aplicación cache . Esto se hace con IP filtering/forwarding.

• Sobre Linux 2.4 y posteriores esto es llamado iptables
• Sobre FreeBSD es llamdo ipfw.
• Otros sistemas BSD pueden usar ip filter, ipnat o pf.

Sobre la mayoría de los sistemas, esto puede requerir reconstruir el kernel o agregar un nuevo modulo.

3.2.1 Inteception Caching, redirección de paquetes para Solaris, SunOS, y sistemas BSD

  No es necesario usar IP Filter sobre FreeBSD, en vez de ello utilizar ipfw.

Navegando un poquito el anterior link (ConfigExamples/Intercept) he localizado las configuraciones especificas para que FreeBSD  intercepte los paquetes para Squid 


Interceptando trafico con IPFW en FreeBSD
  Compilar e instalar SQUID con las opción ./configure --enable-ipfw-transparent.
Configurar Squid para saber que la IP esta siendo interceptada

• http_port 3129 transparent

Configuración de rc.firewall.local

+-------------------------------------------------------------------+

| IPFW=/sbin/ipfw |

| ${IPFW} -f flush | 
| ${IPFW} add 60000 permit ip from any to any | 
| ${IPFW} add 100 fwd SQUIDIP,3128 tcp from any to any 80 recv IFACE|

+-------------------------------------------------------------------+

Para probar si esto funciona usar la herraminta nc (netcat). Parar squid y como root tipear nc -l 3129

Luego inciar squid y intentar navegar en una pagina.
Se deberia ver una salida similar a esta:
+------------------------------------------------------+
|#nc -l 3129
|GET /mail/?ui=pb HTTP/1.1 |
|User-Agent: Mozilla/5.0 (compatible; GNotify 1.0.25.0)|
|Host: mail.google.com |
|Connection: Keep-Alive |
|Cache-Control: no-cache |
+------------------------------------------------------+

Desde aquí en adelante, configurar el browser sin proxy, y deberías ver la cache llenarse y mayor velocidad de navegación.

Volviendo al HowTo de Proxy Transparente

3.3 Enviando los paquetes desde los usuarios finales a tu cache server

  Hay varias maneras de hacer esto. Primero, si tu proxy ya esta en la ruta de los paquetes (la ruta entre los usuarios del proxy y internet) no tienes que preocuparte por estos pasos, Interception Caching ya debería estar trabajando. Si la cache no esta en la ruta natural de las conexiones, entonces tienes que desviar los paquetes de su ruta normal a tu host cache usando routers o switches.

Las subsiguientes configuraciones tratan los métodos de redirección del trafico HTTP al servidor SQUID. Solo es de mi interes la configuración de los Switches Foundry, por lo que obviare los demás apartados.

3.3.2 Redirección de paquetes con Switches Foundry L4
  Primero, configurar Squid como Interception Caching.
Luego, configurar el Foundry L4 para redireccionar el trafico a el/los Squid/s. Por defecto Foundry redirecciona al puerto 80 del Squid box. Esto puede ser cambiado a un puerto diferente si es necesario.
Adicionalmente el switch hace un "health check" del puerto (80) para asegurarse que el Squid esta respondiendo. Si Squid no responde, el switch por defecto envia el trafico directamente (a internet) en vez de redirigirlo a Squid. Cuando el Squid vuelve a estar activo comienza la redireccion nuevamente.
Este ejemplo asume que tienes dos Squid cache:
+----------------------------+

|squid1.foo.com  192.168.1.10|
|squid2.foo.com  192.168.1.11|

+--------------------------------------------+

El servidor SQUID debe estar conectado al switch. Solamente la interface donde esta conectado el router es importante. Donde se conecte el cache SQUID no es importante.
Este ejemplo supone que el router esta conectado en la interface 17 del switch. 

• Ingrese en modo configuación: telnet@ServerIron#conf t
• Configure cada SQUID en el Fundry

• telnet@ServerIron(config)# server cache-name squid1 192.168.1.10

• telnet@ServerIron(config)# server cache-name squid2 192.168.1.11
  

• Agregar los Squids a un cache-group
• telnet@ServerIron(config)#server cache-group 1
• telnet@ServerIron(config-tc-1)#cache-name squid1
• telnet@ServerIron(config-tc-1)#cache-name squid2
• Crear una politica para caching http sobre un puerto local
• telnet@ServerIron(config)# ip policy 1 cache tcp http local
• Activar la politica sobre el puerto conectado a tu router

• telnet@ServerIron(config)#int e 17

• telnet@ServerIron(config-if-17)# ip-policy 1

Ya que todo el trafico saliente a internet  pasa por la interface 17 (el router) y la interface 17 tiene la politica de caching aplicada, el trafico HTTP va a ser interceptado y redireccionado a las caches que tengamos configuradas.
El puerto por default para la redirección puede ser cambiado. El algoritmo usado para el balanceo de carga puede ser cambiado (Least Used, Round Robin,etc). Puertos pueden ser exentos del caching si es necesario. Listas de acceso (ACL) pueden ser aplicadas para que solamente ciertas direcciones IP sean redireccionadas,etc.


3.4 WCCP - Web Cache Cordinator Protocol
  En este momento no voy a trabajar con este protocolo, pero es importante saber que SQUID soporta WCCPv1 y WCCPv2.


3.5 TProxy Interception
  TProxy es una nueva característica de SQUID 2.6 la cual mejora el estándar de Interception Caching, ocultando la presencia de tú cache. Normalmente con Interception Caching el servidor remoto ve a la ingeniería de cache como la fuente de todas las peticiones HTTP. TProxy mejora este paso ocultando la ingieneria de cache haciendo que el cliente final sea visto como la fuente de las peticiones (aunque realmente no lo sea).
Esta nueva característica es interesante tenerla presente o saber de su existencia. Del Troubleshooting de este how to solo voy a tomar:


8.4 "Connection reset by peer" and Cisco policy routing
  Fyodor ha rastreado la causa de un inusual mensaje "connection reset by peer" cuando usas políticas de ruteo Cisco para hijack peticiones  HTTP. 
Cuando el link de red entre el router y la cache cae (goes down) por un instante, los paquetes que están supuestamente para ser redireccionados son enviados a la ruta por defecto. Si esto sucede, un TCP ACK puede ser enviado desde el host cliente al servidor de origen en vez de ser enviado a la cache. El servidor de origen, recibe un paquete inesperado ACK y envía de vuelta un TCP RESET al cliente, lo cual aborta el requerimiento del cliente.
Para trabajar sobre este problema, puedes instalar una ruta estática a la interface "null0"  para la dirección de la cache con una métrica alta (baja precedencia) tal como 250.
Entonces, cuando el link cae (goes down), los paquetes desde el cliente serán dropeados en vez de ser enviados a la ruta por defecto.
Por ejemplo, si la IP 1.2.3.4 es la dirección del SQUID cache, puedes agregar:

• ip route 1.2.3.4 255.255.255.255 Null0 250

Esto parece causar el correcto comportamiento.


Glosario


PMUT = Path MTU es la técnica para determinar el tamaño de la maxima unidad de transmisión (MTU)  on the network path entre dos IP's hosts, usualmente con el objetivo de evitar la fragmentación IP.
OpenBSD PF= Open BSD Packet Filter.
Helpers= Squid puede extenderse usando varios conjuntos de coprocesses (helpers) que manejan aspectos específicos, de los requerimientos o de las respuestas.

Comenzando con SQUID - El WEB Proxy Cache

Voy a tomar desde las FAQ's de Squid, lo que a mi entender resulta interesante  tener en cuenta, a la hora de diseñar y configurar un web proxy-cache (Squid).

¿ Cual es el tamaño del sistema que necesito para ejecutar Squid ?
  No hay reglas rígidas y rápidas. El recurso más importante  para Squid es la memoria física, colocar la mayor cantidad de memoria que se pueda.
Los procesadores no necesitan ser ultra rápidos, es recomendable comprar aquellos que sean económicos en el tiempo.
El disco de sistema sera el mayor cuello de botella, por lo tanto, discos rápidos son importantes para altos volumenes de cache. La performance de los discos SCSI generalmente es mejor que la de los discos ATA. Los discos SATA tienen una performance intermedia entre los discos SCSI y ATA. El disco de sistema y el disco de logfile pueden ser IDE, sin perder performance.
La relación memory-to-disk puede ser importante. Recomendamos 32 MB de RAM por cada GB de espacio de disco que se planea usar para cache.


¿ Es correcto usar discos separados para Squid ?
  Si, ejecutar squid sobre discos separados a los cual se ejecuta es sistema operativo es muchas veces una muy buena idea.
En general, el tiempo de búsqueda es lo que se espera optimizar o mas precisamente, la cantidad total de búsquedas que el sistema puede mantener. Por esta razón, es mejor tener la cache_dir sobre discos pequeños separados, que sobre un gran disco (especialmente con SCSI).
Si el sistema es muy exigido en E/S, desearas tener el sistema operativo y los directorios de log en discos separados.


¿ Que "cache_dir" size debo utilizar ?
  En este capitulo suponemos que se esta dedicando una porción entera del disco para el cache_dir de squid, como es a menudo.
En términos generales, configurar el tamaño del cache_dir igual que el tamaño de la partición, no suele ser una elección acertada. Primero por que Squid no es muy tolerante a ejecutarse fuera del espacio de disco. Sobre el tamaño limite del cache_size, squid usara un poco de espacio extra para el swap.state y algo mas de espacio temporal como área de trabajo, por ejemplo cuando re construye el swap.state.  Así que en cualquier caso asegurarse de dejar espacio extra para esto, o la cache entrara en un ciclo infinito de crash-rebuild.
La segunda razón es la fragmentación, los sistemas de archivos (filesystems) por si mismos pueden hacer mucho para evitar la fragmentación, y para ser efectivo necesitan espacio para optimizar la ubicación de los archivos. Si el disco esta lleno, la optimización es muy difícil y cuando el disco esta 100% lleno la optimización es imposible. Ten tú disco fragmentado y este sera seguramente tu peor cuello de botella.


¿ Como puedo ver estadísticas de squid a nivel de sistema ?
  Las distribuciones de squid incluyen una utilidad llamada cachemgr.cgi, la cual puede ser usada para ver las estadísticas de squid con un browser.


¿ Por que no puedo ejecutar Squid como Root ?
  Ni lo voy a traducir, es obvio.


¿ Puedes decirme una manera de Upgrade Squid con un tiempo mínimo de Downtime ?
  Esta es una técnica que fue descrita por Radu Greab.
Iniciar un segundo servidor (instancia)  Squid sobre un puerto HTTP sin uso (supongamos el 4128). Esta instancia de Squid probablemente no necesite una disco cache grande. Cuando esta segunda instancia (server) ha finalizado de recargar el almacenamiento de disco, cambiar el valor de http_port en squid.conf de ambas instancias. Configurar la instancia original para usar el puerto 5128 y la segunda para usar el puerto 3128. Después, ejecutar "squid -k reconfigure" para ambos Squids. Los nuevos requerimientos irán al segundo Squid ahora sobre el puerto 3128 y el primer Squid terminara de manejar sus actuales requerimientos. Después de unos minutos, es seguro el shutdown del primer squid y upgrade este. Posteriormente simplemente repite los pasos en orden inverso.

La instalación de Squid es sencilla, y esta bien documentada en las faq's de squid, aunque hay que tener en mente las facilities o helpers que se utilizaran, por ejemplo snmp.
En mi laboratorio estoy usando un FreeBSD 8.0, recompile el kernel para que estuviera 100% acorde al hardware y a la utilidad que le voy a dar. Instale Squid 2.7.9 desde los ports (compilando), esta versión tengo entendido que al día de la fecha es la mas estable y parcheada de todas.