Proteger el ancho de banda

Cada usuario tiene tendencia a utilizar el 100% del ancho de banda disponible, no sé si esto es una ley escrita, si no debería estarlo.

Pues ahora que tenemos instalada la red y el acceso mediante proxy cache vamos a intentar regular el consumo de ancho de banda. Resulta interesante que nadie pueda cometer abusos y consumir todos los recursos de la red a costa del resto de usuarios. La regulación del ancho de banda se puede llevar a cabo utilizando distintos criterios: la máquina origen, la dirección o página destino o el tipo de transferencia.

Por un lado podemos intentar discriminar el origen de los datos, resumiendo que los jefe dispongan de mejor conexión que los "pringaos". Resumiendo, vamos a asignar distintos anchos de banda a distintos rangos de direcciones IP.

También se no puede dar el caso de que haya consultas masivas a unos determinados dominios o páginas y puede ser práctico delimitar el ancho de banda asignado a ese dominio.

En general el volumen de tráfico que genera el acceso a páginas web en html es bastante bajo, lo que realmente consume un volumen apreciable del ancho de banda son ficheros de sonido e imagen y una medida posible podría ser limitar de alguna forma la transferencia de estos tipos de ficheros.

Otra posibilidad sería que limitar el ancho de banda sólo para descargas de ficheros grandes y dejar un mayor ancho de banda a ficheros pequeños para que la navegación por páginas html sea más rápida.

Mediante Squid podemos establecer límites al ancho de banda mediante una de sus características de configuración denominada "delay pools". Establecemos una definición de regulación de ancho de banda, establecemos una ACL y asociamos la regulación a la ACL.

Parámetros de configuración

Cada una de las reglas de regulación está definida por un número entero que vamos a utilizar para indentificarlo en los distintos parámetros.

delay_pools

Esta parámetro se utiliza para definir cuantas reglas de regulación vamos a definir.

delay_class

Este parámetro toma dos argumentos el primero el identificador de la regla y en segundo lugar el tipo (clase) de la regla.

El primero argumento es un número entero para identificar la regla.

El segundo argumento puede ser 1,2 ó 3 para indicar uno de estos tipos de reglas.

delay_parameters

establece los valores de la regla. Los argumentos de este parámetro son parejas de valores velocidad/tamaño, donde velociad es un número entero que indica una velocidad en bytes por segundo (B/s), y tamaño indica el número de bytes de reserva que se transmiten antes de aplicar la velocidad de transferencia.

Es decir cada pareja especifica el número de bytes de margen que se permiten antes de se haga efectiva la restricción de velocidad.

Los valores no tienen por qué ser múltiplos de 2.

Tipos de reglas

Hay tres clases de regulaciones, con características diferentes.

Clase 1

La clase uno consiste en un canal individual compartido por todos los usuarios. Es la clase más simple, todas las tasas de descarga van juntas y lo único que tenemos que especificar es la velocidad, en bytes por segundo, y el número de bytes a partir de los cuales tiene que retardar la descarga.

Ejemplo: Supongamos que queremos que la velocidad de descarga de los ficheros .wmv que ocupen más de 1Mb sea de 8k/s.

delay_pools 1

delay_class 1 1

delay_parameters 1 8192/1048576

acl ficheros_wmv url_regex \.wmv$

delay_access 1 allow ficheros_wmv

Cuando en esa red, algún equipo haya bajado más de 1Mb correspondiente a ficheros .wmv entonces la descarga total de ficheros .wmv se hará a una velocidad de 8k/s. Si quisiéramos establecer este límite para los hosts de una red deberíamos elegir la clase 2.

En el anterior ejemplo hemos supuesto que hay un único canal de regulación en el parámetro delay_pools. Ahora vamos a ver un ejemplo con dos canales de clase 1. Queremos que el tráfico de la red local no tenga límite de transferencia, mientras que para las conexiones a internet vamos a utilizar un total de 256Kbits/s.

delay_pools 2

delay_class 1 1

delay_parameters 1 -1/-1

acl red_local src 192.168.0.0/24

delay_access 1 allow red_local

delay_class 2 1

delay_parameters 2 32768/1024

acl resto all src 0.0.0.0/0.0.0.0

delay_access 2 allow resto

La tasa de transferencia viene especificada en bytes por segundo, por ejemplo convirtiendo a otras unidades uno de los parámetros de delay_parameters:

32768 B/s = 32 KB/s = 32 x 8 Kb/s (bits) = 256 Kb/s = 256 Kbits/s

El valor 1024 es un número de bytes lo suficientemente pequeño para que se alcance pronto y se estabilice el ancho de banda.

El valor -1 indica ilimitado.

Las regulaciones de clase 1 están diseñadas para evitar que la acl correspondiente consuma todo el ancho de banda, es decir definen la suma máxima de los anchos de banda de todos los clientes, pero no evita que un cliente pueda consumir ese ancho de banda a costa de otro; todos os clientes comparten un máximo ancho de banda.

Clase 2

La clase dos que consiste en un canal común con 256 canales individuales. Es decir tenemos un canal global y dentro de él otros 256 canales que se aplican a las máquinas de una red de clase C.

Ahora vamos a ver otro ejemplo con dos canales, en este caso ambos de de clase 2. Ahora también que el tráfico de la red local no tenga límite de transferencia, ni global ni por IP, mientras que para las conexiones a internet vamos a utilizar un total de 256Kbits/s y a cada máquina de la red le asigna un máximo de 64kbits/s.

delay_pools 2

delay_class 1 2

delay_parameters 1 -1/-1 -1/-1

acl red_local src 192.168.0.0/24

delay_access 1 allow red_local

delay_class 2 2

delay_parameters 2 32768/1024 8192/1024

acl resto all src 0.0.0.0/0.0.0.0

delay_access 2 allow resto

Este ejemplo es muy parecido al anterior de clase 1, sólo tenemos que agregarle una pareja de valores al parámetro "delay_parameters". La primera pareja de este parámetro especifica el ancho de banda global, mientras que la segunda pareja especifica el ancho de banda por host.

Hay que tener en cuenta que los clientes están limitados por el tamaño del canal más pequeño, por lo que no tiene sentido que el canal común tenga un tamaño menor que los canales individuales.

Clase 3

La clase tres que define un canal común que contiene 256 canales de red, 65536 canales individuales. Muy parecida a la clase dos pero par redes de clase B.

Hay que tener en cuenta que los clientes están limitados por el tamaño del canal más pequeño, por lo que no tiene sentido que el canal común tenga un tamaño menor que los canales individuales.

Ejemplos de control de ancho de banda

Limitación global del ancho de banda

Tenemos una conexión con internet de 4Mbits y queremos que el ancho de banda dedicado a consulta de páginas web desede las IP comprendidas entre 192.168.5.100 hasta 192.168.5.199 sea de 1Mbits máximo.

1Mb/s = 128kB/s = 131072 B/s

4Mb/s = 512kB/s = 524288 B/s

delay_pools 1

delay_class 1 1

delay_parameters 1 131072/8192

acl lista src 192.168.5.100-192.168.5.199/32

delay_access 1 allow lista

Limitación de ancho de banda por red y host

Tenemos una conexión con internet de 4Mbits y queremos que el ancho de banda dedicado a consulta de páginas web desede las IP comprendidas entre 192.168.5.100 hasta 192.168.5.199 sea de 1Mbits máximo, de forma que cada una de las máquinas no pueda consumir más de 512Kbits/s.

Es como el ejemplo anterior, pero añadiendo restricciones adicionales a cada una de las máquinas, por lo que tendremos que elegir la clase 2:

delay_pools 1

delay_class 1 2

delay_parameters 1 131072/8192 65536/8192

acl lista src 192.168.5.100-192.168.5.199/32

delay_access 1 allow lista

Limitación de ancho de banda por servidor

Queremos limitar el ancho de banda a 4KB/s y que cada máquina consuma a lo sumo 2KB/s para todas las conexiones que se hagan a los servidores de banner cuyo nombre empieza por ad.

delay_pools 1

delay_class 1 2

delay_parameters 1 4096/4096 2048/2048

acl publicidad url_regex http://ad.*

delay_access 1 allow publicidad

Ancho de banda ilimitado para la red local

Garantizar un ancho de banda ilimitado para los accesos a la red local

delay_pools 1

delay_class 1 2

delay_parameters 1 -1/-1 -1/-1

acl redlocal url_regex -i 192.168

delay_access 1 allow redlocal

Establecer privilegios de acceso

Establecer privilegios en la red

delay_pools 3

delay_class 1 1

delay_class 2 1

delay_class 3 1

delay_parameters 1 -1/-1

delay_parameters 2 131072/8192

delay_parameters 3 65536/8192

acl jefes src 192.168.5.1-192.168.5.50/32

acl subjefes src 192.168.5.51-192.168.5.99/32

acl resto src 0/0

delay_access 1 allow jefes

delay_access 2 allow subjefes

delay_access 3 allow resto

Ancho de banda en horarios distintos

Limitar el ancho de banda en una franja de horario

acl todos src 0/0

acl laboral time 08:30-16:30

delay_pools 2

delay_class 1 2

delay_parameters 1 -1/-1 -1/-1

delay_access 1 allow todos

delay_class 2 2

delay_parameters 2 131072/8192 65536/8192

delay_access 2 allow laboral

delay_access 2 deny !laboral

delay_access 2 allow todos

Configuración de los navagadores clientes

Esta configuración exige que cada navegador esté configurado para utilizar el proxy. Pero claro, por una lado es un engorro tener que configurar uno a uno todos los equipos de la red y por otro, tenemos la posibilidad de que la configuración TCP/IP le da salida a través de una pasarela.

Si a pesar de todo queremos esta configuración, tendremos que decirle al navegador que utilice como proxy el equipo que alberga Squid y el puerto el 3128. El puerto se puede cambiar en el fichero de configuración. Otro puerto que se suele usar para proxy es el 8080, pero ¿para qué cambiarlo?

Proxy Transparente

Como queremos evitar tener que configurar los navegadores cliente y queremos evitar posibles puertas traseras de salida vamos a configurar un proxy transparente.

¿Qué es un proxy transparente? Es un proxy que no necesita ninguna configuración especial en los clientes. Se denomina transparente porque el cliente en realidad no sabe que lo está usando, es transparente para él.

Cómo configurar el proxy transparente, pues en primer lugar tenemos que configurar el cortafuegos para que reenvíe todas las peticiones que se hagan a un puerto 80 hacia el puerto 3128 que utiliza Squid. Es decir, capturamos todas las peticiones que se hagan a un servidor http y se las enviamos a Squid para que él se encarge del resto.

Estas son las reglas de iptables. La primera para redrigir las peticiones al proxy la siguiente para rechazar el resto de los reenvíos.

Si queremos que las páginas web pasen por el proxy con squid que está en 192.168.5.254, pero el resto siga con acceso normal, pondríamos:

iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.5.254:3128

Si el equipo con squid está en la misma pasarela entonces podemos poner:

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

Cuidado, de las opciones anteriores sólo debemos escoger una de ellas.

Si sólo queremos salida para visitar págias web, entonces pondremos:

Primero garantizamos el tráfico DNS:

iptables -A FORWARD -p tcp -m tcp --dport 53 -j ACCEPT

optables -A FORWARD -p udp -m udp --dport 53 -j ACCEPT

iptables -A FORWARD -p tcp -m tcp --sport 53 -j ACCEPT

iptables -A FORWARD -p udp -m udp --sport 53 -j ACCEPT

En el siguiente caso suponemos que el equipo con squid está en 192.168.5.254:

iptables -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.5.254:3128

iptables -t nat -A FORWARD -j REJECT --reject-with icmp-port-unreachable

Si el equipo con squid está en la misma pasarela entonces podemos poner:

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

iptables -A FORWARD -j REJECT --reject-with icmp-port-unreachable