![[Índice]](../../../images/back.gif){kind=small}
![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Anterior: Anclajes y (Sub-) Conjuntos de Reglas con Nombre] [Contenido] [Siguiente: Pools de Direcciones y Balanceo de Carga]
Poner algo en cola es almacenarlo en orden, a la espera de ser procesado. En una red de ordenadores, cuando se envían paquetes desde un anfitrión, éstos entran en un sistema de colas en el que permanecen hasta ser procesados por el sistema operativo. Entonces el sistema operativo decide qué cola debe procesar y qué paquete o paquetes de dicha cola. El orden en el que el sistema operativo selecciona los paquetes que va a procesar puede afectar al rendimiento de la red. Pongamos por ejemplo un usuario que estuviera ejecutando dos aplicaciones de red: SSH y FTP. Lo ideal sería procesar los paquetes de SSH antes que los de FTP, por la propia naturaleza de SSH; cuando se pulsa una tecla en el cliente SSH se espera obtener una respuesta inmediata, mientras que un retraso de unos pocos segundos en una transferencia por FTP pasa casi inadvertido. Pero, ¿qué ocurriría si el enrutador que maneja estas conexiones procesara una gran parte de paquetes de la conexión de FTP antes de procesar la conexión de SSH? Los paquetes de la conexión de SSH se quedarían en la cola (o incluso serían rechazados por el enrutador si la cola no fuera lo suficientemente grande como para mantener todos los paquetes) y podría parecer que hay retrasos en la sesión de SSH, o que va muy lenta. Al modificar la estrategia de la cola en uso, las diversas aplicaciones, usuarios y ordenadores pueden compartir bastante bien el ancho de banda de la red.
Nótese que el uso de colas sólo es de utilidad para paquetes con dirección de salida, desde dentro. Una vez que un paquete ha llegado a una interfaz desde fuera, es demasiado tarde para ponerlo en una cola debido a que ya habrá consumido el ancho de banda necesario para llegar a la interfaz que acaba de recibirlo. En estos casos la única solución es activar el sistema de colas en el enrutador adyacente o, si el anfitrión que ha recibido el paquete actúa como enrutador, activar el sistema de colas en la interfaz interna desde la que los paquetes salen del enrutador.
El scheduler es lo que decide qué colas hay que procesar y en qué orden deben ser procesadas. Por definición, OpenBSD usa un scheduler tipo FIFO (el primero en entrar es el primero en salir). Una cola FIFO funciona como la cola de un supermercado o la de un banco, en donde el primer producto de la cola es también el primero que se procesa. Según van llegando nuevos paquetes, éstos se van añadiendo al final de la cola. Si la cola se llena, los nuevos paquetes que vayan llegando van siendo bloqueados. Esto se conoce como "tail-drop".
OpenBSD tiene soporte para dos schedulers adicionales:
CBQ (Class Based Queueing) es un algoritmo de formación de colas que divide el ancho de banda de una conexión de red entre varias colas o clases. A cada cola se le asigna un tráfico basándose en la dirección de origen o de destino, el número de puerto, protocolo, etcétera. De forma opcional, se puede configurar una cola para que tome prestado ancho de banda de la cola matriz de la cual origina, si ésta está siendo infrautilizada. A las colas también se les da una prioridad de modo que aquellas que contengan tráfico interactivo, como SSH, puedan tener sus paquetes procesados antes que las colas que contengan tráfico masivo, como FTP.
Las colas CBQ se ordenan de un modo jerárquico. En la parte superior de la jerarquía se encuentra la cola matriz, que define la cantidad total de ancho de banda disponible. Las colas derivadas de ésta se crean bajo la cola matriz, y a cada una de ellas se les puede asignar alguna porción del ancho de banda de la cola matriz. Por ejemplo, se pueden definir las colas como sigue:
En este caso, el ancho de banda total disponible se ha configurado a 2 megabits por segundo (Mbps), que luego se divide entre las tres colas derivadas.
La jerarquía se puede expandir aún más definiendo colas dentro de otras colas. Para dividir el ancho de banda en partes iguales entre varios usuarios y clasificar también el tráfico de éstas con el fin de evitar que ciertos protocolos agoten el ancho de banda de otros, se puede definir una estructura de formación de colas como la siguiente:
Nótese que, en cada nivel, la suma del ancho de banda asignado a cada una de las colas no es superior al ancho de banda asignado a la cola matriz.
Se puede configurar una cola para que tome prestado ancho de banda de la cola de la que origina, si le sobra ancho de banda debido a que no está siendo utilizado por otras colas derivadas. Tomemos como ejemplo una configuración de formación de colas como la siguiente:
Si el tráfico en la cola de ftp excede los 900Kbps y el tráfico en la cola del UsuarioA es menor de de 1Mbps (debido a que la cola de ssh está usando menos tráfico que los 100Kbps asignados), la cola de ftp tomará prestado el ancho de banda sobrante del UsuarioA. De este modo, la cola de ftp podrá usar más ancho de banda del que tiene asignado cuando sufra una sobrecarga. Cuando la cola de ssh incremente su carga, se devolverá el ancho de banda que se ha tomado prestado.
CBQ asigna a cada cola un nivel de prioridad. Las colas con una prioridad más alta tendrán preferencia sobre las colas de prioridad más baja durante una congestión, ya que ambas colas comparten la misma matriz de origen (o sea, siempre que ambas colas se encuentren en la misma rama dentro de la jerarquía). Las colas con una misma prioridad se procesan del modo round-robin. Por ejemplo:
CBQ procesará las colas del UsuarioA y del UsuarioB del modo round-robin; ninguna de las dos colas tendrá preferencia sobre la otra. Al mismo tiempo que esté procesando la cola del UsuarioA, CBQ también procesará las colas que deriven de ésta. En este caso, la cola de ssh tiene una prioridad más alta y obtendrá un trato preferente sobre la cola de ftp si hay congestión en la red. Nótese que no se comparan las prioridades de las colas de ssh y ftp con las colas del UsuarioA y UsuarioB, ya que no están en la misma rama dentro de la jerarquía.
Para una explicación más detallada de la teoría detrás de CBQ, véanse estas Referencias sobre CBQ.
Las PRIQ (Priority Queueing) asignan colas múltiples a una interfaz de red, y dan a cada cola un nivel de prioridad único. Una cola con un nivel de prioridad más alto se procesa siempre antes que una cola con un nivel de prioridad más bajo.
La estructura de formación de colas en PRIQ es estricta, y no se pueden definir colas dentro de otras colas. Se define sólo la cola matriz, en la que se decide la cantidad total de ancho de banda disponible y, a partir de ahí, las «sub-colas» se definen bajo la cola matriz. Consideremos el siguiente ejemplo:
La cola matriz está definida con un ancho de banda de 2Mbps disponible para sí misma, y se han definido tres subcolas. La cola con la prioridad más alta (el número de prioridad más alto) es la que se procesa primero. Una vez que se han procesado todos los paquetes en esa cola, o si la cola estuviera vacía, PRIQ pasa a la cola que tenga el siguiente nivel de prioridad más alto. Dentro de una cola cualquiera, los paquetes se procesan del modo FIFO.
Es importante tener en cuenta que cuando se usa PRIQ hay que planificar las colas con mucho cuidado. Debido a que PRIQ siempre procesa una cola de prioridad más alta antes que otra de prioridad más baja, es posible que una cola de alta prioridad sea la causa de que se retrasen, o incluso se lleguen a bloquear, paquetes en una cola de prioridad más baja si la cola de alta prioridad está recibiendo un flujo constante de paquetes.
RED (Random Early Detection) es un algoritmo que se utiliza para evitar la congestión. Su trabajo es evitar la congestión en la red, asegurándose de que la cola no se llene. Para ello calcula constantemente la longitud media (el tamaño) de la cola y la compara con dos umbrales o límites, un umbral mínimo y otro máximo. Si el tamaño medio de la cola se encuentra por debajo del umbral mínimo, entonces no se bloqueará ningún paquete. Si el tamaño medio se encuentra por encima del umbral máximo, entonces todos los paquetes nuevos que lleguen serán bloqueados. Si el tamaño medio se encuentra entre los valores de los dos umbrales, entonces se bloquearán los paquetes de acuerdo con un cálculo de probabilidad obtenido a raíz del tamaño medio de la cola. En otras palabras, según se va aproximando el tamaño medio de la cola al umbral máximo, se va bloqueando un número cada vez mayor de paquetes. Cuando bloquea los paquetes, RED escoge de qué conexiones bloqueará los paquetes de una forma aleatoria. Las conexiones que usen mayores cantidades de ancho de banda serán las que tengan una probabilidad más alta de que se bloqueen sus paquetes.
RED es muy útil por que evita una situación conocida como sincronización global, explosiones repentinas de tráfico (desbordamientos). La sincronización global se refiere a una pérdida total de caudal debida al bloqueo de paquetes desde varias conexiones al mismo tiempo. Por ejemplo, si la congestión tiene lugar en un enrutador que lleva tráfico para 10 conexiones de FTP y se están bloqueando los paquetes de todas estas conexiones (o de la mayoría de ellas), como ocurre con la formación de colas tipo FIFO, el caudal total caerá de forma significativa. Esta situación no es deseable por que provoca que todas las conexiones de FTP reduzcan su caudal, y también implica que la red ya no puede ser utilizada en su potencia máxima. RED evita esta situación escogiendo de forma aleatoria las conexiones cuyos paquetes bloqueará, en lugar de escogerlas todas. Las conexiones que usen grandes cantidades de ancho de banda tienen una mayor probabilidad de que sus paquetes sean bloqueados. De esta forma se moderará el ritmo de las conexiones que usen un mayor ancho de banda, se evitará la congestión, y no habrán pérdidas significativas en el caudal total. Además de esto, RED también puede manejar explosiones repentinas de tráfico, ya que empieza a bloquear paquetes antes de que se llene la cola. Cuando llega una explosión de tráfico no hay espacio suficiente en la cola para contener los nuevos paquetes.
RED sólo se debería usar cuando el protocolo de transporte fuera capaz de responder a los indicadores de congestión de la red. En la mayoría de casos esto significa que RED se debería usar para poner en cola el tráfico TCP, y no el tráfico UDP o ICMP.
Para una explicación más detallada de la teoría detrás de RED, véanse estas Referencias sobre RED.
ECN (Explicit Congestion Notification) funciona en conjunción con RED para notificar a dos anfitriones que se comuniquen a través de la red sobre cualquier congestión existente en el camino de la comunicación. Para ello permite que RED active un indicador en la cabecera del paquete, en lugar de bloquear el paquete. Si el anfitrión remitente tiene soporte para ECN, entonces puede leer este indicador y moderar el ritmo del tráfico de su red en consecuencia.
Para más información sobre ECN, véase el RFC 3168.
Desde la versión 3.0 de OpenBSD, la implementación ALTQ (Alternate Queueing) de formación de colas ha formado parte del sistema base. Desde OpenBSD 3.3, ALTQ se ha integrado en PF. La implementación de ALTQ de OpenBSD tiene soporte para schedulers de Colas Basadas en Clase (CBQ) y Colas Basadas en Prioridades (PRIQ). También tiene soporte para Pronta Detección Aleatoria (RED) y Notificación Explícita de Congestión (ECN).
Debido a que ALTQ ha sido fusionado con PF, es necesario activar PF para que funcione la formación de colas. Las instrucciones para la activación de PF se pueden encontrar en la sección de Primeros Pasos.
La formación de colas se configura en pf.conf. Existen dos tipos de directivas usadas para configurar la formación de colas:
La sintaxis para la directiva altq on es:
altq on interface scheduler bandwidth bw qlimit qlim \
tbrsize size queue { queue_list }
Por ejemplo,
altq on fxp0 cbq bandwidth 2Mb queue { std, ssh, ftp }activa CBQ en la interfaz fxp0. El ancho de banda total disponible está configurado en 2Mbps. Se han definido tres colas derivadas: std, ssh y ftp.
La sintaxis para la directiva queue es:
queue name [on interface] bandwidth bw [priority pri] [qlimit qlim] \
scheduler ( sched_options ) { queue_list }
queue std bandwidth 50% cbq(default)
queue ssh { ssh_login, ssh_bulk }
queue ssh_login priority 4 cbq(ecn)
queue ssh_bulk cbq(ecn)
queue ftp bandwidth 500Kb priority 3 cbq(borrow red)
Aquí se encuentran activados los parámetros de las colas derivadas anteriormente definidas. A la cola stq se le ha asignado un ancho de banda del 50% del ancho de banda de la cola matriz (ó 1Mbps), y está configurada como la cola predeterminada. La cola ssh define dos colas derivadas: ssh_login y ssh_bulk. A ssh_login se le ha dado una prioridad más alta que a ssh_bulk, y ambas tienen ECN activado. A la cola de ftp se le ha asignado un ancho de banda de 500Kbps y se le ha dado una prioridad de 3. También puede tomar prestado ancho de banda cuando haya disponible ancho de banda adicional. Tiene RED activado.
Para asignar tráfico a una cola se usa la clave queue junto con las reglas de filtrado de PF. Por ejemplo, en un conjunto de reglas de filtrado que contengan una línea como:
pass out on fxp0 from any to any port 22
Los paquetes que coincidan con esa regla pueden ser asignados a una cola específica usando la clave queue:
pass out on fxp0 from any to any port 22 queue ssh
Cuando se usa la clave queue con directivas de bloqueo block, cualquier paquete TCP RST o ICMP resultante que no se pueda alcanzar será asignado a la cola específica.
Nótese que la clasificación de la cola puede tener lugar en una interfaz que no sea la definida por la directiva altq on:
altq on fxp0 cbq bandwidth 2Mb queue { std, ftp }
queue std cbq(default)
queue ftp bandwidth 1.5Mb
pass in on dc0 from any to any port 21 queue ftp
La formación de cola está activada en la interfaz fxp0, pero la clasificación tiene lugar en la interfaz dc0. Si los paquetes que coinciden con la regla pass salen de la interfaz fxp0, pasarán a la cola ftp. Este tipo de formación de colas puede ser muy útil para enrutadores.
Normalmente sólo se da un nombre de cola con la clave queue, pero si se especifica un segundo nombre esa cola se usará para paquetes con un Tipo de Servicio (ToS, Type of Service) de retraso bajo y para paquetes TCP ACK sin carga útil de datos. Un buen ejemplo de esto se encuentra cuando se usa SSH. Las sesiones de ingreso de SSH configuran el ToS para retrasos bajos, mientras que las sesiones de SCP y SFTP no. PF puede usar esta información para poner en la cola paquetes que pertenezcan a una conexión de ingreso en una cola diferente a la de las conexiones que no sean de ingreso. Esto es útil para dar prioridad a los paquetes de conexiones de ingreso sobre los paquetes de transferencia de archivos.
pass out on fxp0 from any to any port 22 queue(ssh_bulk, ssh_login)
Esto asigna los paquetes que pertenecen a las conexiones de ingreso de SSH a la cola ssh_login, y los paquetes que pertenecen a las conexiones de transferencia de archivos de SCP y SFTP a la cola ssh_bulk. En consecuencia, los paquetes de las conexiones de ingreso de SSH serán procesados antes que los de las conexiones de SCP y SFTP, ya que la cola ssh_login tiene una prioridad más alta.
La asignación de paquetes TCP ACK a una cola de prioridad más alta es útil en conexiones asimétricas, o sea aquellas conexiones que tienen anchos de banda de carga y descarga diferentes, como las líneas ADSL. Con una línea ADSL, si se está uilizando al máximo el canal de carga y se inicia una descarga, la descarga sufrirá por que los paquetes TCP ACK que necesita enviar entrarán en congestión cuando intenten pasar a través del canal de carga. Las pruebas realizadas demuestran que para obtener los mejores resultados, el ancho de banda en la cola de carga debe estar configurado con un valor inferior al de la capacidad de la conexión. Por ejemplo, si una línea ADSL tiene un máximo de carga de 640Kbps, al configurar el ancho de banda de la cola matriz, se obtendrán mejores resultados con un valor de 600Kb. La forma para obtener la mejor configuración del ancho de banda es probando varias configuraciones.
Cuando se usa la clave queue con reglas keep state, como:
pass in on fxp0 proto tcp from any to any port 22 flags S/SA \
keep state queue ssh
PF registra la cola en la entrada de la tabla de estado, para que los paquetes que vuelvan desde fxp0 y que coincidan con la conexión de mantenimiento de estado (stateful connection) acaben en la cola ssh. Nótese que, aunque se esté usando la clave queue en una regla que filtra el tráfico entrante, el objetivo es especificar una cola para el tráfico saliente correspondiente; la regla anterior no pone en cola los paquetes entrantes.
[ Alice ] [ Charlie ]
| | ADSL
---+-----+-------+------ dc0 [ OpenBSD ] fxp0 -------- ( Internet )
|
[ Bob ]
En este ejemplo se está usando OpenBSD como pasarela de Internet para una red pequeña casera con tres estaciones de trabajo. La pasarela está realizando filtrado de paquetes y tareas de NAT. La conexión a Internet es a través de una línea ADSL con una velocidad de 2Mbps de descarga y 640Kbps de carga.
La política de formación de colas para esta red es:
A continuación puede verse un conjunto de reglas que cumple esta política de red. Nótese que sólo están presentes aquellas directivas de pf.conf que se aplican directamente a la política anterior; no se muestran las reglas de nat, rdr, las opciones, etcétera.
# activar la formación de colas en la interfaz externa para controlar
# el tráfico que sale hacia Internet; usar el scheduler priq para
# controlar sólo las prioridades; configurar el ancho de banda con
# un valor de 610Kbps para obtener el mejor rendimiento de la cola TCP ACK.
altq on fxp0 priq bandwidth 610Kb queue { std_out, ssh_im_out, dns_out, \
tcp_ack_out }
# definir los parámetros para las colas derivadas.
# std_out - la cola estándar; el tráfico de cualquier regla de
# filtrado que no especifique de forma explícita una
# cola será añadido a esta cola.
# ssh_im_out - tráfico interactivo de SSH y varios mensajes instantáneos.
# dns_out - requerimientos de DNS.
# tcp_ack_out - paquetes TCP ACK sin carga útil de datos.
queue std_out priq(default)
queue ssh_im_out priority 4 priq(red)
queue dns_out priority 5
queue tcp_ack_out priority 6
# activar la formación de colas en la interfaz interna para controlar
# el tráfico entrante procedente de Internet; usar el scheduler
# cbq para controlar el ancho de banda; el ancho de banda máximo
# es de 2Mbps.
altq on dc0 cbq bandwidth 2Mb queue { std_in, ssh_im_in, dns_in, bob_in }
# definir los parámetros para las colas derivadas.
# std_in - la cola estándar; el tráfico de cualquier regla de
# filtrado por debajo que no especifique de forma explícita
# una cola será añadido a esta cola.
# ssh_im_in - tráfico interactivo de SSH y varios mensajes instantáneos.
# dns_in - respuestas de DNS.
# bob_in - ancho de banda reservado para la estación de Bob;
# permitirle que tome prestado.
queue std_in cbq(default)
queue ssh_im_in priority 4
queue dns_in priority 5
queue bob_in bandwidth 80Kb cbq(borrow)
# ... en la sección de filtrado de pf.conf ...
alice = "192.168.0.2"
bob = "192.168.0.3"
charlie = "192.168.0.4"
local_net = "192.168.0.0/24"
ssh_ports = "{ 22 2022 }"
im_ports = "{ 1863 5190 5222 }"
# reglas de filtrado para fxp0 entrante
block in on fxp0 all
# reglas de filtrado para fxp0 saliente
block out on fxp0 all
pass out on fxp0 inet proto tcp from (fxp0) to any flags S/SA \
keep state queue(std_out, tcp_ack_out)
pass out on fxp0 inet proto { udp icmp } from (fxp0) to any keep state
pass out on fxp0 inet proto { tcp udp } from (fxp0) to any port domain \
keep state queue dns_out
pass out on fxp0 inet proto tcp from (fxp0) to any port $ssh_ports \
flags S/SA keep state queue(std_out, ssh_im_out)
pass out on fxp0 inet proto tcp from (fxp0) to any port $im_ports \
flags S/SA keep state queue(ssh_im_out, tcp_ack_out)
# reglas de filtrado para dc0 entrante
block in on dc0 all
pass in on dc0 from $local_net
# reglas de filtrado para dc0 saliente
block out on dc0 all
pass out on dc0 from any to $local_net
pass out on dc0 proto { tcp udp } from any port domain to $local_net \
queue dns_in
pass out on dc0 proto tcp from any port $ssh_ports to $local_net \
queue(std_in, ssh_im_in)
pass out on dc0 proto tcp from any port $im_ports to $local_net \
queue ssh_im_in
pass out on dc0 from any to $bob queue bob_in
|
( Dept IT ) [ PC del Jefe ]
| | T1
--+----+--------+------- dc0 [ OpenBSD ] fxp0 -------- ( Internet )
| fxp1
[ COMP1 ] [ WWW ] /
| /
--+----------'
En este ejemplo, el anfitrión de OpenBSD actúa como cortafuegos para la red de una compañía. La compañía tiene un servidor de WWW en la «zona desmilitarizada» (DMZ) de su red, en el que los clientes cargan sus sitios web mediante FTP. El departamento de Informática, IT, tiene su propia subred conectada a la red principal, y el jefe tiene un PC en su escritorio que usa para correo electrónico y para navear por Internet. La conexión a Internet es a través de una línea T1 a 1.5Mbps en ambas direcciones. El resto de los segmentos de la red usan Fast Ethernet (100Mbps).
El administrador de la red ha decidido aplicar la siguiente política:
A continuación puede verse el conjunto de reglas que cumple esta política de red. Nótese que sólo están presentes aquellas directivas de pf.conf que se aplican directamente a la política anterior; no se muestran las reglas de nat, rdr, las opciones, etcétera.
# activar la formación de colas en la interfaz externa para poner
# en cola a los paquetes salientes hacia Internet; usar el
# scheduler cbq para que se pueda controlar la utilización
# de ancho de banda de cada cola; el ancho de banda saliente
# máximo es de 1.5Mbps.
altq on fxp0 cbq bandwidth 1.5Mb queue { std_ext, www_ext, boss_ext }
# definir los parámetros para las colas derivadas.
# std_ext - la cola estándar; también la cola predeterminada
# para el tráfico saliente en fxp0.
# www_ext - cola contenedora para colas del servidor de WWW;
# limitada a 500Kbps.
# www_ext_http - tráfico http desde el servidor de WWW.
# www_ext_misc - todo el tráfico no http desde el servidor
# de WWW.
# boss_ext - tráfico entrante desde el PC del jefe.
queue std_ext cbq(default)
queue www_ext bandwidth 500Kb { www_ext_http, www_ext_misc }
queue www_ext_http priority 3 cbq(red)
queue www_ext_misc priority 1
queue boss_ext priority 3
# activar la formación de colas en la interfaz interna para
# controlar el tráfico entrante desde Internet o desde la DMZ;
# usar el scheduler cbq para controlar el ancho de banda de cada
# cola; el ancho de banda en esta interfaz está configurado al
# máximo; el tráfico entrante desde la DMZ podrá usar todo este
# ancho de banda, mientras que el tráfico entrante desde Internet
# tendrá un límite de 1.0Mbps (por que se han ubicado 0.5Mbps
# (500Kbps) para fxp1).
altq on dc0 cbq bandwidth 100% queue { net_int, www_int }
# definir los parámetros para las colas derivadas.
# net_int - cola contenedora para el tráfico desde Internet;
el ancho de banda es de 1.0Mbps.
# std_int - la cola estándar; también la cola predeterminada
# para el tráfico saliente en dc0.
# it_int - tráfico hacia la red del Dept IT.
# boss_int - tráfico hacia el PC del jefe.
# www_int - tráfico desde el servidor de WWW en la DMZ.
queue net_int bandwidth 1.0Mb { std_int, it_int, boss_int }
queue std_int cbq(default)
queue it_int bandwidth 500Kb cbq(borrow)
queue boss_int priority 3
queue www_int cbq(red)
# activar la formación de colas en la interfaz de DMZ para
# controlar el tráfico destinado al servidor de WWW;
# se usará cbq en esta interfaz ya que es necesario un control
# detallado del ancho de banda; el ancho de banda en esta interfaz
# está configurado al máximo; el tráfico desde la red interna
# podrá usar todo este ancho de banda, mientras que el
# tráfico desde Internet estará limitado a 500Kbps.
altq on fxp1 cbq bandwidth 100% queue { internal_dmz, net_dmz }
# definir los parámetros para las colas derivadas.
# internal_dmz - tráfico desde la red interna.
# net_dmz - cola contenedora para tráfico desde Internet.
# net_dmz_http - tráfico http.
# net_dmz_misc - todo el tráfico no http; es la cola predeterminada
queue internal_dmz # no necesita ninguna configuración especial
queue net_dmz bandwidth 500Kb { net_dmz_http, net_dmz_misc }
queue net_dmz_http priority 3 cbq(red)
queue net_dmz_misc priority 1 cbq(default)
# ... en la sección de filtrado de pf.conf ...
main_net = "192.168.0.0/24"
it_net = "192.168.1.0/24"
int_nets = "{ 192.168.0.0/24, 192.168.1.0/24 }"
dmz_net = "10.0.0.0/24"
boss = "192.168.0.200"
wwwserv = "10.0.0.100"
# denegación predeterminada
block on { fxp0, fxp1, dc0 } all
# reglas de filtrado para fxp0 entrante
pass in on fxp0 proto tcp from any to $wwwserv port { 21, \
> 49151 } flags S/SA keep state queue www_ext_misc
pass in on fxp0 proto tcp from any to $wwwserv port 80 \
flags S/SA keep state queue www_ext_http
# reglas de filtrado para fxp0 saliente
pass out on fxp0 from $int_nets to any keep state
pass out on fxp0 from $boss to any keep state queue boss_ext
# reglas de filtrado para dc0 entrante
pass in on dc0 from $int_nets to any keep state
pass in on dc0 from $it_net to any queue it_int
pass in on dc0 from $boss to any queue boss_int
pass in on dc0 proto tcp from $int_nets to $wwwserv port { 21, 80, \
> 49151 } flags S/SA keep state queue www_int
# reglas de filtrado para dc0 saliente
pass out on dc0 from dc0 to $int_nets
# reglas de filtrado para fxp1 entrante
pass in on fxp1 proto { tcp, udp } from $wwwserv to any port 53 \
keep state
# reglas de filtrado para fxp1 saliente
pass out on fxp1 proto tcp from any to $wwwserv port { 21, \
> 49151 } flags S/SA keep state queue net_dmz_misc
pass out on fxp1 proto tcp from any to $wwwserv port 80 \
flags S/SA keep state queue net_dmz_http
pass out on fxp1 proto tcp from $int_nets to $wwwserv port { 80, \
21, > 49151 } flags S/SA keep state queue internal_dmz
|
[Anterior: Anclajes y (Sub-) Conjuntos de Reglas con Nombre] [Contenido] [Siguiente: Pools de Direcciones y Balanceo de Carga]
www@openbsd.org