Monografias.com > Computación > Redes
Descargar Imprimir Comentar Ver trabajos relacionados

Network Address Traslator




Enviado por benigno



    Para acceso a Internet en una Red local

    1. Fundamentación. Marco
      teórico
    2. Instalación del S.O.
      Linux, distribución red HAT.
    3. Configuración
      NAT
    4. Permutación Shaper –
      Wondershaper – CBQ
    5. 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
    1. Semejanzas entre IPFilter y NetFilter
    • Realizan un filtrado a nivel del kernel
    • Paquetes IP en sus distintos protocolos
      asociados TCP, UDP, ICMP
    • Herramientas de administración :
    • ipf, ipfstat, ipnat para IPFilter.
    • iptables para NetFilter
    • Inspección Stateless y Stafeful
    • Conteo de paquetes
    • Política por omisión.
    • Ambos paquetes tienen mecanismos para alterar sus
      acciones
      (quick, RETURN).
    1. Diferencias entre IPFilter y NetFilter

    Filosofías opuestas.

    IPFilter:

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

    NetFilter:

    • Se ejecuta la acción de la primera regla que
      coincide.
    • Se identifica el caso del que se trata y se ejecuta una
      acción.
        1. Filtrado
      1. IPFilter
    1. 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:

    1. POSTROUTING
    2. 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.

    Tabla No. 1

    PRIORIDADES DE ENCAMINAMIENTO
    BASADAS EN TOS

    Nombre de TOS

    TOS numérico

    Valor Hexadecimal

    Ejemplos

    Retraso Mínimo

    16

    0x01 0x10

    FTP, telnet, ssh

    Rendimiento Máximo

    8

    0x01 0x08

    FTP-datos

    Fiabilidad Máxima

    4

    0x01 0x04

    snmp, DNS

    Coste Mínimo

    2

    0x01 0x02

    nntp, e-mail

    Servicio Normal

    0

    0x01 0x00

     

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

      2. Disciplina de colas

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

      3. 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.

      4. Clases y Disciplinas de colas con clases
      5. 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.

    1. Disciplinas de colas para la gestión de
      tráfico
    2. 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.

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

        1. Parámetros de las disciplinas de
          colas PRIO
      2. 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:

    Tabla No. 4

    Ejemplo de prioridad con
    disciplina PRIO

    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.

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

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

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

      3. 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.

      4. 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…

      5. 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

      6. 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

      7. Artesanía para que jale el
        shaper
      8. 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

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

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

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter
    Comments
    All comments.
    Comments