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.
- 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
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.
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|
| ${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.
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 17telnet@ServerIron(config-if-17)# ip-policy 1
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
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.
