[Anterior: Formación de Colas y Prioridades de Paquetes] [Contenido] [Siguiente: Marcado de Paquetes]

PF: Reservas (pools) de direcciones y balanceo de carga

Índice de Contenidos

• Introducción
• Reserva de direcciones de NAT
• Balanceo de carga en conexiones entrantes
• Balanceo de carga en tráfico saliente
  • Ejemplo de grupo de reglas

Introducción

Una reserva de direcciones es un grupo de dos o más direcciones cuyo uso comparten un grupo de usuarios. Una reserva de direcciones puede aparecer como la dirección de redirección en las reglas rdr, como la dirección de traducción en las reglas nat y como la dirección de destino en las opciones route-to, reply-to, y dup-to de las reglas de filtrado de paquetes.

Existen cuatro métodos para usar una reserva de direcciones:

• bitmask - incrusta la parte referente a la red que corresponde a la reserva de direcciones en la dirección que se esté modificando (que sería la dirección de origen para las reglas de nat, y la dirección de redirección para las reglas rdr). Ejemplo: si la reserva de direcciones es 192.0.2.1/24 y la dirección que se está modificando es 10.0.0.50, la dirección resultante será 192.0.2.50; si la reserva de direcciones es 192.0.2.1/25 y la dirección que se está modificando es 10.0.0.130, la dirección resultante será 192.0.2.2.
• random - selecciona una de las direcciones de la reserva de forma aleatoria.
• source-hash - usa un resumen criptográfico (hash) de la dirección de origen para determinar qué dirección de la reserva debe usar. Este método asegura que una dirección de origen que venga indicada se asigne siempre a la misma dirección de la reserva. La clave que se le pasa al algoritmo del resumen se puede especificar de modo opcional después de la clave source-hash, en formato hexadecimal o como una cadena. En su modo predeterminado, pfctl(8) generará una clave aleatoria cada vez que se cargue un grupo de reglas.
• round-robin - este método realiza una rotación en secuencia por la reserva de direcciones. Es el método predeterminado en PF, y también el único método permitido cuando se especifica una reserva de direcciones usando una tabla.

A excepción del método round-robin, la reserva de direcciones se debe expresar como un bloque CIDR (Enrutamiento de Inter-Dominios Sin Clase). El método round-robin aceptará más de una dirección individual cuando se use una lista o una tabla.

La opción sticky-address puede ser usada con los tipos de reserva random y round-robin para asegurarse de que una dirección de origen en particular sea siempre asignada a la misma dirección de redirección.

Reserva de direcciones de NAT

Se puede usar una reserva de direcciones como la dirección de traducción en las reglas nat. La dirección de origen de las conexiones se traducirá a la de una de las direcciones de la reserva, basándose en el método escogido. Esto puede ser muy útil en situaciones en las que PF esté realizando NAT para una red muy grande. Dado que el número de conexiones con NAT por dirección de traducción es limitado, al añadir direcciones de traducción adicionales la pasarela de NAT podrá escalar y así servir a un número mayor de usuarios.

En el siguiente ejemplo, se usa una reserva de dos direcciones para traducir los paquetes salientes. Por cada conexión saliente, PF rotará las direcciones según el método round-robin.

nat on $ext_if inet from any to any -> { 192.0.2.5, 192.0.2.10 }

Un problema con este método es que las conexiones sucesivas desde una misma dirección interna no se traducirán siempre a la misma dirección. Esto puede causar interferencias, por ejemplo, cuando se esté navegando por sitios web que realicen seguimientos de los ingresos de los usuarios basándose en la dirección IP. Una alternativa es usar el método source-hash, para que siempre se traduzca cada dirección interna a la misma dirección. Para ello, la reserva de direcciones debe ser un bloque de red CIDR

nat on $ext_if inet from any to any -> 192.0.2.4/31 source-hash

Esta regla de nat usa la reserva de direcciones 192.0.2.4/31 (192.0.2.4 - 192.0.2.5) como la dirección de traducción de los paquetes salientes. Cada dirección interna se traducirá siempre a la misma dirección de traducción, por indicación de la clave source-hash.

Balanceo de carga en conexiones entrantes

Las reservas de direcciones también se pueden usar para el balanceo de carga de las conexiones entrantes. Por ejemplo, se pueden distribuir a través de varios servidores de web las conexiones entrantes al servidor de web:

web_servers = "{ 10.0.0.10, 10.0.0.11, 10.0.0.13 }"

rdr on $ext_if proto tcp from any to any port 80 -> $web_servers \
    round-robin sticky-address

Las conexiones sucesivas se redireccionarán a los servidores de web de acuerdo con el método round-robin, enviando al mismo servidor web las conexiones provenientes del mismo origen. Esta "conexión pegajosa" existirá mientras haya estados que hagan referencia a esta conexión. Una vez que los estados expiren, esta "conexión pegajosa" lo hará también. Las siguientes conexiones provenientes de este host serán redirigidos al siguiente servidor web en el round robin.

Balanceo de carga en tráfico saliente

Las reservas de direcciones se pueden usar en combinación con la opción de filtrado route-to, con el fin de balancear la carga de dos o más conexiones de Internet cuando no se encuentre disponible un protocolo de enrutamiento de múltiples caminos apropiado (como BGP4). Usando route-to con una reserva de direcciones round-robin, se pueden distribuir las conexiones salientes a partes iguales entre múltiples caminos salientes.

Un pieza adicional de información necesaria para esto es la dirección IP del enrutador adyacente en cada conexión de Internet. Esta información se pasa a la opción route-to para controlar el destino de los paquetes salientes.

El siguiente ejemplo balancea el tráfico saliente a través de dos conexiones de Internet:

lan_net = "192.168.0.0/24"
int_if  = "dc0"
ext_if1 = "fxp0"
ext_if2 = "fxp1"
ext_gw1 = "68.146.224.1"
ext_gw2 = "142.59.76.1"

pass in on $int_if route-to \
   { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
   from $lan_net to any keep state

La opción route-to se usa sobre el tráfico que entra en la interfaz interna para especificar las interfaces de red salientes a través de las cuales se balanceará el tráfico, junto con sus respectivas pasarelas. Nótese que la opción route-to debe estar presente en cada una de las reglas de filtrado para las que se balanceará el tráfico. Los paquetes de respuesta se devolverán a la misma interfaz externa por la que salieron (esto es lo que hacen los ISP), y enrutados de vuelta a la red interna como paquetes normales.

Para asegurarse de que los paquetes con una dirección de origen que pertenezca a $ext_if1 sean siempre enrutados a $ext_gw1 (y lo mismo para $ext_if2 y $ext_gw2), hay que incluir las siguientes dos líneas en el grupo de reglas:

pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 \
   to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 \
   to any

Finalmente, también se puede usar NAT en cada una de las interfaces salientes:

nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

Un ejemplo completo que balancea la carga del tráfico saliente sería algo parecido al siguiente:

[Anterior: Formación de Colas y Prioridades de Paquetes] [Contenido] [Siguiente: Marcado de Paquetes]