29.5. Puenteado

Escrito por Steve Peterson.

29.5.1. Introducción

Algunas veces resulta útil dividir una red física (como por ejemplo un segmento Ethernet) en dos segmentos de red separados, sin tener que crear subredes IP y sin utilizar una pasarela para comunicar ambos segmentos. El dispositivo que realiza esta función se denomina bridge. Un sistema FreeBSD con dos interfaces de red puede actuar como un bridge o puente entre ambas.

El bridge funciona de tal forma que aprende las direcciones de la capa MAC (direcciones Ethernet) de los nodos que se encuentran conectados a cada interfaz de red de tal forma que sólo se reenvía tráfico entre los segmentos de red cuando las direcciones fuente y destino se encuentran separadas en segmentos distintos.

En varios aspectos se puede comparar un bridge con un switch de pocos puertos.

29.5.2. Situaciones donde el puenteado resulta adecuado

Existen al menos dos situaciones típicas donde se puede utilizar la funcionalidad proporcionada por los bridges.

29.5.2.1. Tráfico de gran volumen en un segmentos de red

La primera situación surge cuando nos encontramos con un segmento de red congestionado pero por las razones que sean no queremos subdividir la red e interconectar las nuevas subredes mediante un route.

Vamos a considerar un ejemplo de un periódico donde los departamentos editoriales y de producción utilizan la misma subred. Los usuarios de la editorial utilizan el servidor A como servidor de ficheros y los de producción utilizan el servidor B. Se Se utiliza una red Ethernet para conectar ambos departamentos y se ha detectado que la alta utilización del enlace está ralentizando el funcionamiento de la red.

Si los usuarios de la editorial pudieran agregarse en un segmento de red mientras que los usuarios de producción se localizaran en otro se podrían conectar ambos segmentos mediante un bridge. Sólo se utilizará el bridge para encaminar tráfico de red destinado a interfaces que se encuentren en el otro lado del bridge, reduciendo de esta forma la congestión en cada nuevo segmento.

29.5.2.2. Cortafuegos de filtrado/conformación de tráfico

La segunda situación típica se produce cuando se necesita un cortafuegos pero no la Traducción de Direcciones de Red (NAT).

A continuación se muestra un ejemplo. Una pequeña compañía se comunica con su ISP utilizando DSL o ISDN. Dicha compañía posee 13 13 direcciones IP globalmente accesibles delegadas por su ISP y tiene 10 ordenadores en funcionamiento. En esta situación un un cortafuegos basado en un router resulta difícil debido a la distribución del espacio de direccionamiento disponible (subnetting).

Un cortafuegos implementado sobre un bridge se puede utilizar en el camino de bajado desde el ISP hasta las oficinas de la compañía sin necesidad de tener en cuenta ningún aspecto relacionado con la distribución de las direcciones IP.

29.5.3. Configuración de un bridge

29.5.3.1. Selección de la interfaz de red

Un bridge necesita al menos dos tarjetas de red situadas en dos segmentos de red para su funcionamiento. Por desgracia no todas las interfaces de red pueden usarse para el puenteo. Consulte bridge(4), ahín encontrará más información sobre qué tarjetas puede usar.

Por favor, instale y pruebe las dos tarjetas de red antes de continuar.

29.5.3.2. Cambios en la configuración del núcleo

Para activar el soporte de bridging en el núcleo añada

options BRIDGE

al fichero de configuración del núcleo y recompile el kernel.

29.5.3.3. Soporte de cortafuegos

Si se desea utilizar el bridge como un cortafuegos, se debe añadir además la opción IPFIREWALL. Lea el capílo de firewalls para obtener información general sobre cómo configurar el bridge para que actúe además como cortafuegos.

Si además queremos que los paquetes que no sean IP (por ejemplo paquetes ARP) puedan atravesar el bridge deberemos añadir la opción IPFIREWALL_DEFAULT_TO_ACCEPT. Tenga en cuenta opción modifica el comportamiento del cortafuegos de tal forma que por defecto aceptará cualquier paquete. Hay que tener cuidado para asegurarse de que el comportamiento esperado del cortafuegos, que reside en el conjunto de reglas que se hayan definido, no se vea afectado por este cambio.

29.5.3.4. Soporte de conformado de tráfico

Si se quiere utilizar el bridge como un conformador de tráfico, es decir, como un elemento capaz de adaptar los distintos flujos según determinados patrones, se debe añadir la opción DUMMYNET a la configuración del núcleo. Se ruega consultar dummynet(4) para obtener más información al respecto.

29.5.4. Cómo activar el bridge

Añadir la línea:

net.link.ether.bridge=1

en /etc/sysctl.conf para habilitar el soporte de bridging en tiempo de ejecución y la línea:

net.link.ether.bridge_cfg=if1,if2

Para activar el bridging en las interfaces especificadas (sustituya if1 y if2 con los nombres de sus interfaces de red). Si deseamos filtrar los paquetes puenteados utilizando ipfw(8), debemos añadir también:

net.link.ether.bridge_ipfw=1

En FreeBSD 5.2-RELEASE y posteriores, se debe utilizar las siguientes líneas en lugar de las anteriores:

net.link.ether.bridge.enable=1
net.link.ether.bridge.config=if1,if2
net.link.ether.bridge.ipfw=1

29.5.5. Información adicional

Si queremos ser capaces de conectarnos al bridge mediante telnet(1) se puede asignar una dirección IP a una de las tarjetas de red del bridge. Por amplio consenso se considera una mala idea asignar más de una dirección IP al bridge.

Si poseemos varios bridges en nuestra red sólamente puede existir un único camino entre cualesquiera dos máquinas de nuestra red. Técnicamente hablando esto significa que no existe soporte para gestión de enlace mediante mecanismos basados en árboles de recubrimiento mínimos (spanning tree).

Un bridge puede añadir latencia a los tiempos de respuesta de la orden ping(8), especialmente cuando el tráfico tiene que viajar de un segmento de red al otro.

Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Si tiene dudas sobre FreeBSD consulte la documentación antes de escribir a la lista <questions@FreeBSD.org>.

Envíe sus preguntas sobre la documentación a <doc@FreeBSD.org>.