LINUCA: Proxy transparente en red local con Squid $LOGOIMAGE

LINUCA - Asociación Usuarios GNU/Linux de Cantabria

Proxy transparente en red local con Squid (59307 lecturas)
Por David MartÃ−n, tasio (http://tasio.net/)
Creado el 03/01/2004 13:36 modificado el 03/01/2004 13:36

En ocasiones puede resultar interesante contar con un proxy dentro de la red que agilice el acceso a
información ahorrando el máximo ancho de banda posible y aumentando la velocidad de carga de
webs que visitamos con frecuencia, o por ejemplo, si contamos con varias máquinas.

Un proxy transparente nos va a proporcionar muchas ventajas y, gracias a las avanzadas posibilidades de squid, más
bien pocos inconvenientes:

• Listas de acceso complejas para modificar a nuestro gusto los permisos

• Caché 'inteligente' para imágenes y demás objetos que no es necesario descargar continuamente.
♦ Asimismo, posibilidad de no cachear contenido dinámico (php, asp, cgi-bin)
♦ Limites para el tamaño de objeto, para no cachear objetos excesivamente grandes como isos o mp3,
o para no permitir su descarga, útil en entornos de trabajo.
• Posibilidad de conectarlo a su vez a otro proxy
• Al ser transparente (al menos para los usuarios de la red), no será necesario configurar absolutamente nada
en éstos.

Para este caso, fundamento el artÃ−culo en Debian GNU/Linux (Sid), utilizando iptables y squid para el proxy, y con
una máquina actuando de puerta de enlace entre la red local e Internet.

Deberemos contar con sendos paquetes antes de nada:

apt-get install squid iptables

Por descontado, en nuestro kernel deberÃ−a haber soporte para netfilter/iptables.

Antes de poner las reglas de filtrado, echemos un vistazo a las opciones del/etc/squid.conf que nos va a interesar
modificar para que el proxy actúe como transparente.

Antes de nada: Las "listas de acceso" o ACL son un tipo especial de expresiones condicionales mediante las cuales se
configura gran parte del sistema, luego es importante conocerlas.

Están formadas por 3 elementos:

acl nombre_de_la_regla método_de_actuación expresión_coincidente

El nombre de la regla es una expresión arbitraria. El método de actuación puede ser:

Dirección de orÃ−gen. La expresión coincidente puede ser una dirección IP, o un conjunto
src
de direcciones (siempre en formato CIDR), nunca un host.
dst Dirección de destino, con el mismo formato que la anterior
Se evalúa en función de la dirección ip por la que le llegue al squid la petición. Se trata de
myip
su dirección IP.

1/4
LINUCA: Proxy transparente en red local con Squid $LOGOIMAGE

srcdomain Evalúa el nombre del host del que procede la petición.

dstdomain Evalúa el destino de la petición a partir de su host.
srcdom_regex y Evalúa los nombres de dominio de orÃ−gen o destino, pudiéndose utilizar expresiones
dstdom_regex regulares POSIX para encontrar coincidencias.
time Evalúa en función de tiempo
Regla muy útil. Evalúa toda la dirección que el cliente solicite, empezando desde http://..
url_regex
incluÃ−do. Se utilizarán expresiones regulares.
Igual que la anterior, sólo que se empieza a evaluar a partir del primer / que se encuentre por
urlpath_regex
detrás del nombre de dominio.
Método con el que se trate de obtener el contenido. Los más usuales son GET, POST,
method
CONNECT y, en algunos casos, PUT.
Esto se utiliza para detectar cuándo un cliente ha alcanzado un máximo de conexiones, que
maxconn
especificaremos en su expresión coincidente con un número entero positivo.
Se utiliza para evaluar en función del tipo de dato que el cliente solicite, pudiendo ser algo
rep_mime_type como application/x-javascript o application/x-msdos-program. Consultar /etc/mime.types para
ver una lista.

Nótese que las expresiones son sensibles a mayúsculas. Si queremos que no lo sean, deberemos anteponerles el
parámetro -i

Hay más tipos de ACLs, pero no merece la pena comentarlas aquÃ−, debido a su falta de utilidad para nuestro
propósito.

Las reglas definidas mediante ACLs ya pueden utilizarse conjuntamente con el resto de aspectos de configuración del
squid.conf. Seguramente, vengan ya algunas en nuestro archivo, que nos ahorrarán algo de trabajo. En particular,
merece la pena añadir una ACL para que coincida con nuestra red local.

acl redlocal src 10.0.0.0/24

y a este conjunto de direcciones, permitirles el uso del proxy.

http_access allow redlocal

Las reglas se definen de ese modo.

accion allow|deny ACL

Algunas de las acciones son:

http_access Controlar si lo que coincide con la ACL tiene acceso al proxy

En este caso, deny sirve para impedir que se cachee lo que coincida con el ACL y allow para forzarlo.
Es útil utilizar una ACL de tipo urlpath_regex aquÃ−. Ejemplo:

acl NOCACHE urlpath_regex -i cgi-bin \? \.gz$ \.bz2$

no_cache no_cache deny NOCACHE

Esta regla impide el cacheo de páginas con contenido dinámico y de archivos con extensiones (.gz,
.bz2) que no merece la pena cachear. Es además insensible a mayúsculas, por si cae algún *.ISO
por ejemplo.
à til si tenemos el squid conectado a otro proxy, para evitar que lo definido en el ACL se pida al otro
always_direct proxy, prefiriendo descargarlo el propio squid directamente. Ã til sobre todo para archivos grandes que
no merezca la pena hacer pasar por 2 proxies
never_direct El opuesto al anterior, para forzar el uso de otros proxies.
Nota: Existe una preferencia. Un deny con un allow por encima que coincida con lo mismo no funcionará

2/4
LINUCA: Proxy transparente en red local con Squid $LOGOIMAGE

Esto es a grandes rasgos, lo más importante a tener en cuenta respecto a las listas de acceso. Ahora vamos a lo que nos
interesa, el proxy transparente.

En primer lugar, hay algunas lÃ−neas que hay que tener en cuenta para que funcione del modo que esperamos:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_single_host off
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

Además, si queremos realizar caché de lo que pase por el proxy, de modo que aceleremos al máximo la velocidad
del mismo deberemos tener:

offline_mode on

Puede no interesarnos que se sepa que estemos utilizando un proxy, la versión, o lo que tenemos conectado detrás.
Para eso, podemos utilizar:

header_access X-Forwarded-For deny all

header_access Via deny all

Y ya puestos, podemos reemplazar algunas cabeceras, como la identidad del proxy o del navegador del cliente, los
lenguajes que preferimos...:

header_access Accept-Language deny all

header_replace Accept-Language es,en

Es importante, para modificar una cabecera, eliminarla antes con header_access:

header_access User-Agent deny all

header_replace User-Agent Nutscrape/1.0 (CP/M; 8-bit)

Nota: 'all' en el header_access procede de otra ACL denominada asÃ−, normalmente definida siempre como "src
0.0.0.0/0", que coincide en todos los casos.

Con respecto al caché, interesa tener en cuenta un par de aspectos, como son el tamaño máximo de los objetos
cacheados, y el tamaño total que podrá utilizar el propio caché.

cache_dir aufs /var/spool/squid 600 16 256

Esta lÃ−nea tiene mucha sustancia. En primer lugar, indica el tipo de caché que vamos a utilizar. "aufs" utiliza
POSIX-threads, lo que hará que Squid trabaje con hilos independientes para tareas de E/S, que lo van a acelerar
bastante. El siguiente parámetro es el directorio donde estará la caché de disco. Es buena idea mantenerlo separado
del resto de sistemas de archivos. Lo siguiente, el 600, es el tamaño máximo en MB que puede ocupar la caché de
disco. Cuando se alcance, los elementos antiguos serán sobreescritos por los que vayan llegando. Los otros dos
parámetros sirven para controlar la fragmentación de los elementos, esos valores son aptos.

maximum_object_size 4096 KB

Los objetos con un tamaño por encima de 4096 KB no serán almacenados en disco.

Para utilizar squid conjuntamente con otro caché:

cache_peer 1.2.3.4 parent 8080 0 no-query

Esto hará que, a menos que se haya especificado con un ACL antes, las peticiones vayan a través del caché
1.2.3.4, puerto 8080 en lugar de efectuarse directamente. Esto puede serle útil a quienes vivan, como yo, con el proxy
de telefónica tocándonos la moral. Al menos acá, da bastantes problemas, amén de que a nivel nacional ese proxy
vela por que no podamos acceder a contenidos que al gobierno le parecen politicamente incorrectos. En otros casos, en
algunas webs, los proxies de telefónica están en listas negras que impiden el acceso a las mismas. De este modo,
podremos saltárnoslo. Nos interesarÃ−a añadir además:

3/4
LINUCA: Proxy transparente en red local con Squid $LOGOIMAGE
nonhierarchical_direct off
prefer_direct off

Por cierto, los cambios realizados en el squid.conf se pueden re-leer por completo rápidamente mediante un
/etc/init.d/squid reload, sin necesidad de un restart, que por lo general tarda bastante.

Hay muchas más opciones que no he tratado aquÃ− por querer hacerlo lo más breve posible, pero en el squid.conf
vienen muy bien explicadas.

En cuanto a iptables, podemos apañarnos con esta regla:

iptables -t nat -A PREROUTING -i eth1 -s 10.0.0.0/24 -d ! 10.0.0.0/24 -p tcp --dport 80 -j REDIRECT --to-port 3128

En este caso, eth1 es el interfaz conectado a la red local. Todo lo procedente de 10.0.0.0/24, pero que no vaya
encaminado a 10.0.0.0/24, nos lo va a encaminar al puerto 3128, que es donde normalmente tendremos squid.

Enlaces relacionados:

• www.squid-cache.org(1)
• www.netfilter.org(2)

Lista de enlaces de este artÃ−culo:

1. http://www.squid-cache.org/
2. http://www.netfilter.org

E-mail del autor: tasio _ARROBA_ tasio.net

Podrás encontrar este artÃ−culo e información adicional en: http://linuca.org/body.phtml?nIdNoticia=246

4/4