Network Address Traslator

Para acceso a Internet en una Red local

2. Fundamentación. Marco teórico
3. Instalación del S.O. Linux, distribución red HAT.
4. Configuración NAT
5. Permutación Shaper – Wondershaper – CBQ
6. Bibliografía

1. Actualmente las direcciones IP públicas (Homologadas), son insuficientes para atender a toda la población de usuarios que demanda servicio de Internet, y por el mismo motivo, la obtención de una IP oficial homologada es costoso.

   Si contamos con una red local, funcionando con TCP/IP sobre un rango de direcciones privadas, es posible mediante un Traductor de Direcciones de Red, que las demás máquinas accedan a Internet de forma trasparente, ocultas tras la máquina pasarela, la cual es la que aparece como el único sistema que está usando Internet

   El Sistema Operativo Linux, es por mucho, una mejor opción que los sistemas comerciales que ofrecen NAT, pues además de ser gratuito viene preparado con utilerías que los demás sistemas apenas empezaran a ofrecer y que muchos sistemas propietarios solo ofrecen en sus gamas altas.

   FUNDAMENTACIÓN

   1. Actualmente las direcciones IP públicas (Homologadas), son insuficientes para atender a toda la población de usuarios que demanda servicio de Internet, y por el mismo motivo, la obtención de una IP oficial homologada es costoso.

      Si contamos con una red local, funcionando con TCP/IP sobre un rango de direcciones privadas, es posible mediante un Traductor de Direcciones de Red, que las demás máquinas accedan a Internet de forma trasparente, ocultas tras la máquina pasarela, la cual es la que aparece como el único sistema que está usando Internet.

      1. El filtrado de paquetes es un mecanismo de inspección, manejo y control de los paquetes que pasan por un sistema.

         Sirve para la implementación de Firewalls, Control de acceso, Interconexión de redes e Implementación de políticas de uso.

      2. Filtrado

         La traducción de direcciones de red, es el cambio de la dirección de origen o destino de un paquete y la forma o control de cómo se hace.

         Y se utiliza para intercomunicar redes públicas y privadas, redirigir peticiones, compartir recursos (direcciones IP, medios de comunicación), ocultar la estructura de la red interna para la protección de sus nodos.

      3. NAT
         1. Reglas
      4. Funcionamiento
   2. Marco teórico
2. INTRODUCCIÓN

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.

Por lo que el orden de las mismas importa, dado que es secuencial.

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

2. 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).

2. 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. 0. 0. Filtrado
   1. IPFilter
2. PROCESO DE 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 :

iptables [-t tabla] comando especificación _de_regla [opciones]

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

Se tiene que declarar la cadena que se vaya a utilizar, aun cuando cree o borre una cadena definida por el usuario. Sólo las cadenas incorporadas OUTPUT y PREROUTING pueden pertenecer a más de una tabla.

1. -A append, agregar. Este comando acepta un nombre de cadena y la especificación de una regla como parámetros obligatorios.

   -D delete, eliminar. Acepta un nombre de cadena y la especificación de una regla o el número de regla como parámetros obligatorios.

   -C test / check, probar / comprobar. -s, -d, -p, e –i son obligatorios. Este comando acepta un nombre de cadena y la especificación de una regla como parámetros obligatorios.

   -I insert, insertar. Es una extensión de append, pero la especificación de la regla se pone delante del número de regla al que hace referencia. Este comando acepta un nombre de cadena, el número de regla antes de la cual hacer la inserción y una especificación de regla como parámetros obligatorios.

   -R replace, reemplazar. insert y delete. Este comando acepta como parámetros obligatorios un nombre de cadena, un número de regla y la especificación de una regla. La especificación de regla reemplazará al número de regla de la cadena especificada.

   -F flush, vaciar. Borra todas las reglas de una cadena, o todas las reglas de todas las cadenas si no se especifica la información de ninguna cadena.

   -L list, enumerar. Enumera todas las reglas de una cadena o todas las reglas de todas las cadenas si no se especifica ningún nombre de cadena.

   -Z zero, poner a cero. Pone a cero los contadores. Pone a cero los contadores de la cadena especificada o de todas las cadenas si no se da el nombre de ninguna.

   -N new, nueva. Crea una cadena definida por el usuario. Este comando necesita sólo un nombre de cadena como parámetro obligatorio

   -X delete a user-defined chain, borrar una cadena definida por el usuario. Este comando necesita un nombre de cadena, y la cadena tiene que haber sido vaciada. Las cadenas predeterminadas no se pueden borrar.

   -P policy, política. Este comando acepta un nombre de cadena y un objetivo como argumentos obligatorios.

   -E rename chain, renombrar cadena. Este comando acepta el nombre de cadena viejo y el nombre de cadena nuevo como argumentos obligatorios.

   -h help, ayuda. Opcionalmente acepta un argumento.

2. Comandos
3. Opciones

• 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:

-p tcp -sport 0:1023

-m multiport –p tcp -sport 25, 110

• –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:

-p tcp – – tcp-flags SYN, ACK, RST, FIN SYN, ACK

• [!] – – 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):

echo-reply (pong)

destination-unreachable

network-unreachable

host-unreachable

protocol-unreachable

port-unreachable

fragmentation-needed

source-route-failed

network-unknown

host-unknown

network-prohibited

host-prohibited

TOS-network-unreachable

TOS-host-unreachable

communication-prohibited

host-precedence-violation

precedence-cutoff

source-quench

redirect

network-redirect

host-redirect

TOS-network-redirect

TOS-host-redirect

echo-request (ping)

router-advertisement

router-solicitation

time-exceeded (ttl-exceeded)

ttl-zero-during-transit

ttl-zero-during-reassembly

parameter-problem

ip-header-bad

required-option-missing

timestamp-request

timestamp-reply

address-mask-request

address-mask-reply

• –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

Si se quiere implementar prioridades de encaminamiento basadas en el servicio (TOS) se deben utilizar los valores de la tabla No.1.

1. Objetivos iptables

Un objetivo es una acción que hay que llevar a cabo cuando los paquetes se corresponden con la especificación de la regla. Todas las cadenas embebidas tendrán una política predeterminada que, en caso de que no haya ninguna otra regla que la anule, determine el futuro del paquete. Todas las políticas están predeterminadas a ACCEPT.

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

LOG. Permite que los paquetes con los que se ha establecido una correspondencia sean registrados. El objetivo LOG puede aceptar cualquiera de los siguientes parámetros opcionales:

• – -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.

MARK. Establece la marca de cortafuegos (fwmark) para que la utilicen las subsiguientes reglas. Esto requiere la tabla mangle (-t mangle) y tiene el siguiente parámetro obligatorio: – – set mark marca. La marca será un valor numérico.

REJECT. Equivalente a DROP, pero se devuelve un mensaje de error. Solamente válido en las cadenas INPUT, FORWARD y OUTPUT (igual que DROP o ACCEPT). REJECT tiene el siguiente parámetro opcional: – – reject-with tipo. Le permite cambiar el mensaje predeterminado icmp-net-unreachable (red icmp no accesible) por uno de éstos : icmp-host-unreachable (servidor icmp no accesible), icmp-port-unreachable (puerto icmp no accesible) o icmp-proto-unreachable (protocolo icmp no accesible), Si la regla específica –p icmp, entonces el parámetro reject-with puede aceptar echo-reply (respuesta de eco).

TOS. Permite dar valor al campo de tipo de servicio. Solamente válido en la cadena PREROUTING o en la OUTPUT. Acepta un argumento obligatorio: – – set-tos tos. Donde tos puede ser uno de los valores numéricos de la tabla No 1.

MIRROR. Objetivo experimental que intenta hacer de espejo de los paquetes conmutando las direcciones IP de origen y destino. Válido solamente en las cadenas INPUT, FORWARD y OUTPUT.

SNAT. Necesita la tabla nat (-t nat) y es válido solamente en la cadena POSTROUTING. Acepta un argumento obligatorio: – -to source dirección-ip[-dirección-ip] [:puerto-puerto]. Cambia la dirección origen del paquete de salida a la especificada en el parámetro. Cambiará también los puertos de los protocolos udp y tcp, si es necesario. Normalmente, no habrá alteración de puertos.

DNAT. Necesita la tabla nat (-t nat) y es válido solamente en la cadena PREROUTING. Acepta un argumento obligatorio: – -to-destination dirección-ip[-dirección-ip] [:puerto-puerto]. Cambia la dirección destino del paquete de entrada a la(s) especificada(s) en el parámetro. Cambiará también los puertos de los protocolos udp y tcp si es necesario. Normalmente, no habrá alteración de puertos.

MASQUERADE. Necesita la tabla nat (-t nat) y es válido solamente en la cadena POSTROUTING. Par uso de conexiones de acceso telefónico. Acepta un parámetro opcional: – -to-ports puerto[-puerto]. Este comando toma preferencia sobre la heurística de selección de puerto predeterminada. Válido solamente con –p tcp o –p udp.

REDIRECT. Necesita la tabla nat (-t nat) y es válido solamente en las cadenas PREROUTING Y OUTPUT (o cadenas definidas por el usuario que se llamen desde esas cadenas). Envía paquetes a localhost. Acepta un parámetro opcional: – -to –ports puerto[-puerto]. Este comando toma preferencia sobre la heurística de selección de puerto predeterminada. Válido solamente con –p tcp o –p udp.

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:

# ip rule list

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’:

# echo 200 hotmail >> /etc/iproute2/rt_tables

# ip rule add from 192.168.10.0/24 table 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:

# ip route add default via 195.96.98.253 dev ppp2 table hotmail

# ip route flush cache

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

1. 0. Es el algoritmo que gestiona el proceso de encolar paquetes en un dispositivo (interfaz de red). Esta gestión puede ser tanto en la cola de entrada (ingress), como en la cola de salida (egress).

   1. Disciplina de colas

      Es aquella disciplina de colas que no admite una subdivisión interna que pueda ser configurada por el usuario.

   2. Disciplina de colas sin clases

      Una disciplina de colas con clases puede contener muchas clases, cada una de las cuales es interna a la disciplina de colas. Además, cada clase contiene una nueva disciplina de colas, que puede ser con clases o sin ellas.

   3. Clases y Disciplinas de colas con clases
   4. Clasificador y filtro

   Las disciplinas de colas con clases necesitan determinar a qué clase envían cada paquete que llega. Esto lo hacen utilizando un clasificador. A su vez la clasificación la llevan a cabo utilizando filtros, los cuales determinan una serie de condiciones que deben cumplir los paquetes.

2. Disciplinas de colas para la gestión de tráfico
3. DISCIPLINAS DE COLAS SIN CLASES

Tienen la capacidad de reordenar, retrazar o descartar los paquetes que van llegando para ser enviados:

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

1. Esta disciplina de colas está formada por tres bandas (0, 1 y 2). Dentro de cada banda los paquetes son enviados siguiendo una política FIFO (First In, First Out). Pero ningún paquete de la banda 1 es enviado mientras existan paquetes por enviar de la banda 0, y lo mismo ocurre para la banda 2. Es decir, existe una prioridad definida entre dichas bandas, siendo la banda 0 la más prioritaria y la banda 2 la de menor prioridad.

   Aunque la cola pfifo_fast tiene una subdivisión interna de tres bandas, no puede ser modificada por el usuario.

   Para determinar los paquetes que van a cada banda se utiliza el campo TOS de la cabecera IP del mismo. El proceso consiste en que el kernel de Linux primero da una determinada prioridad a los paquetes en función del valor del campo, y posteriormente existe un mapeo de prioridades, definibles por el usuario, entre la prioridad asignada por el kernel y cada una de las tres bandas.

   Los valores mas importantes para el campo TOS de la cabecera IP están dados en la tabla No. 2 y el mapeo en la tabla No. 3:

   Tabla No. 2 Prioridades para el campo TOS de la cabecera IP
   Binario	Decimal	Significado
   1000	8	Minimize delay (md)
   0100	4	Maximize throughput (mt)
   0010	2	Maximize reliability (mr)
   0001	1	Minimize monetary cost (mmc)
   0000	0	Normal Service

   Tabla No. 3 Mapeo de prioridades pfifo_fast

   Para ver el gráfico seleccione la opción "Descargar" del menú superior

   La columna Banda pfifo_fast es la que determina cómo se mapea cada una de las prioridades del kernel de Linux a las bandas de la disciplina de colas. Este mapeo es configurable por el usuario a través del parámetro priomap.

2. PFIFO_FAST
3. Token Bucket Filter

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 root tbf rate 220kbit latency 50ms burst 1540

• 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. 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. 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
   1. Disciplina de colas PRIO
2. DISCIPLINAS DE COLAS CON CLASES

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

# tc qdisc add dev eth0 root handle 1: prio

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

# tc qdisc add dev eth0 parent 1:1 handle 10: sfq

# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000

# tc qdisc add dev eth0 parent 1:3 handle 30: sfq

Ahora podemos comprobar lo que hemos creado:

# tc –s qdisc ls dev eth0

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. 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.
2. Disciplina de colas Class-Based Queueing (CBQ)

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

1. Filtro u32

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.

1. La instalación se realizó con los CD’s quemados a partir de las imágenes iso, del Red Hat Linux release 9 ‘Shrike’, Kernel 2.4.20-8, bajadas de un espejo encontrado a través de http://www.redhat.com .

   Con la 9 ‘Shrike’, la configuración de las tarjetas de red, se realiza con el control de dispositivos de red, en el entorno X’s. Anteriormente se realizaba mediante linuxconf desde la consola.

2. Instalación del S.O. Linux, distribución Red Hat.
   1. Introducción
3. CONFIGURACIÓN NAT

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.

1. Los cortafuegos de filtrado funcionan siguiendo este principio: la información que se necesita para tomar una decisión sobre qué hacer con un paquete está en la cabecera. La cabecera contiene información sobre las direcciones origen y destino, el tiempo de vida (TTL), el protocolo, y mucha más información. También contiene la suma de comprobación de la cabecera, que ayuda a identificar si la cabecera ha sido corrompida. En resumen, en una cabecera de IP van contenidos unos trece campos distintos, muchos de los cuales contienen múltiples piezas de información.

   IP no comprueba el valor de payload nada más que para ver si es del tamaño correcto. El protocolo de control de transporte TCP, es el responsable de asegurar la integridad de la carga. Los paquetes UDP no tienen ningún método de comprobación de errores inherente.

   Linux, desde el kernel 2.4.0, utiliza netfilter y la herramienta de nivel de usuario iptables, para proporcionar el filtrado de paquetes. Para implementar un cortafuegos de filtrado de paquetes, se tienen que tomar decisiones al respecto de qué tipo de paquetes filtrar específicamente y qué hacer con ellos cuando se encuentran esos paquetes.

   El software de iptables permite aplicar varios criterios diferentes a los paquetes.

   Los criterios se pueden aplicar a paquetes de entrada, de salida, o a paquetes que atraviesen el cortafuegos. Estás decisiones se pueden basar en: de dónde vienen los paquetes por la dirección, a dónde van por la dirección o a dónde van por el puerto.

   Se pueden aplicar diferentes reglas, dependiendo de si son paquetes TCP, paquetes UDP o paquetes ICMP. La forma de funcionamiento de netfilter también permite manipular el post y preencaminamiento de los paquetes, y pude filtrar conexiones basándose en conexiones nuevas, establecidas o relacionadas, igual que con los paquetes de dirección, basándose en indicadores específicamente activados en el paquete.

   Netfilter también pude alterar los paquetes, cambiando los indicadores, que se pueden utilizar luego para cambiar la prioridad de la colocación de los paquetes en la cola. Finalmente, para aquellos paquetes que no tienen especificado un tratamiento concreto, la política general determina su destino final.

   La capacidad de netfilter de manejar paquetes asociados con conexiones establecidas o relacionadas, la convierte en una herramienta de "estados completos". Éste es un término empleado por el marketing, del que se abusa, y que significa que el software puede hacer el seguimiento total de las conexiones. De hecho, cualquier software de filtrado de paquetes (como ipchains, anterior al kernel 2.2.x de Linux) que permite secciones activas de FTP, es de estados completos. Esto también se aplica a cualquier software capaz de hacer el seguimiento de conexiones enmascaradas. Netfilter también hace el seguimiento de estas conexiones y los siguientes paquetes (establecidos o relacionados) no son sometidos al conjunto completo de reglas. sino sólo a aquellas que se aplicaron a la conexión inicial, haciendo que netfilter se ejecute más rápido.

2. Filtros de paquetes

   Los cortafuegos proxy funcionan de manera diferente que los filtros de paquetes.

   Todo el tráfico se recibe en el cortafuegos, bien sea de entrada o de salida. Pero los proxy redirigen el tráfico permitido a través del cortafuegos rescribiendo sus cabeceras. Para ser redirigido, el tráfico ha de registrarse en el cortafuegos. De hecho, gran parte del análisis de la sección previa se puede aplicar a un proxy. La diferencia es sutil; dado que el software de filtrado de paquetes lo que hace es rescribir las cabeceras cuando hace enmascaramiento y normalmente no redirige el tráfico, y el proxy transparente, reencamina (localmente) el tráfico que llega a una interfaz, y sale por otra. Los proxy funcionan a más alto nivel en el modelo OSI que los filtros de paquetes, por lo que tienen mas sobrecarga de trabajo, pero pueden inspeccionar paquetes enteros con más detenimiento. También pueden hacer cosas como mantener un caché de conexiones para aumentar la velocidad de acceso.

   Cualquier encaminador, pasarela o servidor que transporta un paquete de red de una red a otra, rescribe la cabecera. Pero la reescritura no altera las direcciones de origen o destino; sólo altera el valor de TTL y la suma de comprobación, y, ocasionalmente, la longitud total y el valor de desplazamiento relativo de fragmento (entre otros), si hay que fragmentar los paquetes para continuar. En estas notas, la reescritura de las cabeceras se refiere principalmente a la reescritura de las direcciones.

3. Cortafuegos Proxy

   La traducción de direcciones de red, básicamente le permite rescribir las cabeceras de paquetes según pasan por el cortafuegos. Estas cabeceras pueden ser escritas según van saliendo del cortafuegos (post-encaminamiento) e implica el cambio de la dirección original del sistema que inicia la conexión por la dirección externa del cortafuegos. Un servidor de Internet verá entonces una conexión que se origina en el cortafuegos o sistema NAT. Dado que la dirección original es la que se cambia, netfilter la denomina NAT del origen o SNAT. Puede utilizar este mecanismo para proteger una red con direcciones IP públicas. En una forma especializada de SNAT, el enmascaramiento de IP, se utiliza comúnmente para permitir que una red con direcciones IP privadas (direcciones IP no encaminables hacia Internet) sea capaz de acceder a Internet. Ambos mecanismos hacen lo mismo, y ambos se pueden utilizar con direcciones IP privadas. Sin embargo el enmascaramiento de IP está reservado, generalmente, para cuentas de acceso telefónico con direcciones IP dinámicas. Si no sabe qué dirección IP se le ha asignado cuando se conecta a su ISP, esto es probablemente lo que tiene, así que necesitará emplear enmascaramiento en lugar de SNAT.

4. SNAT

   El otro tipo de NAT, o alteración de paquetes, que permite netfilter se llama NAT de destino o DNAT. Esta forma de alteración de la dirección de hace antes del encaminamiento y se usa para tomar una conexión inicial al sistema NAT y redirigirla a un sistema interno. En algunos círculos, a este mecanismo se le denomina reencaminamiento de puertos, porque el reencaminamiento generalmente se basa en el puerto inicial de la conexión. Esto le permitiría tener sistemas independientes en sus red de confianza capaces de manejar HTTP, FTP, correo, DNS, y demás, pero aparentado que la máquina NAT es la que está haciendo todo el trabajo. Esta particular forma de alteración de direcciones requiere que disponga de una dirección IP encaminable. Si tiene que utilizar enmascaramiento de IP, entonces no podrá utilizar DNAT.

5. DNAT
6. Enmascaramiento

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 :

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

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 :

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

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

• touch Aip
• chmod 744 Aip
• touch Dip
• chmod 744 Dip

Aip :

/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

Dip:

/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

Si llegáramos a ejecutar los scripts mas de una ocasión, las cadenas se duplican tantas veces como agreguemos la cadena, en el caso del borrado, si no existe una regla similar, se arroja un error indicándolo solamente.

Para listar lo que tengamos en iptables :

iptables -L

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

1. Automatización de las cadenas

Una buena opción es utilizar al demonio CRON, para programar el horario de activación – desactivación de las cadenas.

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 :

crontab -e

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:

crontab -l

Borrar lo que hay en el crontab:

crontab -r

1. Pruebas y Optimizaciones

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. 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. 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. Creación de ligas simbólicas

      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. Carga del módulo

      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. Fijación a la interface de red

      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 del shaper y configuración de rutas

      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. Levantamiento de módulos para el NAT

      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. Artesanía para que jale el shaper
   7. Agrupando scripts
2. shaper.o

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

y se le agrega:

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

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

shapecfg attach shaper0 eth0

shapecfg speed shaper0 128000

shapecfg attach shaper1 eth1

shapecfg speed shaper1 128000

/etc/rc.d/./s_Prutas

/etc/rc.d/./ip_modulos

/etc/rc.d/./s_ip_reglas

/etc/rc.d/./Qrutas

/etc/rc.d/./Prutas

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

1. 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. El archivo s_Prutas 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. ip_modulos 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. s_ip_reglas 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. Qrutas 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. Prutas lleva
7. 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. shapecfg speed shaper0 8000

   shapecfg speed shaper1 8000

2. s8

   shapecfg speed shaper0 16000

   shapecfg speed shaper1 16000

3. s16

   shapecfg speed shaper0 32000

   shapecfg speed shaper1 32000

4. s32

   shapecfg speed shaper0 64000

   shapecfg speed shaper1 64000

5. s64

   shapecfg speed shaper0 128000

   shapecfg speed shaper1 128000

6. s128

   shapecfg speed shaper0 256000

   shapecfg speed shaper1 256000

7. s256

   shapecfg speed shaper0 512000

   shapecfg speed shaper1 512000

8. s512
9. sInsano

shapecfg speed shaper0 1024000

shapecfg speed shaper1 1024000

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.

1. De la página http://lartc.org/wondershaper/ se bajó el wondershaper-1.1a.tar.gz, se descomprime (en nuestro caso lo hicimos en /etc/sysconfig/cbq/):

   $ tar −xzvf wondershaper−1.1a.tar.gz

   La forma de activarlo, es realmente fácil, solo se modifican en el script wshaper.htb los siguientes parámetros:

   DOWNLINK=800

   UPLINK=220

   DEV=ppp0

   # low priority OUTGOING traffic – you can leave this blank if you want

   # low priority source netmasks

   NOPRIOHOSTSRC=

   # low priority destination netmasks

   NOPRIOHOSTDST=

   # low priority source ports

   NOPRIOPORTSRC=

   # low priority destination ports

   NOPRIOPORTDST=

   Y se comentan o remueven las siguientes 2 líneas:

   echo Please read the documentation in 'README' first

   exit

   0. Ajustes
2. wshaper.htb

• 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 puede hacer a mano, pero es preferible editar el archivo rc.local con:

   /etc/rc.d/./ip_tables

   /etc/sysconfig/cbq/wondershaper-1.1a/./wshaper.htb

   Para hacerlo a mano, se puede elaborar un enlace simbólico por ejemplo al directorio rc.d :

   ln –s /etc/sysconfig/cbq/wondershaper-1.1a/whaper.htb /etc/rc.d/whaper.htb

   Y para arrancarlo o detenerlo :

   ./wshaper start

   ./wshaper stop

2. Arranque
3. Comentarios

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 :

# low priority destination ports

NOPRIOPORTSRC=

Hay que corregirla a NOPRIOPORTDST=

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:

DEVICE= <interfaz>,<bandwidth>,<weight>

RATE=<speed>

WEIGHT=<speed>

PRIO=<1-8>

1. 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 dispositivo

   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 Clases

   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 TBQ 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 SFQ qdisc
6. Parámetros de filtrado

RULE=[[saddr[/prefix]] [:port[/mask]] [daddr[/prefix]] [:port[/mask]] Estos parámetros levantan las reglas de filtrado "u32" que deriva el tráfico por cada una de las clases. Usted puede utilizar campos múltiples de RULE por cada configuración. La máscara de puertos opcional solo debe ser utilizada por usuarios experimentados que entienden cómo funciona el filtro u32. (ej. 10.1.1.0/24:80)

MARK=<mark> Este parámetro levanta las reglas del filtro "fw" para cada una de las clases de acuerdo a "mark" del cortafuegos. La marca del paquete es un número decimal que etiqueta cada paquete que cumple una regla si una regla del firewall así lo dicta. Puede utilizar campos múltiples de la MARK por cada configuración. Las reglas para diversos tipos de filtro pueden ser combinadas. Se debe poner atención.

Configuración (1)

Arranque (1)

Comentarios (1)

PERMUTACIÓN shaper – wondershaper – cbq (1)

BIBLIOGRAFÍA (1)

(1) Para ver la monografía completa seleccione la opción "Descargar" del menú superior

Benigno Martínez Carranza