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