SQUID como Proxy TransparenteSiguiendo 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 tcnica: No es necesario configurar a los clientes. Esta es la razn mas popular para investigar esta opcin. 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. Tambin hay desventajas de esta estrategia La intercepcin HTTP rompe el estndar TCP/IP por que el user-agents piensan que estn 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 estn 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 autenticacin 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 redireccin 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, diseado para prevenir la suplantacin de direcciones ( address spoofing). 2 Requerimientos y mtodos 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 configuracin 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 envan 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 sern capaz de navegar del todo. T DEBES probar la

configuracin en un ambiente no productivo antes habilitar esta caracterstica 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, tambin necesitan ser configurados. Para algunos sistemas operativos, necesitas tener configurado y construir una versin de Squid que pueda reconocer las conexiones hijacked y dicernir la direccion de destino.

Para Linux configurar Squid con la opcin: --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-transparentHacer 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 mtodos de intercepcin 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 direccin IP en el puerto 80) y entregarlos a la aplicacin 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 mayora de los sistemas, esto puede requerir reconstruir el kernel o agregar un nuevo modulo. 3.2.1 Inteception Caching, redireccin 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 opcin ./configure --enable-ipfw-transparent. Configurar Squid para saber que la IP esta siendo interceptada http_port 3129 transparent Configuracin 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 deberas ver la cache llenarse y mayor velocidad de navegacin. 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 debera 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 mtodos de redireccin del trafico HTTP al servidor SQUID. Solo es de mi interes la configuracin de los Switches Foundry, por lo que obviare los dems apartados. 3.3.2 Redireccin 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 configuacin: 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 redireccin 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 caracterstica de SQUID 2.6 la cual mejora el estndar de Interception Caching, ocultando la presencia de t cache. Normalmente con Interception Caching el servidor remoto ve a la ingeniera 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 caracterstica 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 polticas 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 estn 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 enva de vuelta un TCP RESET al cliente, lo cual aborta el requerimiento del cliente. Para trabajar sobre este problema, puedes instalar una ruta esttica a la interface "null0" para la direccin de la cache con una mtrica alta (baja precedencia) tal como 250. Entonces, cuando el link cae (goes down), los paquetes desde el cliente sern dropeados en vez de ser enviados a la ruta por defecto. Por ejemplo, si la IP 1.2.3.4 es la direccin del SQUID cache, puedes agregar: ip route 1.2.3.4 255.255.255.255 Null0 250 Esto parece causar el correcto comportamiento.