Funciona mediante reglas o criterios para seleccionar paquetes, las cuales forman grupos, que se revisan secuencialmente verificando si el paquete concuerda con los criterios de selección.

Los criterios de selección de paquetes pueden ser entre otros:

• Protocolos (TCP, UDP, ICMP)
• Direcciones de origen
• Direcciones de destino
• Puertos (UDP, TCP)
• Interfaz
• Banderas de TCP (SYN, ACK)
• Tipo del paquete (ICMP)

1. Acciones

Una ves seleccionado el paquete, se toma una acción con el mismo, las cuales pueden ser:

• Permitir el paso del paquete.
• Tirar el paquete.
• Incrementar contadores.
• Guardar en bitácora.
• Rechazar el paquete con algún error.
• Procesar con otro grupo de reglas.

1. Modos de implementación

• IPFilter
• NetFilter
• Hardware

1. IPFilter

• Propio de la familia BSD
• Escrito por Darren Reed
• Incluido en NetBSD, FreeBSD
• Licencia tipo BSD

1. NetFilter

• Solución de los sistemas Linux.
• Primera y segunda generación
• Basado en ipfw (sistemas BSD)
• Escrito por Alan Cox
• Mejorado por Jos Vos
• Desde los kernels 1.1
• Herramienta ipfwadn
• Tercera generación
• Código del kernel reescrito por Rusty Russell y Michael Neuling
• Para los kernels de las series 2.2
• Herramienta ipchains
• Cuarta Generación
• Código del kernel reescrito por (el hamster de) Rusty Russell
• Para los kernels de las series 2.4
• Herramienta iptables
• Extensible
• Licencia GNU GLP

1. Hardware

Incrustado en la circuitería de algunos de los sig. dispositivos.

• Routers de banda ancha
• Cable routers

1. Semejanzas entre IPFilter y NetFilter

• Realizan un filtrado a nivel del kernel
• Paquetes IP en sus distintos protocolos asociados TCP, UDP, ICMP
• Herramientas de administración :
• ipf, ipfstat, ipnat para IPFilter.
• iptables para NetFilter
• Inspección Stateless y Stafeful
• Conteo de paquetes
• Política por omisión.
• Ambos paquetes tienen mecanismos para alterar sus acciones (quick, RETURN).

1. Diferencias entre IPFilter y NetFilter

Filosofías opuestas.

IPFilter:

• Se ejecuta la acción de la última regla que coincide.
• Se dictan las políticas generales y luego excepciones.

NetFilter:

• Se ejecuta la acción de la primera regla que coincide.
• Se identifica el caso del que se trata y se ejecuta una acción.

1. PROCESO DE FILTRADO

0. IPFilter

0. Filtrado

• Los criterios pueden ser una combinación de características :

• pass in on x10 proto tcp from 192.168.2.46/32 to any port = 80 flags S/SA

• Las acciones son pass y block. El comportamiento de estas puede ser modificado por log, quick o los grupos.
• Dos juegos de reglas activos, entrada (in) y salida (out).

• block in all
• pass out all

• Cada juego tiene un grupo base (1).

• Se pueden formar nuevos grupos y toda regla puede ser miembro o cabeza de un grupo.
• pass in from any to 192.168.2.46/32 port = 80 head 333
• block in from 192.168.27.0/24 to any group 333 head 334
• pass in from 192.168.27.4/32 to any group 334

• Se alimentan estas reglas al programa de interacción

• ipf –f ipf.rules

1. NAT

• Se especifica en la interfaz por la que salen
• tipos:

• Redirectdirección y puerto a dirección y puerto
• Mapred a red (no regulada)
• Bimapmapeo bidireccional
• Map-blockmapeo estático de direcciones a bloques de dirección y un rango de puertos.

• El caso mas ordinario:

• map 192.268.27.0/24 to 132.248.28.164 portmap auto

• Se alimentan las reglas al programa ipnat

• ipnat –f ipnat.rules

1. NetFilter

• Las reglas tienen una parte de comparación (match), y una acción. Las acciones pueden ser:

• ACCEPT
• DROP
• alguna acción definida por una extensión
• una cadena

• Las cadenas son conjuntos de reglas, tienen una política (acción por omisión)
• Una tabla contiene a estas cadenas.
• Se pueden crear cadenas nuevas

• Iptables –N mychain

• Se tienen 3 tablas:

• filter

• INPUT
• OUTPUT
• FORWARD

• nat

• PREROUTING
• POSTROUTING
• OUTPUT

• mangle

• OUTPUT
• PREROUTING

• Ejemplos de reglas

• iptables –A OUTPUT –j REJECT –p tcp –destination-port 113 –reject-with tcp-reset
• iptables –t filter –A INPUT –j ACCEPT –p tcp –d 192.168.27.5/32 –s 192.168.27.0/24 –i eth0 –destination-port 80 –m –state NEW

1. iptables

Existen 3 cadenas predefinidas incrustadas en netfilter:

1. INPUT Trabaja con paquetes con destino en el servidor local.
2. FORWARD Trabaja con paquetes que van de una interfaz o otra.
3. OUTPUT Trabaja con paquetes con origen en el servidor local.

Los paquetes van a la cadena INPUT ó FORWARD, pero no a ambas.

Si se añade NAT, se utilizarán 2 cadenas adicionales:

4. POSTROUTING
5. PREROUTING

Cuando un paquete llega a una interfaz, primero llega a la cadena PREROUTING –si existe-. Aquí las direcciones de destino se cambian a (DNAT) para indicar otro servidor diferente. Si por ejemplo, el tráfico al puerto 80 del servidor local se va a mandar a un servidor interno, el destino se cambia aquí. El paquete llega entonces a la interfaz y el kernel hace la búsqueda en la tabla de encaminamiento para ver a dónde tiene que ir el paquete (al servidor local o a otra interfaz).

Entonces el netfilter toma el paquete basándose en el destino (servidor local o interfaz de salida) y ejecuta la cadena INPUT o la FORWARD. Si el paquete pasa por la cadena FORWARD y no se rechaza, se le vuelve a pasar por la tabla de encaminamiento del kernel y se le envía a la interfaz apropiada.

Mientras el paquete sale de la interfaz, netfilter hace pasar al paquete otra vez por las reglas de POSTROUTING.

PREROUTING -> FORWARD->POSTROUTING

PREROUTING->INPUT->proceso local->OUTPUT->POSTROUTING

1. Cadenas

Una cadena es una lista de reglas agrupadas lógicamente. Cada regla de la cadena de aplica contra la cabecera de una IP para buscar una correspondencia.

Las cadenas contienen reglas que están numeradas a partir de uno. Y se hace referencia a ellas por su especificación o por su número.

Una especificación de regla es el conjunto de condiciones que tiene que tener un paquete. La misma regla básica puede existir en múltiples cadenas, pero si la cadena objetivo es ACCEPT, DROP, REJECT, o MASQUERADE, este objetivo termina la cadena para que no se procesen más reglas en esta cadena.

La sintaxis básica de las reglas de iptables es :

En la especificación de la tabla –t , podemos utilizar la tabla

• filter Filtro. Es la cadena predeterminada.
• mangle Alteración
• nat Traducción de direcciones de red

La tabla mangle se utiliza cuando se quiere modificar los bits de TOS, o poner una marca en el paquete, para que netfilter pueda hacer gestión de colas o para otros propósitos.

La tabla nat se usa para SNAT, DNAT, y MASQUERADE e implementa las cadenas PREROUTING y POSTROUTING

• Para máscaras de dirección, éstas pueden ser de los sig. tipos: /N o /N.N.N.N
• Las direcciones también pueden ser nombres de servidores.
• Los puertos pueden ser números o nombres de servicios.
• ! Se puede utilizar con varias opciones para invertir el significado:
• -p[!] protocolo. Protocolo puede aceptar ! (como por ejemplo –p ! icmp para hacer que se corresponda todos los mensajes excepto los icmp; o puede aceptar all para hacer que se corresponda todos los protocolos.
• -s[!] dirección. Dirección de origen. Puede aceptar opcionalmente!, una máscara de red o un puerto. Note que la dirección 0/0 se corresponderá con todas las direcciones y será lo predeterminado sin no se especifica –s.
• -d[!] dirección. Dirección destino. igual que –s
• -i[!] nombre. Nombre de la interfaz de entrada. Puede aceptar ! También acepta el sufijo – en el nombre de interfaz indicando todas las interfaces de ese tipo; esto es, ppp+ son todas las interfaces PPP (ppp0-pppN). Esta opción se puede referir sólo a la interfaz de entrada, así que no se puede utilizar en la cadena OUTPUT ni en la POSTROUTING (o cadenas llamadas desde esas cadenas).
• -o[!] nombre. Nombre de interfaz de salida. Parecido a –i, pero se aplica sólo a la interfaz de salida y sus correspondientes cadenas.
• -j objetivo. Objetivo de la regla (nombre de cadena definido por el usuario o valor especial), si lo hay. Valores especiales, ACCEPT, DROP, QUEUE o RETURN, terminan la cadena.
• -n. Salida numérica de direcciones y puertos. iptables intenta resolverlos de manera predeterminada.
• -v. Modo verboso. Muestra las direcciones de interfaz, opciones de reglas (si las hay), máscaras TOS y los contadores de paquetes y bytes. Utilice –vv si quiere obtener informes extremadamente verbosos.
• -x. Número de expansión. Cuando se muestran los contadores de paquetes y de bytes, no utiliza las abreviaturas K, M ni G, sino que muestra todos los ceros.
• [!] -f. Fragmentos segundo y siguientes. Puede ir precedido de !.
• --line-numbers. Usado con reglas de enumeración para mostrar los números de línea delante de las especificaciones de regla como referencia.
• --sport [!] puerto[:puerto]. Válido sólo siguiendo a la opción –p tcp o a la –p udp. Especifica un puerto origen o un rango de ellos (los rangos se especifican utilizando – o : para separar el principio y el final del rango). También se puede utilizar con la opción de correspondencia multiport (multi-puerto, con la que se pueden enumerar hasta 15 puertos). Los fragmentos de la regla pueden tener el siguiente aspecto:

• --dport[!] puerto[:puerto]. Válido sólo siguiendo a la opción –p tcp o a la –p udp. parecido al -sport, previo, pero especifica el puerto(s) destino.
• --tcp-flags [!] indicadores indicadores-activos. Válido sólo siguiendo a la opción –p tcp. Esta opción consulta a los indicadores enumerados en indicadores y establece entonces una correspondencia si los indicadores del conjunto indicadores-activos son los únicos indicadores activados. Los indicadores posibles son :SYN, ACK, FIN, RST, URG, PSH, y ALL NONE. Si quiere examinar los indicadores SYN, ACK, RST y FIN, pero aceptar sólo aquellos con los indicadores SYN y ACK establecidos (respuesta a una conexión nueva) el fragmento de regla tendría este aspecto:

• [!] - - syn. Válido sólo siguiendo a la opción –p tcp. esto equivale a lo siguiente: - - tcp-flags SYN, RST, ACK SYN
• --icmp-type [!] ICMP [sub]tipo. Válido sólo siguiendo a la opción –p icmp. Los siguientes son tipos y subtipos ICMP válidos. (indentados bajo el tipo principal):

• --mac-source [!] dirección-mac. Sólo válido si sigue a la opción –m mac. Útil con las cadenas INPUT o PREROUTING. Un fragmento de la regla tendría el siguiente aspecto : -m mac - - mac-source 00:00:ab:c0:45:a8
• --limit tasa. Tasa máxima de correspondencias (medio). El valor predeterminado es 3/hora; todo lo que sobrepase ese límite se rechaza. Si su sistema no puede tolerar más de una nueva conexión por segundo, puede usar el límite con este fragmento de regla: -p tcp - - syn Para evitar que su servidor se sobrecargue, aunque esto normalmente se utiliza con el objetivo LOG para evitar que los registros crezcan demasiado rápidamente. La tasa puede especificar el periodo (el predeterminado es /hour, hora) como /minute (minutos), /second (segundos), /hour (horas) o /day (días). Fragmento de regla: -m limit - -limit 1/sec
• --limit-burst número. Número máximo inicial de correspondencias antes de empezar a utilizar el –limit rate precedente. El valor de la ráfaga (burst) se vuelve a poner a uno cada vez que el - - limit rate anterior se ha alcanzado. El valor de - - limit-burst predeterminado es 5.
• --port [puerto[,puerto]]. Solamente válido con la opción –p tcp o la –p udp y después de la opción –m multiport. Se establece una correspondencia si los puertos origen y destino son el mismo, y se establece una correspondencia con cualquier otro puerto opcional enumerado (se permiten hasta 15 puertos separados por comas). Esto es un ejemplo de fragmento de regla multiport que establece un correspondencia sólo entre los puertos 25 y 110: -m multiport –p tcp - - port 25, 110
• --mark valor[/máscara]. Hace que se correspondan paquetes con una marca dada (un valor sin signo). Este valor debe ser establecido utilizando el objetivo MARK.
• - uid-owner id-de-usuario. Válido sólo cuando se utiliza en la cadena OUTPUT para identificar paquetes creados por un usuario concreto, e incluso entonces funciona sólo con algunos paquetes creados localmente.
• --gid-owner id-de-grupo. Similar a –uid-owner, pero se aplica al grupo.
• --pid-owner id-de-proceso. Similar a –uid-owner, pero se aplica al identificador de proceso (PID).
• --sid-owner id-de-sesión. Similar a –uid-owner, pero se aplica a la sesión.
• --state estado. Establece correspondencias entre estados de conexiones TCP. El parámetro estado es una lista separada por comas de valores que constan de uno o más de los siguientes valores: NEW, ESTABLISHED, RELATED, INVALID, El NEW se refiere a conexiones nuevas (parecido a –syn, pero incluye toda la información de la conexión nueva). El ESTABLISHED se refiere a una conexión actualmente existente y válida. El RELATED se refiere a paquetes que inician una conexión debido a una conexión ESTABLISHED (como la conexión de canal de datos FTP o los mensajes de error ICMP, que no tienen estado de puerto ni de conexión). Utilizará normalmente ESTABLISHED y RELATED juntos. El estado INVALID se refiere a paquetes no cubiertos por los casos anteriores –como las exploraciones que utilizan pings TCP, paquetes con los bits SYN y ACK puestos a 1 que no tienen un paquete SYN correspondiente, o exploraciones de árbol XMAS, con todos los bits puestos a 1 (SYN, ACK, FIN, URG, PSH, RST). Un fragmento de regla puede que tenga este aspecto: -m state –state ESTABLISHED, RELATED
• unclean. Una opción experimental diseñada para establecer correspondencia con paquetes raros o mal formados: -m unclean
• --tos tos. Utilizado para emparejar una de las siguientes máscaras TOS. El valor TOS debe establecerse primero con netfilter utilizando el objetivo TOS que se ha visto anteriormente. Algunos fragmentos de la regla pueden tener este aspecto : -m tos --tos 16

Además de los objetivos incorporados ACCEPT, DROP, QUEUE, RETURN, existen otros si cargado los módulos. Los objetivos que se incluyen actualmente :

• - -log-level nivel. Permite especificar el nivel de registro.
• - - log-prefix prefijo. Le permite añadir hasta 14 caracteres como la primera parte del registro para identificar la entrada de registro.
• - -log-tcp-sequence. Registrará los números de secuencia de TCP (un posible riesgo de seguridad).
• - -log-tcp-options. Lee y registra el campo de options de la cabecera del paquete TCP.
• - -log-ip-options. Lee y registra el campo de options de la cabecera del paquete IP.

1. Cadenas definidas por el usuario

Las cadenas definidas por el usuario proporcionan una manera de agrupar reglas de forma lógica. Se llama a estas cadenas desde cadenas predefinidas como objetivos. En cualquier punto de la cadena puede llamar a una cadena definida por el usuario desde la misma tabla. Cuando una cadena definida por el usuario termina sin establecer ninguna correspondencia, vuelve al siguiente parámetro de la cadena de llamada.

Cuando se crean las cadenas definidas por el usuario, los nombres deben ir en minúsculas, dado que las mayúsculas se reservan para las cadenas predefinidas y para los objetivos. El nombre no puede ser ninguno de los nombres de las cadenas predefinidas ni de los valores especiales.

1. Control de tráfico

A partir del kernel 2.2.X, Linux posee un subsistema de red rediseñado, gracias al cual las facilidades como el routing, cortafuegos y código de clasificación de tráfico, se realizan ahora mediante la herramienta IPROUTE2. Además de que hace el trabajo que se hacía con ifconfig y route.

IPROUTE2 proporciona 2 herramientas:

• ip
• tc (traffic control)

En el nuevo diseño del subsistema de networking para Linux es posible definir varias tablas de enrutado, de forma que se puede decidir qué tabla es utilizada por un determinado tráfico IP. Esto es, podemos clasificar nuestro tráfico IP y aplicar un conjunto distinto de reglas de enrutado para cada tipo de tráfico.

Por defecto hay tres tablas:

• local
• main
• default

cada una con una prioridad distinta, y que se aplican a todos los tráficos. Para comprobar el número de tablas definidas en nuestro equipo, y como se clasifican los paquetes para ir a cada una de ellas, se ejecuta el siguiente comando de iproute2:

La tabla local es la primera en ser aplicada y es la que tiene la prioridad menor.

Por ejemplo supongamos que tenemos un router Linux con dos enlaces a Internet, uno de ellos con mayor ancho de banda que el otro. Supongamos además que damos acceso a Internet a una red clientes, de forma que proporcionamos dos tipos de servicio. El primero de ellos es un acceso sólo para consultar el hotmail y el segundo es un servicio de acceso normal. Lógicamente el primer servicio es más barato que el segundo, por lo que utilizará el acceso de menor ancho de banda.

La dirección del acceso con mayor ancho de banda es 212.64.94.251 y es un enlace PPP a la dirección 212.64.94.1 el acceso de menor ancho de banda tiene dirección 212.64.78.148 y es un enlace a la dirección 195.96.98.253. Además nuestros clientes con acceso a hotmail tendrán una dirección de red 192.168.10.0/24, mientras que nuestros clientes con acceso normal tendrán una dirección de la red 192.168.10.128/24.

Para implementar lo anterior, creamos la tabla y generamos la nueva regla a la que llamamos ‘hotmail’:

Si listamos nuestras tablas:

# ip rule ls

0: from all lookup local

32765: from 192.168.10.0/24 lookup hotmail

32766: from all lookup main

32767: from all lookup default

Ahora añadimos la ruta a la tabla ‘hotmail’ y reiniciamos el caché de rutas:

Los usuarios de la red 192.168.10.128/24 accederán a través del otro acceso a Internet, el cuál estará configurado como gateway en las tablas por defecto.

Para el control de tráfico, se usan los filtros y las colas. Los filtros colocan los paquetes en las colas y estas deciden qué paquetes mandar antes que otros.

Filtros

• fwmarkMediante netfilter
• u32Mediante las cabeceras de los paquetes

Colas sin Clases

• PFIFO_FAST
• TOKEN BUCKET FILTER
• STOCHASTIC FAIRNESS QUEUEING

Colas con clases

• PRIO
• CBQClass-Based Queueing
• HTBHierarchical Token Bucket

Paquetes a enviar  [ reordena | retraza | descarta ]  Paquetes enviados

Existen tres procesos de este tipo para encolar paquetes:

• PFIFO_FAST
• TOKEN BUCKET FILTER
• STOCHASTIC FAIRNESS QUEUEING

Este tipo de disciplina es el que se utiliza en el caso de que nuestra única necesidad sea limitar el ancho de banda de un determinado interfaz.

El modelo de funcionamiento consiste en suponer que tenemos un buffer (bucket) al cual llegan los denominados ‘tokens’ a un ritmo constante. Estos tokens además serán los que utilizarán los paquetes IP para salir del interfaz de red. Es como si cada paquete IP tuviese que esperar a una carretilla (token) que será la encargada de sacarlo del interfaz. Así pues, en función de cómo sean los ritmos de llegada de tokens y paquetes IP las situaciones que pueden plantearse son tres:

1. Los paquetes IP llegan al mismo tiempo que los tokens. Es este caso, cada paquete IP es asignado automáticamente a una de las carretillas que lo sacará del interfaz.
2. Los paquetes IP llegan a un ritmo mayor que el de los tokens. En este caso, los paquetes IP tendrán que esperar durante un tiempo a que haya disponible una carretilla que les pueda sacar. Se esta situación se prolonga, parte de los paquetes IP que esperan empezarán a ser descartados con lo cual limitamos el ancho de banda.
3. Los paquetes IP llegan a un ritmo menor que el de los tokens. En este caso, cada paquete IP será asignado automáticamente a una carretilla que lo sacará del interfaz. Además los tokens que no han sido utilizados para sacar ningún paquete IP, serán almacenados en el buffer (bucket) hasta alcanzar el límite del mismo. De esta forma, si cambiara la tendencia y empezaran a llegar paquetes IP a un mayor ritmo, se podrían utilizar estos tokens almacenados para sacar, de manera instantánea, parte de esos paquetes IP que llegan.

En realidad los tokens tienen correspondencia con bytes y no con paquetes IP, pero el resto del modelo es bastante aproximado.

Por ejemplo, supongamos que tenemos una interfaz de red (eth0) del que queremos limitar el acho de banda de salida para que no sature a otro equipo que utilizamos como gateway de salida a Internet. Supongamos que queremos limitar el ancho de banda a 220 Kbits/seg. :

• tc qdisc add dev eth0. Se va a añadir una disciplina de colas en el interfaz eth0.
• tbf. La disciplina es del tipo Token Bucket Filter.
• rate 220kbit. El ritmo al que llegarán los tokens a la disciplina de colas será de 220 Kbits/seg. y por lo tanto éste será el máximo ancho de banda de salida para la interfaz eth0.
• latency 50ms. El tiempo máximo que permanecerá un paquete IP esperando por un token será de 50 milisegundos.
• burst 1540. El tamaño del buffer (bucket) donde se almacenarán los tokens no utilizados será de 1540 bytes. Normalmente mientras mayor es el límite impuesto al ancho de banda, mayor deberá ser el tamaño de este bucket.

1. Stochastic Fairness Queueing

Este tipo de disciplina de colas intenta distribuir el ancho de banda de un determinado interfaz de la forma más justa posible.

Pare ello esta disciplina implementa una política de Round Robin entre todos y cada uno de los flujos de comunicación establecidos en el interfaz, dando a cada uno la oportunidad de enviar sus paquetes por turnos. Un flujo de comunicación será cualquier sesión TCP o flujo UDP, y de esta forma lo que conseguimos es que ninguna comunicación impida al resto poder enviar parte de la información. Lógicamente esta disciplina de colas sólo tendrá sentido en aquellos interfaces que normalmente estén saturados y en los que no queramos que una determinada comunicación eclipse al resto.

1. DISCIPLINAS DE COLAS CON CLASES

Cuando los paquetes IP llegan a una disciplina de este tipo, son enviados a una de las clases que la componen, es decir, necesitan ser clasificados. Para realizar esta clasificación se consultan los filtros asociados a la disciplina de colas, los cuales devuelven un resultado que permite a la disciplina de colas determinar a qué clase debe ser enviado el paquete. Además, cada clase sabemos que tiene asociada una nueva disciplina de colas (con o sin clases), con lo que nuevas consultas a filtros pueden ser realizadas hasta conseguir clasificar el paquete completamente.

En Linux, cada interfaz de red tiene una disciplina de colas de salida (egress) llamada ‘root’, que es la primera de su estructura interna. Por defecto, si no se especifica otra cosa, esta disciplina es del tipo pfifo_fast. Además, a cada disciplina de colas le es asignado un ‘manejador’ que se utilizará en los comandos de configuración de dicha disciplina. Estos manejadores constan de dos partes, un ‘numero mayor’ y un ‘número menor’ separados por ‘:’, así el manejador de la disciplina de colas ‘root’ es ‘1:0’. Normalmente el número menor del manejador de una disciplina de colas es siempre cero, y el número mayor de las clases adjuntas a una disciplina de colas debe coincidir con el número mayor de la misma.

0. Disciplina de colas PRIO

Esta disciplina de colas recuerda a la disciplina sin clases pfifo_fast, aunque es mucho más versátil y ofrece mayores posibilidades.

Por defecto esta disciplina de colas define tres clases, y cada una de ellas tiene asociada una nueva disciplina de colas con política FIFO. Entre las tres clases existe una prioridad de forma que mientras haya un paquete en la clase 1 no se envían paquetes de la clase 2, y lo mismo entre las clases 2 y 3.

En esta clase podemos definir los filtros que consideremos necesarios, de forma que no estamos limitados a hacer una clasificación de los paquetes en función del campo TOS, sino que podemos hacer una clasificación tan compleja como queramos.

Aunque por defecto cada una de las tres clases asociadas a la disciplina PRIO tienen una disciplina con política FIFO, en realidad podemos definir la disciplina de colas que queramos. Por tanto, podría ser por ejemplo una nueva disciplina con clases, filtros asociados, etc.

0. Parámetros de las disciplinas de colas PRIO

En este tipo de disciplinas se pueden configurar dos parámetros:

• bands. Este parámetro permite especificar el número de clases (por defecto 3) que queremos que tenga la disciplina.
• priomap. Podemos decidirnos por no adjuntar ningún filtro que realice la clasificación del tráfico entre las distintas clases que tengamos. En este caso la clasificación se hace siguiendo el mismo criterio (campo TOS) que en el caso de la disciplina pfifo_fast. Así, este parámetro permite determinar el mapeo que queremos establecer entre las prioridades del kernel de Linux, y nuestras clases.

Por ejemplo supongamos un interfaz en el que queremos dar prioridad al tráfico que necesita interactividad, frente al resto del tráfico.

Para ello crearíamos la estructura en la disciplina de colas mostrada en la tabla No. 4:

Para ver la tabla seleccione la opción "Descargar" del menú superior

El tráfico normal es enviado a la clase 30:, el tráfico que necesita interactividad es enviado a las clases 20: o 10:.

Los comandos serían los siguientes:

Esta orden crea de forma instantánea las clases 1:1, 1:2, 1:3

A continuación adjuntamos las disciplinas de colas a cada una de las tres clases

qdisc sfq 30: quantum 1514b

Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

qdisc tbf 20: rate 20 Kbit burst 1599b lat 667.6ms

Sent 0 bytes 0 pkts (dropped 0, everlimits 0)

qdisc sfq 10: quantum 1514b

Sent 132 bytes 2 pkts (dropped 0, overlimits 0)

qdisc prio 1: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Sent 174 bytes 3 kpts (dropped 0, overlimits 0)

Si comprobamos este mapeo de prioridades entre el kernel de Linux y nuestras tres clases, veremos como efectivamente hemos conseguido lo que íbamos persiguiendo. Para ello es necesario recordar que la banda 0 corresponde a la clase 1:1, la banda 1 a la clase 1:2 y la banda 2 a la clase 1:3.

1. Disciplina de colas Class-Based Queueing (CBQ)

Esta disciplina de colas fue la primera que se creó, y probablemente la más utilizada. De hecho, en muchos ámbitos aún se asocia el Control de Tráfico en Linux exclusivamente en referencia a este tipo de disciplina de colas.

CBQ es la más compleja, menos entendida y más empírica de todas las disciplinas de colas. Esto obedece básicamente al hecho de que, además de ser una disciplina de colas con clase, CBQ ofrece la capacidad de regular el ancho de banda (shaping), siendo en este terreno donde surgen sus mayores dificultades.

Supongamos que se intenta reducir el ancho de banda de una conexión de red de 10 Mbit/seg a 1 Mbit/seg. Para lograrlo tendremos que conseguir que el enlace esté inactivo el 90 % del tiempo. Sin embargo, medir con exactitud ese porcentaje entraña mucha dificultad. CBQ utiliza un algoritmo basado en la estimación del intervalo de tiempo trascurrido entre dos peticiones consecutivas del hardware para el envió de datos. Así, se ha comprobado que no siempre se consiguen buenas aproximaciones de este modo, e incluso a veces los resultados son totalmente equívocos.

No obstante, para la mayoría de las situaciones, este algoritmo trabaja de forma adecuada cumpliendo perfectamente con nuestras necesidades.

0. Parámetros CBQ para ajustar la regulación del ancho de banda.

CBQ trabaja intentando que el enlace esté inactivo durante un porcentaje de tiempo que asegure que se regula hasta conseguir el ancho de banda deseado.

También hemos hecho referencia a la complejidad del algoritmo y su falta de exactitud en determinadas situaciones. De hecho, el número de parámetros que se utilizan para esta tarea es elevado y a veces no se sabe cuál es exactamente su función, de ahí que en la mayoría de ocasiones debe ser la propia experiencia la que enseñe como jugar con estos parámetros.

Algunos de los más importantes son:

• avpkt. Tamaño medio del paquete medido en bytes
• bandwidth. Ancho de banda del dispositivo físico. Se necesita para calcular el tiempo muerto entre petición y petición.
• mpu. Tamaño mínimo del paquete. Es necesario porque incluso un paquete de cero bytes de datos da lugar a una trama Ethernet de un tamaño mínimo distinto de cero.
• rate. Ancho de banda regulado con el que queremos que funcione nuestra disciplina de colas.

1. Parámetros CBQ para definir el comportamiento como disciplina de colas con clases.

Al igual que la disciplina PRIO, CBQ permite definir prioridades dentro de las clases que componen su estructura interna. De esta forma, cada vez que el nivel hardware solicita un paquete, CBQ lanza un proceso Round Robin por prioridades. Para la confirmación de este proceso CBQ pone a disposición del usuario los siguientes parámetros:

• prio. Establece las distintas prioridades entre las clases que componen la estructura interna de la disciplina de colas.
• allot y weight. Ambos parámetros permiten configurar el hecho de que aquellas clases con un mayor ancho de banda puedan enviar mayor cantidad de información cada vez que les toque el turno durante el proceso Round Robin por prioridades.

1. Parámetros CBQ para definir la posibilidad de prestar y pedir prestado ancho de banda entre las distintas clases.

Manteniendo siempre la limitación global en el ancho de banda establecido para la disciplina de colas CBQ, existe la posibilidad de que entre las clases se presten ancho de banda en el caso que sea posible. Los parámetros de que se dispone para ellos son:

• isolated / sharing. Una clase configurada con el parámetro isolated no prestará nunca ancho de banda a sus hermanas. El comportamiento contrario viene establecido por el parámetro sharing. Por defecto, si no se indica lo contrario se supondrá que el sharing está activo.
• bounded / borrow. Una clase configurada con el parámetro bounded no intentará pedir prestado ancho de banda a ninguna de sus hermanas. El comportamiento contrario viene establecido por el parámetro borrow. Por defecto, si no se indica nada, se supondrá que el borrow está activo.

Básicamente CBQ es muy apropiada para casos en los que se dispone de un ancho de banda fijo que se quiera dividir en varios propósitos, dando a cada uno de ellos un ancho de banda garantizado, y con la posibilidad de prestar ancho de banda entre ellos.

1. Disciplina de colas Hierarchical Token Bucket (HTB).

HTB tiene una funcionalidad muy similar a la de CBQ, aunque su implementación es completamente distinta y sus configuración mucho más sencilla. El único pero es que HTB aún no forma parte del kernel estándar de Linux y hay que parcharlo y recompilarlo para utilizarla

1. UTILIZACIÓN DE FILTROS PARA LA CLASIFICACIÓN DE PAQUETES.

Sabemos que en las disciplinas de colas con clases es necesario llevar a cabo una clasificación del tráfico. Es decir, es necesario determinar a qué clase debe ir cada paquete IP.

Para ello utilizamos el concepto de filtro que asociaremos a cada disciplina de colas en la que sea necesario llevar a cabo una clasificación.

Las posibilidades a la hora de filtrar los paquetes son múltiples, incluso hay algunos tipos de filtros que son específicos de determinadas disciplinas de colas.

• u32Mediante las cabeceras de los paquetes
• fwmarkMediante netfilter
• route

Este tipo de filtro proporciona una versatilidad enorme al permitir muchos criterios a la hora de llevar a cabo el filtrado, lo cual hace que sean los más ampliamente utilizados.

Por definición, este tipo de filtro permite filtrar en función de cualquier conjunto de bits, tanto de la cabecera del paquete IP, como de la cabecera del segmento de datos. Sin embargo, este tipo de utilización es bastante complicada, por lo que normalmente se suelen utilizar formas más directas para estos filtros. Así, algunos de estos criterios directos son:

• Dirección IP de origen / destino del paquete
• Protocolo utilizado tcp, udp, icmp, gre, ...
• Puertos de origen y destino utilizados
• Valor del campo TOS de la cabecera IP

Por ejemplo:

# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \

mach ip src 4.3.2.1/32

mach ip dport 80 0xffff flowid 10:1

Este filtro seleccionará aquellos paquetes IP que tenga como dirección origen 4.3.2.1 y puerto destino el 80.

1. Filtro route

Este tipo de filtros toman su decisión en función del resultado obtenido al pasar el paquete IP por la tabla de rutas.

Por ejemplo:

# ip route add 192.168.10.0/24 via 192.168.10.1 dev eth1 realm 10

Con este comando indicamos que los paquetes que vayan a cualquiera de las direcciones 192.168.10.0/24 será marcado con el realm 10 si son consultados por un filtro de tipo route.

# tc filter add dev eth1 parent 1:0 protocol ip prio 100 \

route to 1 0 classid 1:10

Como vemos, cualquier paquete con destino 192.168.10.0/24 será enviado a la clase con manejador 1:10.

Linux utiliza el software netfilter a través de una interfaz a nivel de usuario llamada iptables para llevar a cabo un filtrado de paquetes de estados completos. Utiliza la misma interfaz de nivel de usuario para llevar a cabo la traducción de direcciones de red (NAT), el enmascaramiento y el reencaminamiento de puertos.

Básicamente, existen dos tipos de cortafuegos en Linux y cada tipo básico tiene sus subtipos. Los dos tipos básicos son filtros de paquetes y cortafuegos proxy.

Los filtros de paquetes pueden ser :

• Reencaminamiento. Es en este tipo de cortafuegos de filtro de paquetes donde se toma la decisión de reencaminar o no.
• Enmascaramiento. Estos cortafuegos rescriben las direcciones de origen y destino.

Los cortafuegos proxy pueden ser:

• Estándar. Con este tipo, un cliente se conecta a un puerto especial y se le redirecciona para salir por otro puerto.
• Transparente. Con este cortafuegos, el cliente no usa un puerto especial, sino que el software del cortafuegos hace las funciones de proxy de la conexión de modo transparente.

Con mucha frecuencia, el software de cortafuegos de filtrado de paquetes se usa para ocultar una red pública interna y permitir que entre solamente cierto tráfico.

En otro esquema de red, no se tienen bloques de direcciones IP públicos para trabajar, y en muchas ocasiones, solo tienen acceso telefónico a otras redes TCP/IP, en particular a Internet. Por lo que le les asigna una dirección IP de un grupo de IP disponibles con cada conexión.

Utilizando el enmascaramiento de IP, una red de negocio pequeño o familiar puede dar acceso a todas las máquinas conectadas a una red externa como Internet, utilizando una dirección IP única en un servidor en una única máquina. Todos los paquetes que vayan a Internet se enmascaran como si estuvieran enviados desde el servidor que está ejecutando el enmascaramiento de IP. El servidor mantiene la información necesaria para encaminar los paquetes de la red de vuelta a las máquinas que los deben recibir.

Cada conexión es tanto SNAT como DNAT, dependiendo de en qué dirección vayan los paquetes. Sin embargo, es el paquete de la conexión inicial (un paquete con el bit SYN a 1), el que determina que estamos haciendo. Después de eso, el seguimiento de la conexión permite que los paquetes de retorno vuelvan al sistema origen. El seguimiento de paquetes convierte a netfilter en una herramienta de filtrado de paquetes estados completos, también permite que se ejecute más rápidamente, dado que netfilter recuerda las reglas que afectan a la conexión, las utiliza, y se salta el resto.

1. Componentes del kernel necesarios

Linux, viene en la mayoría de las distribuciones con el kernel precompilado con todo lo que se necesita para utilizar el enmascaramiento de IP. Todo lo que se necesita para implementarlo es cargar algunos módulos del kernel y configurar algunas reglas sencillas de cortafuegos.

Para recompilar nuestro propio kernel, la lista de elementos necesarios es la siguiente:

• Code maturity options. Indicar una de las sig.
• development
• incomplete code
• drivers
• Loadabel module support.
• Habilite (enable)
• Kernel module loader
• Networking options.
• Network packet filtering
• Network packet filtering debugging
• TCP/IP Networking
• IP Netfilter configuration
• Connection tracking
• FTP protocol support
• IP tables support
• Full NAT
• MASQUERADE target support
• IPv6 protocol (opcional)
• IPv6 Netfilter configuration
• IPv6 tables suport
• Packet filtering

1. Módulos

Cuando un paquete de salida de red llega a la máquina cortafuegos (el servidor que tiene el enmascaramiento de IP instalado), el cortafuegos rescribe los elementos de cada paquete para hacer que parezca que salen del cortafuegos y no de la máquina que está detrás del cortafuegos. Los paquetes de retorno se modifican para que vuelvan a la máquina que envió los paquetes de salida originales. Para ninguno de los dos extremos de la transacción nada raro en absoluto parece estar pasando.

Algunos servicios, como FTP, necesitan un trato especial, de ahí el módulo para soportar el seguimiento de conexiones FTP. La razón de este trato especial es que una conexión activa de FTP utiliza dos puertos distintos, el 21 para control, y el 20 para transferencia de datos. Esto complica las cosas porque la conexión del puerto 20 viene, no del cliente, sino del servidor en respuesta al cliente. Esto es necesario para descargas pasivas, que sólo utilizan el canal de control (puerto 21). Este es el comportamiento predeterminado en Netscape e Internet Explorer. Pero, para otros clientes FTP, necesitará el seguimiento de la conexión y que estén cargados los módulos FTP de traducción de direcciones de red (a menos que los arrancase en el modo pasivo o como ncftp que automáticamente conmutará de un modo a otro)

Para tener un servidor de enmascaramiento se deberán tener los sig. módulos:

• ip_tables
• iptable_nat
• ip_conntrack
• ip_conntrack_ftp
• ip_nat_ftp
• ipt_MASQUERADE
• ipt_MARK

Los cuales se pueden cargar manualmente, o al ejecutar el archivo de configuración de reglas.

1. Configuración de reglas

Para cargar automáticamente los módulos y las reglas cada vez que el sistema se reinicie, se crea un archivo con atributos de ejecutable en el directorio /etc/rc.d

• cd /etc/rc.d
• touch ip_tables
• chmod 744 ip_tables

Se edita el archivo ip_tables y se carga con lo siguiente:

/sbin/depmod -a

/sbin/insmod ip_tables

/sbin/insmod ip_conntrack

/sbin/insmod ip_conntrack_ftp

/sbin/insmod ip_conntrack_irc

/sbin/insmod iptable_nat

/sbin/insmod ip_nat_ftp

/sbin/insmod ipt_MASQUERADE

/sbin/insmod ipt_state

/sbin/insmod ipt_MARK

echo "1" > /proc/sys/net/ipv4/ip_forward

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

/sbin/iptables -P INPUT ACCEPT

/sbin/iptables -F INPUT

/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -F OUTPUT

/sbin/iptables -P FORWARD ACCEPT

/sbin/iptables -F FORWARD

/sbin/iptables -t nat -F

/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

/sbin/iptables -A FORWARD

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Donde eth0 es NIC que va a tu bridge y eth1 con la NIC a tu LAN.

Si se utiliza un módem ADSL, sustituir eth0 por ppp0 y emplear:

/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

La última línea se puede sustituir por :

/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.150.244

Donde 192.168.150.244 es la IP de la tarjeta de red a Internet

O por:

/sbin/iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0 -s 172.16.200.0/24 -d0/0

Donde 172.16.200.0/24 es la red local.

Se edita el archivo rc.local y para que se cargue al inicio el archivo de reglas, se le agrega al final:

• /etc/rc.d/./ip_tables

1. Bloqueando salida a Internet

Si tenemos la necesidad de no permitir que determinada IP salga a Internet, solo basta con agregar su dirección a la cadena FORWARD, por ejemplo :

Donde el /32 se refiere a que todos los octetos son ocupados para la identificación de la IP.

Para permitirle salir a Internet nuevamente, solo haya que borrar la regla anterior :

Lo anterior desde la consola o para el caso de varias direcciones se hace con un script ejecutable como por ejemplo:

/sbin/iptables -A FORWARD -s 172.16.200.3/32 -j DROP

/sbin/iptables -A FORWARD -s 172.16.200.4/32 -j DROP

/sbin/iptables -A FORWARD -s 172.16.200.5/32 -j DROP

/sbin/iptables -A FORWARD -s 172.16.200.7/32 -j DROP

/sbin/iptables -A FORWARD -s 172.16.200.8/32 -j DROP

/sbin/iptables -A FORWARD -s 172.16.200.11/32 -j DROP

/sbin/iptables -A FORWARD -s 172.16.200.21/32 -j DROP

/sbin/iptables -D FORWARD -s 172.16.200.3/32 -j DROP

/sbin/iptables -D FORWARD -s 172.16.200.4/32 -j DROP

/sbin/iptables -D FORWARD -s 172.16.200.5/32 -j DROP

/sbin/iptables -D FORWARD -s 172.16.200.7/32 -j DROP

/sbin/iptables -D FORWARD -s 172.16.200.8/32 -j DROP

/sbin/iptables -D FORWARD -s 172.16.200.11/32 -j DROP

/sbin/iptables -D FORWARD -s 172.16.200.21/32 -j DROP

Para listar lo que tengamos en iptables :

Ahora podemos activarlas (Aip para bloquear) desde el arranque en el rc.local y borrarlas (Dip para permitir) desde consola.

Por ejemplo si en el arranque en el rc.local tenemos:

# shaper

/etc/rc.d/ ./spr

# bloqueo de IP’s

/etc/rc.d/./Aip

Podemos programar el CRON para que las active o desactive en determinado horario, en el caso de que se desee que los usuarios de determinadas máquinas puedan tener acceso a Internet solo a determinadas horas:

edita el archivo crontab para el root :

en el cual ponemos :

00 09 * * 1-6 /etc/rc.d/./Dip

00 10 * * 1-6 /etc/rc.d/./Aip

00 14 * * 1-6 /etc/rc.d/./Dip

00 16 * * 1-6 /etc/rc.d/./Aip

Que activará el archivo Dip de lunes a Sábado (1-6) a las 9 de la mañana y a las 14:00 Hrs. y Activará el archivo Aip a las 10 dela mañana y a las 16:00 Hrs.

ya que los campos utilizados son * * * * * tarea

donde los asteriscos respresentan:

1. minutos 0-59
2. horas 0-23
3. días del mes 1-31
4. meses 1-12
5. días de la semana 0-7 donde 0 ó 7 es el domingo

Como separadores se utiliza la coma (, separa números) el guión (- especifica rangos).

Listar lo que tenemos en el crontab:

Borrar lo que hay en el crontab:

Actualmente en Linux se pueden implementar facilidades como:

• Regulación del ancho de banda de alguna interfaz de red (abriéndola o cerrándola)
• Repartir en función de múltiples criterios, el ancho de banda de nuestra interfaz de red.
• Proteger a nuestra red de ataques clásicos como el Deny of Service.
• Proteger a Internet de nuestros propios clientes malandros.
• Multiplexar varios servidores como uno solo, permitiendo implementar el balanceo de carga o la alta disponibilidad.
• Hacer enrutamiento según criterios tan variados como el usuario, dirección, MAC, IP de Origen, tipo de servicio, hora del día, etc.

1. Regulación del ancho de banda -Traffic Shaping-

Existen varias formas de regular el ancho de banda al cual trabajan nuestras interfaces de red todas ellas tinen que ver con el control del tráfico, para prevenir que las aplicaciones que corren en determinada parte, dejen muy limitadas a las que corren en alguna otra. Esto es muy importante si se está conectado al propio cabezal de Internet, ya que de otra forma existe la posibilidad de quitar ancho de banda a los propios clientes.

Lo anterior se consigue mediate los siguientes módulos o scripts:

• shaper. Limita el caudal en la salida de las interfaces exclusivamente.
• rshaper. Limita en ambos sentidos, por IP o bloques de IP’s, pero no está documentado su empleo junto con NAT.
• wondershaper. Utiliza a CBQ o a HTB.
• cbq init script.

1. shaper.o

El modulo shaper, se puede seleccionar en la instalación del Red Hat Linux, o se puede conseguir fácilmente en la red. Aunque existe información sobre como hacerlo andar, es algo confusa y contradictoria en la forma que quedan las rutas del dispositivo físico y el shaper.

0. Creación de ligas simbólicas

Como el kernel solo acepta un módulo a la vez, hay que crear tantas ligas simbólicas al shaper.o, como interfaces de red vayamos a utilizar, por ejemplo utilizamos el módulo shaper.o y la liga shaper1.o para el caso de dos interfaces:

ln - s /lib/modules/2.4.20-8/kernel/drivers/net/shaper.o /lib/modules/2.4.20-8/kernel/drivers/net/shaper1.o

1. Carga del módulo

insmod /lib/modules/2.4.20-8/kernel/drivers/net/shaper.o

insmod /lib/modules/2.4.20-8/kernel/drivers/net/shaper1.o

Al levanter el primer modulo del shaper, queda como shaper0, y los siguientes aparecen como shaper1, shaper2, … shapern. Podemos listar los módulos mediante lsmod | more

2. Fijación a la interface de red

La interfaz del dispositivo físico debe de estar levantada para que se pueda fijar el shaper a la misma.

shapecfg attach shaper0 eth0

shapecfg speed shaper0 128000

shapecfg attach shaper1 eth1

shapecfg speed shaper1 128000

La parte shapecfg attach shaper0 eth0, se puede hacer solo una vez y queda fija hasta no apagar la PC. Pero la parte shapecfg speed shaper0 128000 se puede modificar desde consola o script y refleja cambios de inmediato. Según las referencias encontradas, se le puede dar una velocidad de 8000 a 256000, pero las pruebas que se realizaron, salieron bien en velocidades de 8000 a 1024000.

3. Levantamiento del shaper y configuración de rutas

El shaper lo levantamos como cualquier otra interfaz:

ip link set shaper0 up

ip link set shaper1 up

Ahora le agregamos las direcciones, las cuales deben ser las mismas que la interfaz real, pues si se le quitan, se cae el NAT.

En el caso de la ruta por default de nuestra interfaz con salida a Internet, si se elimina y se levanta la misma pero con salida por el shaper correspondiente.

ip address add 192.168.150.244/24 brd 192.168.150.255 dev shaper0

ip route del default via 192.168.150.2 dev eth0

ip route add default via 192.168.150.2 dev shaper0

ip address add 172.16.200.34/24 brd 172.16.200.255 dev shaper1

ip route flush cache

Se refresca el cache de rutas…

4. Levantamiento de módulos para el NAT

Ahora se procede a cargar los módulos para el NAT :

/sbin/depmod -a

/sbin/insmod ip_tables

/sbin/insmod ip_conntrack

/sbin/insmod ip_conntrack_ftp

/sbin/insmod ip_conntrack_irc

/sbin/insmod iptable_nat

/sbin/insmod ip_nat_ftp

/sbin/insmod ipt_MASQUERADE

/sbin/insmod ipt_state

/sbin/insmod ipt_MARK

echo "1" > /proc/sys/net/ipv4/ip_forward

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

/sbin/iptables -P INPUT ACCEPT

/sbin/iptables -F INPUT

/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -F OUTPUT

/sbin/iptables -P FORWARD ACCEPT

/sbin/iptables -F FORWARD

/sbin/iptables -t nat -F

/sbin/iptables -A FORWARD -i shaper0 -o shaper1 -m state --state ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A FORWARD -i shaper1 -o shaper0 -j ACCEPT

/sbin/iptables -A FORWARD

/sbin/iptables -t nat -A POSTROUTING -o shaper0 -j SNAT --to 192.168.150.244

5. Artesanía para que jale el shaper

Teóricamente el shaper debería de estar funcionando con el NAT en este punto, solo que se encontró en la práctica que no era así, ya que se procedió a montar el shaper cuando ya se tenía el NAT, por lo que se utiliza lo siguiente para que el sistema comience a andar:

Dar de baja y volver a colocar las direcciones de las interfaces de red:

ip address del 192.168.150.244/24 brd 192.168.150.255 dev eth0

ip address del 172.16.200.34/24 brd 172.16.200.255 dev eth1

ip route flush cache

ip address add 192.168.150.244/24 brd 192.168.150.255 dev eth0

ip route del default via 192.168.150.2 dev shaper0

ip route add default via 192.168.150.2 dev eth0

ip address add 172.16.200.34/24 brd 172.16.200.255 dev eth1

ip route flush cache

Ahora colocar el gateway por default nuevamente

ip route del default via 192.168.150.2 dev eth0

ip route add default via 192.168.150.2 dev shaper0

ip route flush cache

6. Agrupando scripts

Para la implementación y la interactividad fácil desde la consola, se encontró que es mejor separar en pequeños scripts la forma de levantar el NAT y el shaper, siendo la forma como quedó finalmente:

1. Se edita el archivo rc.local quitando o comentado /etc/rc.d/./ip_tables y agregándole al final: /etc/rc.d/./spr
2. El archivo spr se hace ejecutable

• cd /etc/rc.d
• touch spr
• chmod 744 spr

insmod /lib/modules/2.4.20-8/kernel/drivers/net/shaper.o

shapecfg attach shaper0 eth0

shapecfg speed shaper0 128000

shapecfg attach shaper1 eth1

ip route del default via 192.168.150.2 dev eth0

ip route add default via 192.168.150.2 dev shaper0

1. El archivo s_Prutas lleva:

ip link set shaper0 up

ip link set shaper1 up

ip address add 192.168.150.244/24 brd 192.168.150.255 dev shaper0

ip route del default via 192.168.150.2 dev eth0

ip route add default via 192.168.150.2 dev shaper0

ip address add 172.16.200.34/24 brd 172.16.200.255 dev shaper1

ip route flush cache

2. ip_modulos lleva:

/sbin/depmod -a

/sbin/insmod ip_tables

/sbin/insmod ip_conntrack

/sbin/insmod ip_conntrack_ftp

/sbin/insmod ip_conntrack_irc

/sbin/insmod iptable_nat

/sbin/insmod ip_nat_ftp

/sbin/insmod ipt_MASQUERADE

/sbin/insmod ipt_state

/sbin/insmod ipt_MARK

3. s_ip_reglas lleva:

echo "1" > /proc/sys/net/ipv4/ip_forward

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

/sbin/iptables -P INPUT ACCEPT

/sbin/iptables -F INPUT

/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -F OUTPUT

/sbin/iptables -P FORWARD ACCEPT

/sbin/iptables -F FORWARD

/sbin/iptables -t nat -F

/sbin/iptables -A FORWARD -i shaper0 -o shaper1 -m state --state ESTABLISHED,RELATED -j ACCEPT

/sbin/iptables -A FORWARD -i shaper1 -o shaper0 -j ACCEPT

/sbin/iptables -A FORWARD

/sbin/iptables -t nat -A POSTROUTING -o shaper0 -j SNAT --to 192.168.150.244

4. Qrutas lleva:

ip address del 192.168.150.244/24 brd 192.168.150.255 dev eth0

ip address del 172.16.200.34/24 brd 172.16.200.255 dev eth1

ip route flush cache

5. Prutas lleva

ip address add 192.168.150.244/24 brd 192.168.150.255 dev eth0

ip route del default via 192.168.150.2 dev shaper0

ip route add default via 192.168.150.2 dev eth0

ip address add 172.16.200.34/24 brd 172.16.200.255 dev eth1

ip route flush cache

6. Finalmete se hacen scripts para poner la velocidad que deseemos, la cual es tomada enseguida, y unas ligas simbólicas en el directorio /root para activar comodamente:

1. s8

shapecfg speed shaper0 8000

shapecfg speed shaper1 8000

2. s16

shapecfg speed shaper0 16000

shapecfg speed shaper1 16000

3. s32

shapecfg speed shaper0 32000

shapecfg speed shaper1 32000

4. s64

shapecfg speed shaper0 64000

shapecfg speed shaper1 64000

5. s128

shapecfg speed shaper0 128000

shapecfg speed shaper1 128000

6. s256

shapecfg speed shaper0 256000

shapecfg speed shaper1 256000

7. s512

shapecfg speed shaper0 512000

shapecfg speed shaper1 512000

8. sInsano

1. Comentarios

1. Se hace notar que en las referencias consultadas estaba un límite de 8000 a 256000, pero en alguna otra documentación tenía una velocidad arriba de 256000, por lo que en las pruebas que se hicieron con varias PC’s de la red, se soportaba 8000k hasta 1024000k, no queriendo probar mas arriba, para no interferir con el ancho de banda de los clientes. El ancho de banda inicial era alto, y casi de inmediato el shaper lo acomodaba al caudal deseado, el cual era correcto en las páginas de prueba bandwidth test.
2. La velocidad puede ser diferente entre los shapers, depende de lo que tratemos de hacer.
3. Se hicieron scripts similares para el caso del NAT exclusivamente, para poder alternar y/o probar ambas cosas.

• DOWNLIK. Vel. de bajada en Kb, un poco menor a nuestra vel. máxima
• UPLINK. Vel. de subida en Kb, un poco menor a nuestra vel. máxima
• DEV. Interfaz con salida a Internet
• NOPRIOHOSTSRC. IP’s locales con baja prioridad
• NOPRIOHOSTDST. IP’s foráneas con baja prioridad
• NOPRIOPORTSCR. Puertos Locales con baja prioridad.
• NOPRIOPORTDST. Puertos foráneos con baja prioridad.

En el DOWNLINK Y UPLINK como trabajamos con velocidades iguales en nuestro servicio, pues, las dejé iguales, sólo limitándolos a algo cercano a 256K.

1. Se encontró al wondershaper realmente fácil de ajustar, pues se limita solo el caudal de la interfaz con salida a Internet.
2. Los valores introducidos en la velocidad son aproximados, encontrándose que variaban de 0 a un 10%.
3. Cuando un PC con alta prioridad, necesita más ancho de banda, lo toma de las PC’s marcadas para una baja prioridad.
4. En el script original la línea :

5. Cuando cargamos el wondershaper (o al cbq), ignora las reglas del iptables donde se bloquean a determinadas IP’s.

1. cbq.init script

El cbq, viene incluido con el Red Hat : cbq.init v0.7.1 (Red Hat modified for bug 53904). como cbq en /sbin/cbq.

Para activar el cbq, se debe de escribir un archivo para cada shaper en el directorio /etc/sysconfig/cbq.

1. Cada archivo se debe de empezar con el nombre cbq-
2. Luego un identificador que puede estar en el rango [0002-FFFF]
3. punto . para separar el número del nombre del shaper
4. Nombre del shaper, que puede ser cualquier palabra.

cbq-identificador.nombre

Si existe el archivo cbq-0000.example, ponerle otro nombre distinto, por ejemplo ej_cbq-0000.example, para que no se interfiera a la hora de compilar.

Por default viene el archivo con los parámetros:

1. Parámetros de dispositivo

DEVICEes la interfaz y si se tiene mas de una clase en la misma, en las demás solo pondremos el nombre y omitimos el bandwidth y weight.

Bandwidth se refiere a la velocidad real de nuestra interfaz y weight es aprox. 1/10 de la misma.

2. Parámetros de Clases

RATE es el ancho de banda asignado a la clase, se pueden utilizar KBit, MBit y BPS

WEIGHTes el ajuste fino y aprox. es igual a 1/10 de RATE.

PRIOes la prioridad. donde 1 es la más alta y 8 la mínima.

Adicionalmente tenemos:

PARENT=<clsid> Especifica la identificación de la clase padre a la cual esta vinculado el shaper. (Se deben construir clases padre antes de sus hijos).

LEAF= none | tbf | sfq Especifica que cola se va a utilizar : token bucket filter, stochastic fairness queueing o ninguna. (por default es la tbf la que utiliza, este tipo de disciplina es el que se utiliza en el caso de que nuestra única necesidad sea limitar el ancho de banda de un determinado interfaz).

Para permitir que la cola pida prestado ancho de banda, se debe poner none o a sqf. Y sfq se utiliza para distribuir el ancho de banda de forma equitativa, para evitar que alguien se lo apropie todo.

BOUNDED=yes | no Si se pone a no, permite pedir prestado ancho de banda a su clase padre si sobrepasa el asignado (LEAF debe de estar = none o sqf), si se pone yes no permite pedir prestado ancho de banda.

ISOLATED=yes | no Puesta a yes la clase no presta ancho de banda no usado a sus hijos.

3. Parámetros de TBQ qdisc

BUFFER=<bytes>[/bytes] controla la profundidad del token bucket. Representa el tamaño máximo del burst que la clase puede enviar. La parte opcional es para determinar la longitud de los intervalos en el tamaño de los paquetes , para los cuales se guardan los tiempos de transmisión. (ej. 10Kb/8)

LIMIT=<bytes> Determina la longitud máxima de reserva, si la cola contiene más datos que los especificados por LIMIT, se descartan los paquetes nuevos que llegan. La longitud de reserva determina la latencia de la cola en caso de congestión. (ej. 15Kb)

PEAK=<speed> Tarifa máxima absoluta para el tráfico. Esto permite que controles la tarifa máxima absoluta que la clase puede enviar, porque TBF que permite 256Kbit/s por supuesto permitiría el índice de 512Kbit para la mitad de un segundo o 1Mbit para un cuarto de segundo.

MTU=<bytes> Número máximo de octetos que se pueden enviar inmediatamente sobre el médio físico. Se requiere cuando se ha especificado PEAK. Por lo general se omite el MTU de Ethernet, pero, para otros tipos de medios puede que se desee cambiarlo. (ej. MTU=1500)

4. Parámetros de SFQ qdisc

QUANTUM=<bytes> Este parámetro no se debe fijar más bajo que el MTU, para Ethernet es 1500b, o (con la cabecera del MAC) 1514b que es el valor usado en los ejemplos de Alexey Kuznetsov.

PERTURB=<segundos> Periodo de la perturbación de la función hash. si no se utiliza, la reconfiguración del hash nunca ocurrirá, que es lo que probablemente no desea El valor prefijado de 10 segundos es uno bueno. (PERTURB=10)

5. Parámetros de filtrado