Para acceso a Internet en una Red local
- Fundamentación. Marco
teórico - Instalación del S.O.
Linux, distribución red HAT. - Configuración
NAT - Permutación Shaper –
Wondershaper – CBQ - Bibliografía
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 InternetEl 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.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 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.- 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. - NAT
- Reglas
- Funcionamiento
- Marco teórico
- 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)
- 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.
- Modos de implementación
- IPFilter
- NetFilter
- Hardware
- IPFilter
- Propio de la familia
BSD - Escrito por Darren Reed
- Incluido en NetBSD, FreeBSD
- Licencia tipo BSD
- 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
- Hardware
Incrustado en la circuitería de algunos de los sig.
dispositivos.
- Routers de banda ancha
- Cable routers
- 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).
- 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.
- Filtrado
- IPFilter
- 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
- pass in on x10 proto tcp from 192.168.2.46/32 to
- 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 pueden formar nuevos grupos y toda regla puede ser
- Se alimentan estas reglas al programa de
interacción - ipf –f ipf.rules
- 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.
- Redirectdirección y puerto a
- El caso mas ordinario:
- map 192.268.27.0/24 to 132.248.28.164 portmap
auto
- map 192.268.27.0/24 to 132.248.28.164 portmap
- Se alimentan las reglas al programa ipnat
- ipnat –f ipnat.rules
- 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
- iptables –A OUTPUT –j REJECT –p
- iptables
Existen 3 cadenas predefinidas incrustadas en netfilter:
- INPUT Trabaja con paquetes con destino en el servidor
local. - FORWARD Trabaja con paquetes que van de una interfaz o
otra. - 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:
- POSTROUTING
- 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
- 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.
-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.- Comandos
- 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 | |||
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 |
|
- 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.
- 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.
- 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
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).- Disciplina de colas
Es aquella disciplina de colas que no admite una
subdivisión interna que pueda ser configurada
por el usuario. - 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. - Clases y Disciplinas de colas con clases
- 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.- Disciplinas de colas para la gestión de
tráfico - 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
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 IPBinario
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_fastPara ver el gráfico
seleccione la opción "Descargar" del menú
superiorLa 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.- PFIFO_FAST
- 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:
- 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. - 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. - 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.
- 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.
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.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.- Parámetros de las disciplinas de
colas PRIO
- Parámetros de las disciplinas de
- Disciplina de colas PRIO
- 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 |
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.
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.- Parámetros CBQ para ajustar la
regulación del ancho de banda.
- Parámetros CBQ para ajustar la
- 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.
- 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.
- 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.
- 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
- 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
- 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.
- 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.
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.- Instalación
del S.O. Linux, distribución Red Hat. - 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.
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.- 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. - 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. - 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. - DNAT
- 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.
- 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
- 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.
- 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
- 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.
- 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:
- minutos 0-59
- horas 0-23
- días del mes 1-31
- meses 1-12
- 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
- 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.
- 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.
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.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- Creación de ligas
simbólicasinsmod
/lib/modules/2.4.20-8/kernel/drivers/net/shaper.oinsmod
/lib/modules/2.4.20-8/kernel/drivers/net/shaper1.oAl 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 - 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. - Fijación a la interface de
redEl 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 shaper0ip route del default via 192.168.150.2 dev
eth0ip route add default via 192.168.150.2 dev
shaper0ip address add 172.16.200.34/24 brd
172.16.200.255 dev shaper1ip route flush cache
Se refresca el cache de
rutas… - Levantamiento del shaper y
configuración de rutasAhora 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_forwardecho "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 - Levantamiento de módulos para el
NATTeó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 eth0ip address del 172.16.200.34/24 brd
172.16.200.255 dev eth1ip route flush cache
ip address add 192.168.150.244/24 brd
192.168.150.255 dev eth0ip route del default via 192.168.150.2 dev
shaper0ip route add default via 192.168.150.2 dev
eth0ip address add 172.16.200.34/24 brd
172.16.200.255 dev eth1ip route flush cache
Ahora colocar el gateway por default
nuevamenteip route del default via 192.168.150.2 dev
eth0ip route add default via 192.168.150.2 dev
shaper0ip route flush cache
- Artesanía para que jale el
shaper - Agrupando scripts
- 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:
- Se edita el archivo rc.local quitando o comentado
/etc/rc.d/./ip_tables y agregándole al final:
/etc/rc.d/./spr - 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
ip link set shaper0 up
ip link set shaper1 up
ip address add 192.168.150.244/24 brd
192.168.150.255 dev shaper0ip route del default via 192.168.150.2 dev
eth0ip route add default via 192.168.150.2 dev
shaper0ip address add 172.16.200.34/24 brd 172.16.200.255
dev shaper1ip route flush cache
- 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
- ip_modulos lleva:
echo "1" >
/proc/sys/net/ipv4/ip_forwardecho "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 - s_ip_reglas lleva:
ip address del 192.168.150.244/24 brd
192.168.150.255 dev eth0ip address del 172.16.200.34/24 brd 172.16.200.255
dev eth1ip route flush cache
- Qrutas lleva:
ip address add 192.168.150.244/24 brd
192.168.150.255 dev eth0ip route del default via 192.168.150.2 dev
shaper0ip route add default via 192.168.150.2 dev
eth0ip address add 172.16.200.34/24 brd 172.16.200.255
dev eth1ip route flush cache
- Prutas lleva
- 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:
shapecfg speed shaper0 8000
shapecfg speed shaper1 8000
- s8
shapecfg speed shaper0 16000
shapecfg speed shaper1 16000
- s16
shapecfg speed shaper0 32000
shapecfg speed shaper1 32000
- s32
shapecfg speed shaper0 64000
shapecfg speed shaper1 64000
- s64
shapecfg speed shaper0 128000
shapecfg speed shaper1 128000
- s128
shapecfg speed shaper0 256000
shapecfg speed shaper1 256000
- s256
shapecfg speed shaper0 512000
shapecfg speed shaper1 512000
- s512
- sInsano
shapecfg speed shaper0 1024000
shapecfg speed shaper1 1024000
- Comentarios
- 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. - La velocidad puede ser diferente entre los shapers,
depende de lo que tratemos de hacer. - Se hicieron scripts similares para el caso del NAT
exclusivamente, para poder alternar y/o probar ambas
cosas.
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.gzLa 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'
firstexit
- Ajustes
- 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.
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.htbY para arrancarlo o detenerlo :
./wshaper start
./wshaper stop
- Arranque
- Comentarios
- Se encontró al wondershaper realmente
fácil de ajustar, pues se limita solo el caudal de la
interfaz con salida a Internet. - Los valores introducidos en la velocidad son
aproximados, encontrándose que variaban de 0 a un
10%. - Cuando un PC con alta prioridad, necesita más
ancho de banda, lo toma de las PC’s marcadas para una
baja prioridad. - En el script original la línea :
# low priority destination ports
NOPRIOPORTSRC=
Hay que corregirla a NOPRIOPORTDST=
- Cuando cargamos el wondershaper (o al cbq), ignora las
reglas del iptables donde se bloquean a determinadas
IP’s.
- 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.
- Cada archivo se debe de empezar con el nombre
cbq- - Luego un identificador que puede estar en el rango
[0002-FFFF] - punto . para separar el número del nombre del
shaper - 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>
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.- Parámetros de dispositivo
RATE es el ancho de banda asignado a la clase, se
pueden utilizar KBit, MBit y BPSWEIGHTes 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. - 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) - 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) - Parámetros de SFQ qdisc
- 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)
(1) Para ver la monografía completa seleccione la
opción "Descargar" del menú
superior
Benigno Martínez Carranza