Introduccion
Para que sirve?
Aclarando conceptos
Trafic Control Super Script (TCSS)
Finalizando la configuración
Sitios web útiles
Para cerrar
INTRODUCCIÓN
En este articulo les voy a explicar los conceptos de administración del ancho de banda con las herramientas GNU/GPL que trabajan en conjunto con el kernel Linux. En este caso hablaremos de netfilter e iptables, iproute2, y una de sus utilidades: tc y de Traffic Control Super Script, una linda aplicación que permite especificar reglas de limitación de ancho de banda en base a IP y puerto de origen y/o destino mediante unos simplificadamente complejos archivos de configuración. También hablaremos a nivel conceptual de CBQ (Class-Based Queuing; su traducción puede sonar vulgar, pero es "Encolamiento basado en clases"), aunque el día de hoy ya contamos con otras disciplinas como HTB.
PARA QUE SIRVE?
En principio, CBQ presenta la capacidad de dar el ancho de banda requerido por cada clase en un intervalo de tiempo especificado, si hubiera demanda del mismo. Esto se logra mediante un mecanismo similar al utilizado por los delay_pools de Squid para limitación de ancho de banda de Proxy HTTP, aplicando "esperas" entre las transferencias de paquetes.
En segunda instancia CBQ permite que las clases "tomen prestado" ancho de banda no utilizado por otras clases.
ACLARANDO CONCEPTOS
El ancho de banda en si mismo es una función del tamaño y el tiempo. Por ejemplo, la velocidad la medimos en metros por segundo. En el mundo de las comunicaciones medimos bits, bytes o algún múltiplo por segundo. De esta forma tenemos que en un vinculo de 512Kb por segundo logramos una velocidad o tasa de transferencia de 64Kb por segundo, ya que 8 bits = 1 byte, y, por lo tanto, 512/8 = 64. (Olvidemos por un momento que en ADSL o cablemodem tenemos diferentes anchos de banda dependiendo de si estamos enviando o recibiendo datos). De aquí que las limitaciones de ancho de banda se realicen intercalando esperas en la trasmisión / recepción de datos, como en los delay_pools que comentábamos.
Si suponemos un escenario típico, tendremos direcciones IP (computadoras o dispositivos) que intentan acceder a recursos IP de otras redes, pasando a través de un gateway. Esto se puede aplicar a una configuración NAT clásica, direcciones IP privadas, accediendo a internet a través de un gateway GNU/Linux con dos o mas interfases de red.
Como sea, logramos que todas las solicitudes hacia internet pasen a través de nuestro gateway, por lo que podremos controlar no solo que protocolos o combinaciones de puertos o IP de origen o destino permitir, sino también el ancho de banda permitido.
En principio, quise hablar del Script CBQ.init, que permite armar fácilmente reglas de CBQ mediante el comando tc del paquete iproute2, pero le quise dar la oportunidad a otra aplicación llamada Traffic Control Super Script (TCSS). De todas formas, me gustaría comentar que CBQ.init resulta útil cuando deseamos aprender a crear nuestros propios comando tc, ya que mediante su función compile podemos obtener la traducción de los archivos de configuración CBQ.init que hagamos a comandos tc.
Así mismo, existen otras aplicaciones para este mismo propósito, como Snitch y HTB.init. Pasemos, finalmente, a revisar TCSS.
TRAFFIC CONTROL SUPER SCRIPT
Ante todo, al TCSS no lo he visto ni en Slackware, Gentoo, SuSe, Mandrake, ni en ninguna otra; van a tener que descargarlo del sitio oficial. Esto es importante: el autor recomienda que el firewalling y el control de ancho de banda lo realice un servidor GNU/Linux realizando bridging. El TCSS (y demás derivados de iproute2/tc) se puede aplicar aunque no trabajemos de dicha forma.
Al descargar TCSS, obtendremos un archivo .tar.gz. Vamos a desempaquetarlo donde deseemos. Es preferible utilizar el directorio /etc/rc.d/tcss como contenedor de configuración y aplicación, ya que la misma es muy pequeña.
El primer paso consiste en editar el archivo de configuración, llamado, increíblemente, config. Ese archivo ya existe; nos limitaremos a cambiar algunos parámetros. Recuerden que tanto la aplicación como la configuración reciden en un mismo directorio; en nuestro caso, usaremos /etc/rc.d/tcss. Este archivo aparte de los clásicos comentarios al principio, contiene estas lineas:
path='/etc/rc.d/tcss01f';
hostsfile="$path/tcss-hosts";
devicesfile="$path/tcss-devices";
shape_ports='all';
shape_parent_classid='0';
shape_protocol='tcp';
shape_prio='1';
debug=false;
version="0.1f";
allow_version_check=true;
Archivo /etc/rc.d/tcss
Las lineas que nos interesan cambiar probablemente sean tan solo path para que apunte a /etc/rc.d/tcss y allow_version_check en false. Esta variable le indica a TCSS que automáticamente verifique con su sitio oficial en internet si hay actualizaciones disponibles. Si quieren aprovechar esta funcionalidad, sepan que necesitan tener el paquete wget instalado.
Luego debemos editar el archivos tcss-devices, que indica cual es la interfaz de red conectada a internet y cual es la interfaz de red de nuestros "clientes". Viene uno de ejemplo y es el siguiente:
eth0 8139too dstif 100Mbit 10Mbit 10 cbq 1000 on
eth0 8139too srcif 100Mbit 11Mbit 11 cbq 1000 on
Archivo /etc/rd.d/tcss-devices
En este caso, vemos que hay dos interfases de 100Mb (¡Atención!, hablamos del ancho de banda físico del dispositivo, y no del ancho de banda que posee nuestra conexión a internet), eth0 y eth1, las cuales corresponden a la interfaz que lleva a nuestros clientes (eth0 configurada como dstif, que usa el modulo del kernel 8139too) y la que lleva la conexión a internet (eth1, configurada como srcif, que también usa el modulo del kernel 8139too).
Pero existen mas parámetros en este archivo. Ya vimos las cuatro primeras columnas. La quinta columna, según una regla estándar CBQ, es el valor de la cuarta dividido 10. En este caso, 100Mb / 10 = 10Mb.
Luego, la sexta columna es el numero identificador de la interfaz, único. Es recomendable usar valores menores que 20 en este archivo. En este caso usa 10 y 11. El séptimo campo indica que deseamos usar CBQ. El octavo campo indica "siempre 1000". Un valor entre 1000 y 1500 es normal. La ultima columna simplemente "activa", o no, la interfaz para ser usada en TCSS.
FINALIZANDO LA CONFIGURACIÓN
El ultimo archivo a configurar es tcss-host. Este archivo indica por cada linea una regla de control de trafico diferente. Cada regla consta de 13 parámetros, y cada valor/columna debe estar separado por otro exactamente por una tabulación (tecla
1. Nombre de la regla
2. Dirección IP a limitar ("cliente")
3. IP o red contra la cual realizar el control de trafico (relativo a la IP "Cliente")
4. Identificador de la regla (numero siempre par empezando por 22, 24, 26, etc)
5. Sentido del trafico a controlar
6. Puerto destino
7. Puerto origen
8. Protocolo
9. Velocidad
10. Velocidad dividido 10
11. Regla activada o no
12. Regla bidireccional o no
13. Usar u32 o iptables para la clasificación
El parámetro 1 es tan solo un nombre descriptivo de la regla.
El parámetro 2 indica a que dirección IP o red limitaremos para la regla en cuestión
El parámetro 3 indica si esta regla solo se aplica cuando el destino es una cierta IP o red. En combinación con los campos 6 y 7 podemos armar reglas que tengan en cuenta diferentes combinaciones de IP de origen/destino y puerto origen/destino según el protocolo (campo 8 tcp/udp), El cuarto campo es un valor que, como recordaran debe ser mayor o igual a 22, en incrementos de 2 en 2, ya que el identificador de dispositivos es menor a 20. El quinto campo indica si es una regla de bajada (dstif) o subida (srcif). Este campo toma especial significado si al parámetro 12 no lo configuramos como bidireccional (bi o notbi, según consideremos). El campo 9 y, por consiguiente el campo 10, es el eje de este articulo: el ancho de banda que deseamos al cliente "consumir". El campo 10 es aproximadamente un 10% del campo 9. El campo 12 permite definir si el control de trafico también se realizara en el sentido de "retorno", relativo a la regla en cuestión (si es dstif o scrif). Podemos limitar la velocidad con la que el usuario baja archivos del puerto 80 de cualquier red destino (0/0), pero quizá no deseemos limitar con que velocidad puede realizar solicitudes http. Si deseamos aplicar la regla en ambos sentidos, especificaremos bi. En caso contrario notbi. La ultima columna toma sentido si nuestros clientes se encuentran NATeados, o sea, si no tienen IP publica. En este caso, no se puede utilizar un clasificador u32 (notables), sino que debe usar iptables, especificando el parámetro tables.
El archivo de configuración de ejemplo es el siguiente:
kegan-ssh 10.10.11.2 0/0 22 dstif any 22 tcp 128kbit 12kbit on bi notables
kegan-http 10.10.22.2 0/0 24 dstif 80 any tcp 64kb 6kbit on bi notables
kegan-all 10.10.11.2 0/0 26 dstif any any all 33kbit 3kbit on bi notables
Archivo /etc/rd.d/tcss-host
SITIOS WEB UTILES:
* TCCS: www.psimax.com.za - Seccion "TCSS"
* CBQ.init: www.sourceforge.net/projects/cbqinit
* HTB.init: www.sourceforge.net/projects/htbini
* Snitch: http://snitch.sourceforge.net
PARA CERRAR
Investiguen Snith con 17-filter, que permite armar reglas de control de tráfico sobre la base del protocolo de capa 7 (HTTP, FTP, por ejemplo, sin hablar del puerto 80, 20, o 21). Que les sea útil.
Articulo copiado textualmente de la revista: Linux User
Autor: Arturo "Buanzo" Busleiman
Web: www.buanzo.com.ar
Saludos
Fernando Ferrari
fernandorferrari@yahoo.com.ar
No hay comentarios.:
Publicar un comentario