Obtenga la utilidad de configuración de puentes
ftp://shadow.cabi.net/pub/Linux/BRCFG.tgz de las páginas
personales de Alan Cox. Esta es la misma referencia que encuentra en el
documento de Chris. No me había dado cuenta de que era una URL de un ftp y no
de http ...
Lea el Multiple Ethernet HOWTO,
ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/mini/Multiple-Ethernet
si quiere asesoramiento sobre cómo configurar más de una tarjeta de red en su
máquina.
En el BootPrompt HOWTO
ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/BootPrompt-HOWTO podrá
encontrar aún más detalles de la magia involucrada en el proceso de arranque.
Puede escapar de la lectura del Redes-En-Linux-Como
http://www.insflug.org/documentos/Redes-En-Linux-Como/. Es una
lectura bien larga, y tendrá que seleccionar de ella los detalles que necesite.
El material de lectura anterior le enseñará lo que necesita para preparar el
kernel para reconocer un segundo dispositivo ethernet en el arranque, por
ejemplo añadiendo los siguiente a /etc/lilo.conf, y volviendo a
ejecutar lilo:
append = "ether=0,0,eth1"
Observe el "eth1". "eth0" es la primera tarjeta. "eth1" es la segunda tarjeta. Puede añadir los parámetros de arranque que quiera a la línea que lilo le ofrece. Esto es para tres tarjetas:
linux ether=0,0,eth1 ether=0,0,eth2
Yo uso loadlin para arrancar mi kernel desde DOS:
loadlin.exe c:\vmlinuz root=/dev/hda3 ro ether=0,0,eth1 ether=0,0,eth2
Fíjese que este truco obliga al kernel a sondear direcciones en el arranque.
Esto no ocurrirá si carga los controladores ethernet como módulos (por
seguridad, ya que la orden de sondeo no puede ser determinada) así que si usa
módulos tendrá que añadir los parámetros de IRQ y puerto apropiados para el
controlador específicamente en su fichero /etc/conf.modules. Yo por
lo menos tengo
alias eth0 3c509
alias eth1 de620
options 3c509 irq=5 io=0x210
options de620 irq=7 bnc=1
Puede averiguar está usando módulos mediante ps -aux para ver si se
está ejecutando kerneld y comprobando si hay archivos .o en
algún subdirectorio del directorio /lib/modules. Necesita el que el
directorio se llame como le diga uname -r. Si tiene kerneld
y/o tiene algún archivo como loquesea.o, edite
/etc/conf.modules y lea cuidadosamente la página del manual de
depmod.
Tenga en cuenta también que hasta hace poco (kernel 2.0.25) el
controlador 3c509 no podía ser usado para más de una tarjeta si era
usado como módulo. He visto un parche por ahí que soluciona esto. Puede que
esté integrado en el kernel cuando lea este documento.
Recompile el kernel con bridging activado.
CONFIG_BRIDGE=y
Yo compilé con el cortafuegos, reenvío IP, enmascaramiento y lo demás activado. Esto es sólo si quiere cortafuegos...
CONFIG_FIREWALL=y
CONFIG_NET_ALIAS=y
CONFIG_INET=y
CONFIG_IP_FORWARD=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_VERBOSE=y
CONFIG_IP_MASQUERADE=y
En realidad no necesita todo esto. Lo que sí necesita, además de esto, es la configuación normal de la red:
CONFIG_NET=y
y no creo que necesite preocuparse de ninguna de las demás opciones de red. Yo tengo opciones sin compilar dentro del kernel disponibles como módulos que puedo añadir más tarde.
Instale el nuevo kernel, vuelva a ejecutar lilo y rearranque con el
kernel nuevo. ˇNo debería haber cambios hasta ahora!
Chris dice que un puente no debería tener dirección IP, pero esta no es la configuración que describo aquí.
Seguro que querrá la máquina para conectarse a la red, así que va a necesitar
una dirección y necesita asegurarse de que tiene el dispositivo de loopback
activado de la manera normal, de tal forma que sus programas puedan hablar
con los lugares que se supone deberían poder hablar. Si la dirección loopback
no está activada, el servicio de resolución de nombres, y otros podrían no
funcionar adecuadamente. Vea el Redes-En-Linux-Como (
http://www.insflug.org/documentos/Redes-En-Linux-Como/), aunque la
configuración estándard debería haber hecho esto:
ifconfig lo 127.0.0.1
route add -net 127.0.0.0
Va a necesitar dar direcciones a sus tarjetas de red. He modificado el
archivo /etc/rc.d/rc.inet1 de mi slackware (3.x) para
configurar dos tarjetas y usted debería buscar en su archivo de configuración
la manera de doblar o triplicar el número de instrucciones. Suponga que usted
tiene direcciones en
192.168.2.100
(esto es en el espacio de direcciones reservado para redes privadas, pero no se preocupe, no va a hacerle daño a nadie si usa esta dirección por error) así que probablemente ya tenga una línea como
ifconfig eth0 192.168.2.100 netmask 255.255.255.0 metric 1
en su configuración. Lo primero que probablemente quiera hacer es limitar el espacio de direcciones que alcance esta tarjeta a la mitad, de tal forma que pueda en algún momento puentear o hacer cortafuegos con las dos mitades. Añada pues una línea que reduzca la máscara para direccionar un número menor de máquinas:
ifconfig eth0 netmask 255.255.255.128
Intente esto también. Limita a la tarjeta a, como mucho, las direcciones entre
.0 y .127.
Ahora puede configurar su segunda tarjeta en la otra mitad del espacio de
direcciones local. Asegúrese que nadie está usando ya las direcciones. Por
simetria, yo lo pongo en 228=128+100. Cualquier dirección funcionará
tan pronto como no esté en la máscara de la otra tarjeta. Bueno, seguramente.
Evite direcciones especiales como .0, .1, .128 etc.
a no ser que de verdad sepa qué hace.
ifconfig eth1 192.168.2.228 netmask 255.255.255.128 metric 1
Esto evita que la segunda tarjeta direccione entre .128 and .255.
Aquí es donde tengo que anunciar las salvedades en el esquema de puenteado y
cortafuegos: no puede hacer cortafuegos con paquetes que no se ruten. No hay
rutas, no hay cortafuegos. Al menos esto es verdad en el kernel 2.0.30
y en kernel más recientes. Los filtros para el cortafuegos están estrechamente
relacionados con el código de reenvío IP.
Esto no significa que no pueda hacer puentes. Puede hacer un puente entre dos tarjetas y hacer cortafuegos con ellas desde una tercera. Puede tener dos tarjetas y hacer un cortafuegos con ellas contra una dirección IP externa como un router cercano, siempre y cuando el router sea rutado por usted hasta una de las tarjetas.
En otras palabras, ya que voy a hacer un cortafuegos quiero controlar con precisión el destino físico de algunos paquetes.
Tengo la pequeña red de máquinas conectadas a un concentrador que cuelga de eth0, por lo que configuro ahí una red:
route add -net 192.168.2.128 netmask 255.255.255.128 dev eth0
El .128 sería .0 si tuviera una clase C completa allí. No la
tengo, por definición, ya que he partido a la mitad el espacio de direcciones.
El dev eth0 es innecesario porque las direcciones de las tarjetas caen
en la máscara, pero podría ser necesario en su caso. Uno puede necesitar más de
una tarjeta en esta subred (127 máquinas en un segmento) pero estas tarjetas
serían puenteadas bajo la misma máscara de red, de tal forma que aparecen como
una ante el código de rutado.
En la otra tarjeta tengo un cable directo a un router grande en el que confío.
cliente 129
__ | __
cliente 1 \ .0 .128 | / red 1
cliente 2 --- Hub - eth0 - Kernel - eth1 - Hub - Router --- red 2
cliente 3 __/ .100 .228 .2 | \__ red 3
|
cliente 254
Yo pongo la dirección del router a la tarjeta como una ruta fija («estática») porque si no caería entre la máscara de las primeras tarjetas y el kernel se confundiría al mandar paquetes al router grande. Voy a hacer cortafuegos con estos paquetes, y esta es otra razón por la que rutarlos específicamente.
route add 192.168.2.2 dev eth1
No los necesito, ya que no tengo más máquinas en esa mitad del espacio de direcciones, pero declaro una red también en la segunda tarjeta. Separar mis interfaces en dos grupos mediante el rutado me permitirá hacer unas reglas de cortafuegos muy estrictas si lo necesito, pero puede escapar con mucho menos rutado específico que el aquí expuesto.
route add -net 192.168.2.128 netmask 255.255.255.128 dev eth1
Necesito también enviar todos los paquetes no locales al mundo, así que le diré al kernel que se los mande al router grande.
route add default gw 192.168.2.2
La mayoría de lo que ha visto es configuración estándard de la red, pero estamos puenteando, así que también tenemos que escuchar paquetes en ambas tarjetas que no se dirijan a nosotros. Lo que sigue debe ir al fichero de configuración de red.
ifconfig promisc eth0
ifconfig promisc eth1
La página del manual dice que allmulti equivale a promisc,
pero a mi no me funcionó.
Una cosa de la que me di cuenta era que tuve que poner al menos la segunda tarjeta en un modo en el que respondiera a las preguntas del router grande sobre qué máquinas escondía en mi red local..
ifconfig arp eth1
Por si acaso, le hice lo mismo a la otra tarjeta.
ifconfig arp eth0
Active el puenteo, también en su archivo de configuración de la red:
brcfg -enable
Debe haber probado esto extensivamente en pruebas reales, por supuesto. El configurador del puente mostrará algunos números. Puede experimentar con conectando y desconectando los puertos uno cada vez.
brcfg -port 0 -disable/-enable
brcfg -port 1 -disable/-enable
Para comprobar el estado en cualquier momento, ejecute
brcfg
sin parámetros. Verá cómo el puente escucha, aprende y hace el reenvío. (No entiendo por qué el código repite las mismas direcciones físicas en mis dos tarjetas, pero no importa, el HOWTO de Chris dice que es así)
Si todo funciona como es debido, pruebe su propio archivo de comandos de configuración tirando abajo ambas tarjetas y luego ejecutándolo:
ifconfig eth0 down ifconfig eth1 down
/etc/rc.d/rc.inet1
Con un poco de suerte los varios subsistemas (NFS, ypbind,
etc.) ni se enterarán. ˇNo intente esto a no ser que esté delante del
teclado!
Si quiere ser aún más cuidadoso, mate tantos demonios primero como pueda, y
desmonte los directorios nfs. Lo peor que puede pasar es que tenga que resetear
en modo monousuario (pasando el parámetro single a lilo o
loadlin), y deshacer los cambios antes de rearrancar con las cosas
como estaban antes de que empezara.
Verifique que hay tráfico distinto en cada interfaz:
tcpdump -i eth0
# (en una ventana)
tcpdump -i eth1
# (en otra ventana)
Debe acostumbrarse a usar tcpdump para buscar cosas que no deberían
estar pasando o que no pasan y deberían.
Por ejemplo, busque los paquetes que pasan por el puente a la segunda tarjeta
desde la red interna. Aquí busco paquetes de la máquina con dirección
.22:
tcpdump -i eth1 -e host 192.168.2.22
Ahora le mando un ping desde la máquina .22 al router.
Debería ver el paquete según informe de tcpdump.
En esta fase tiene un puente listo que también tiene dos direcciones de red. Compruebe que puede hacer ping desde fuera y dentro de su red local, y que puede hacer telnet y ftp entre el exterior y el interior.