Interesante
- Cómo configurar un servidor NFS
Configurar un servidor NFS.
Introducción.
NFS, acrónimo de Network File System, es un popular protocolo utilizado para compartir volúmenes entre máquinas dentro de una red de manera transparente, más comúnmente utilizado entre sistemas basados sobre UNIX®. Es útil y fácil de utilizar, sin embargo no en vano es apodado cariñosamente como "No File Security". NFS no utiliza un sistema de contraseñas como el que tiene SAMBA, solo una lista de control de acceso determinada por direcciones IP o nombres. Es por esto que es importante que el administrador de la red local o usuario entienda que un servidor NFS puede ser un verdadero e inmenso agujero de seguridad si este no es configurado apropiadamente e implementado detrás de un contrafuegos o firewall.Personalmente, solo recomiendo utilizar NFS dentro de una red local detrás de un contrafuegos o firewall que permita el accesos solo a las máquinas que integren la red local, nunca para compartir sistemas de archivos a través de Internet. Al no contar con un sistema de autenticación por contraseñas, es un servicio susceptible del ataque de algún cracker. SAMBA es un mucho mejor y más seguro protocolo para compartir sistemas de archivos.
Procedimientos.
Teniendo en cuenta los aspectos de seguridad mencionados, es importante que siga los procedimientos descritos a continuación al pie de la letra, y que posteriormente se comprometa también consultar a detalle la documentación incluida en el paquete nfs-utils, ya que este le proporcionará información adicional y completa sobre aspectos avanzados de configuración y utilización.
Configurando el servidor NFS.
Se requiere tener instalados nfs-utils y portmap. Preguntaremos al sistema si estos están instalados con la siguiente línea de comando:
rpm -q nfs-utils portmap
Lo cual debe de regresar algo como lo siguiente:
nfs-utils-0.3.1-13.7.2.1
portmap-4.0-38En caso de que falte alguno de estos paquetes, inserte el CD de instalación en la unidad correspondiente, abra una terminal o consola y ejecute lo siguiente:
mount /mnt/cdrom/
rpm -Uvh /mnt/cdrom/RedHat/RPMS/paquete_faltanteCabe mencionar que lo mejor será siempre utilizar la versiones de nfs-utils y portmap más actuales. Salvo por RedHat® Linux 7.1 o LinuxPPP 7.x, el resto de las versiones anteriores de RedHat® y LinuxPPP® incluyen paquetes de nfs-utils y portmap con serios agujeros de seguridad. Visite el servidor ftp de la distribución utilizada y descargue los paquetes actualizados, que seguramente incluirán los parches de seguridad necesarios:
- ftp://updates.redhat.com/7.2/en/os/i386/, si posee alguna distribución basada sobre RedHat® Linux 7.2
- ftp://updates.redhat.com/7.3/en/os/i386/, si posee alguna distribución basada sobre RedHat® Linux 7.3
- ftp://updates.redhat.com/8.0/en/os/i386/, si posee alguna distribución basada sobre RedHat® Linux 8.0
- ftp://updates.redhat.com/9/en/os/i386/, si posee alguna distribución basada sobre RedHat® Linux 9
Configurando la seguridad.
Lo siguiente será configurar un nivel de seguridad para portmap. Esto se consigue editando los ficheros /etc/hosts.allow y /etc/hosts.deny. Debemos especificar que direcciones IP o rango de direcciones IP pueden acceder a los servicios de portmap y quienes no pueden hacerlo. Podemos entonces determinar en /etc/hosts.allow como rango de direcciones IP permitidas los siguiente:
portmap:192.168.1.0/255.255.255.0
Esto corresponde a la dirección IP de la red completa y la máscara de la sub-red. Adicionalmente podemos especificar direcciones IP individuales sin necesidad de establecer una máscara. Esto es de utilidad cuando se desea compartir volúmenes con otras máquinas en otras redes a través de Internet. Ejemplo:
portmap:192.168.1.0/255.255.255.0
portmap:192.168.20.25
portmap:192.168.30.2
portmap:216.200.152.96
portmap:148.240.28.171Una vez determinado que direcciones IP pueden acceder a portmap, solo resta determinar quienes no pueden hacerlo. Evidentemente nos referimos al resto del mundo, y esto se hace agregando la siguiente línea:
portmap:ALL
Es importante destacar que la línea anterior es INDISPENSABLE y NECESARIA si quiere tener un nivel de seguridad decente. De manera predeterminada las versiones más recientes de nfs-utils no permitirán iniciar el servicio si esta línea no se encuentra presente en /etc/hosts.deny.
Una vez configurado portmap, debe reiniciarse el servicio de portmap:
/sbin/service portmap restart
Si tiene un DNS, de de alta las direcciones IP asociadas a un nombre o bien edite /etc/hosts y agregue las direcciones IP asociadas con un nombre. Esto nos servirá como listas de control de accesos. Ejemplo del fichero /etc/hosts:
127.0.0.1 localhost.localdomain localhost
192.168.1.254 servidor.mi-red-local.org servidor
192.168.1.2 algun_nombre.mi-red-local.org algun_nombre
192.168.1.3 otro_nombre.mi-red-local.org otro_nombre
192.168.1.4 otro_nombre_mas.mi-red-local.org otro_nombre_mas
192.168.1.5 como_se_llame.mi-red-local.org como_se_llame
192.168.1.6 como_sea.mi-red-local.org como_sea
192.168.1.7 lo_que_sea.mi-red-local.org lo_que_seaCompartir un volumen NFS.
Procederemos a determinar que directorio se va a compartir. Puede crear también uno nuevo:
mkdir -p /var/nfs/publico
Una vez hecho esto, necesitaremos establecer que directorios en el sistema serán compartidos con el resto de las máquinas de la red, o bien a que máquinas, de acuerdo al DNS o /etc/hosts se permitirá el accesos. Esto deberemos agregarlos en /etc/exports determinado con que máquinas y en que modo lo haremos. Se puede especificar una dirección IP o bien nombre de alguna máquina, o bien un patrón común con comodín para definir que máquinas pueden acceder. De tal modo podemos utilizar el siguiente ejemplo (la separación de espacios se hace con un tabulador):
/var/nfs/publico *.mi-red-local.org(ro,sync)
En el ejemplo anterior se esta definiendo que se compartirá /var/nfs/publico/ a todas las máquinas cuyo nombre, de acuerdo al DNS o /etc/hosts, tiene como patrón común mi-red-local.org, en modo de lectura escritura. Se utilizó un asterisco (*) como comodín, seguido de un punto y el nombre del dominio. Esto permitirá que como_se_llame.mi-red-local.org, como_sea.mi-red-local.org, lo_que_sea.mi-red-local.org, etc., podrán acceder al volumen /var/nfs/publico/ en modo solo lectura. Si queremos que el accesos a este directorio sea en modo de lectura y escritura, cambiamos (ro) por (rw):
/var/nfs/publico *.mi-red-local.org(rw,sync)
Ya que se definieron los volúmenes a compartir, solo resta iniciar o reiniciar el servicio nfs. Utilice cualquiera de las dos líneas dependiendo el caso:
/sbin/service nfs start
/sbin/service nfs restartA fin de asegurarnos de que el servicio de nfs esté habilitado la siguiente vez que se encienda el equipo, debemos ejecutar lo siguiente:
/sbin/chkconfig --level 345 nfs on
El comando anterior hace que se habilite nfs en los niveles de corrida 3, 4 y 5.
Como medida de seguridad adicional, si tiene un contrafuegos o firewall implementado, cierre, para todo aquello que no sea parte de su red local, los puertos tcp y udp 2049, ya que estos son utilizados por NFS para escuchar peticiones.
Configurando las máquinas clientes.
Para probar la configuración, es necesario que las máquinas clientes se encuentren definidas en el DNS o en el fichero /etc/hosts del servidor. Si no hay un DNS configurado en la red, deberán definirse los nombres y direcciones IP correspondientes en el fichero /etc/hosts de todas las máquinas que integran la red local.
Como root, en el equipo cliente, ejecute el siguiente comando para consultar los volúmenes exportados (-e) a través de NFS por un servidor en particular:
showmount -e 192.168.1.254
Lo anterior mostrará una lista con los nombres y rutas exactas a utilizar. Ejemplo:
Export list for 192.168.1.254:
/var/nfs/publico 192.168.1.0/24A continuación creamos, como root, desde cualquier otra máquina de la red local un punto de montaje:
mkdir /mnt/servidornfs
Y para proceder a montar el volumen remoto, utilizaremos la siguiente línea de comando :
mount servidor.mi-red-local.org:/var/nfs/publico /mnt/servidornfs
Si por alguna razón en el DNS de la red local, o el fichero /etc/hosts de la máquina cliente, decidió no asociar el nombre de la máquina que fingirá como servidor NFS a su correspondiente dirección IP, puede especificar ésta en lugar del nombre. Ejemplo:
mount -t nfs 192.168.1.254:/var/nfs/publico /mnt/servidornfs
Podremos acceder entonces a dicho volumen remoto con solo cambiar al directorio local definido como punto de montaje, del mismo modo que se haría con un disquete o una unidad de CDROM:
cd /mnt/servidornfs
Si queremos poder montar este volumen NFS con una simple línea de comando o bien haciendo doble clique en un icono sobre el escritorio, será necesario agregar la correspondiente línea en /etc/fstab. Ejemplo:
servidor.mi-red-local.org:/var/nfs/publico /mnt/servidornfs nfs user,exec,dev,nosuid,rw,noauto 0 0La línea anterior especifica que el directorio /var/nfs/publico/ de la máquina servidor.mi-red-local.org será montado en en directorio local /mnt/servidor/nfs, permitiéndole a los usuarios el poder montarlo, en modo de lectura y escritura y que este volumen no será montado durante el arranque del sistema. Esto último es de importancia, siendo que si el servidor no está encendido al momento de arrancar la máquina cliente, este se colgará durante algunos minutos.
Una vez agregada la línea en /etc/fstab de la máquina cliente, si utiliza GNOME Midnight Commander, el administrador de archivos de GNOME-1.1 y 1.2, solo restará iniciar una sesión gráfica, hacer clique derecho sobre el escritorio y seleccionar Actualizar dispositivos o Rescan devices. Esto colocará un icono adicional sobre el escritorio que deberá ser tratado del mismo modo que se haría con un disquete o unidad de CDROM.
Si utiliza GNOME-1.4 o superior, éste incorpora Nautilus como administrador de archivos, mismo que auto-detecta cualquier cambio en /etc/fstab. Solo debe hacerse clique derecho sobre el escritorio y debe seleccionarse el disco que se desee montar.
Instalación de GNU/Linux a través de un servidor NFS.
Este es quizás el uso más común para un volumen NFS. Permite compartir un volumen que contenga una copia del CD de instalación de alguna distribución y realizar inclusive instalaciones simultáneas en varios equipos. Tiene como ventaja el que la instalación puede resultar más rápida que si se hiciese con un CDROM, siendo que la tasa de trasferencia de archivos será determinada por el ancho de banda de la red local, y nos permitirá instalar GNU/Linux en máquinas que no tengas unidad de CDROM.
Una vez creado y configurado un volumen a compartir copiaremos todo el contenido del CD de instalación en éste:
cp -r /mnt/cdrom/* /var/nfs/publico/
En el directorio images del CD encontraremos varias imágenes para crear disquetes de arranque. Utilizaremos bootnet.img para crear el número de disquetes necesarios para cada máquina en la que realizaremos una instalación, y que nos permitirán acceder a la red. Inserte un disquete y ejecute lo siguiente:
cd /var/nfs/publico/images/
dd if=bootnet.img of=/dev/fd0 bs=1440kAñada en /etc/hosts, o bien de de alta en el DNS, las direcciones IP, que serán utilizadas por las nuevas máquinas, asociadas a un nombre con el dominio que específico como regla de control de acceso en /etc/exports -es decir *.mi-red-local.org-. Para /etc/hosts, puede quedar algo así:
127.0.0.1 localhost.localdomain localhost
192.168.1.254 servidor.mi-red-local.org servidor
192.168.1.2 algun_nombre.mi-red-local.org algun_nombre
192.168.1.3 otro_nombre.mi-red-local.org otro_nombre
192.168.1.4 otro_nombre_mas.mi-red-local.org otro_nombre_mas
192.168.1.5 como_se_llame.mi-red-local.org como_se_llame
192.168.1.6 como_sea.mi-red-local.org como_sea
192.168.1.7 lo_que_sea.mi-red-local.org lo_que_sea
192.168.1.8 nueva_maquina.mi-red-local.org nueva_maquina
192.168.1.9 otra_nueva_maquina.mi-red-local.org otra_nueva_maquinaUtilice estos disquetes para arrancar en los equipos, ingrese una dirección IP y demás parámetros para esta máquina y cuando se le pregunte ingrese la dirección IP del servidor NFS y el directorio en éste donde se encuentra la copia del CD de instalación. El resto continuará como cualquier otra instalación.
Autor: Joel Barrios Dueñas
Correo electrónico: joelbarrios arroba linuxparatodos punto net Sitio de Red: http://www.linuxparatodos.net/
Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1
(c) 1999-2005 Linux Para Todos. Usted es libre de copiar, distribuir y comunicar públicamente la obra y hacer obras derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al autor original. b) No puede utilizar esta obra para fines comerciales. c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor. Los derechos derivados de usos legítimos u otras limitaciones no se ven afectados por lo anterior. Licencia completa en castellano. La información contenida en este documento y los derivados de éste se proporcionan tal cual son y los autores no asumirán responsabilidad alguna si el usuario o lector hace mal uso de éstos.Technorati Tags:
NFS servidor NFS portmap linux >>
Cómo interconexionar redes con WDS
Escrito por J. Llorente
Introducción a WDS y DS
Cuando se diseñó el estándar 802.11(1) se pensó en dos tipos básicos de servicios:
BSS (Basic Service Set): en este caso sólo hay un punto de acceso y una red inalámbrica definida por las estaciones conectadas a ese único AP.
ESS (Extended Service Set): en éste caso hay varios APs (como se muestra en la figura 1) e interesa que las estaciones conectadas a cualquiera de ellos puedan interconectarse de forma transparente. El sistema que permite dicha interconexión es el DS (Distribution System).
El sistema de distribución wireless no está del todo definido en el estándar 802.11 (sección 5.2.2(2)). Tampoco interesaba definirlo completamente, ya que es conceptualmente muy sencillo y a veces también muy fácil de implementar. De hecho el sistema de distribución está definido por separado ya que el medio puede ser distinto al 802.11, por ejemplo una red LAN Ethernet.
El DS es sencillamente la forma en que se interconectan varios puntos de acceso (o AP) para permitir la interconexión de las estaciones inalámbricas registradas en los distintos APs. El DS también sirve de base para la implementación de sistemas más sofisticados como el NoCatAuth, Roaming con IAPP, Mobility IP, etc.
Bridging (o WDS) en la LAN
La forma más simple de DS es la conexión de varios APs en las misma red LAN, configurados con un bridge a Nivel 2, tal como lo expliqué en el artículo anterior(3) y como se muestra en la siguiente imagen:
Figura1: Sistema de distribución a través de una LAN
La única diferencia es que en este caso tenemos dos ordenadores conectados a la misma LAN, con el bridging habilitado en los servidores wireless, el propio sistema de bridging se encargará de permitir la interconexión entre todas las estaciones y los ordenadores conectados a la LAN.
WDS, o DS inalámbrico
Pero, ¿es posible interconectar LAN o directamente APs a través del enlace inalámbrico?. Sí, sí es posible, para ello se ha definido un formato especial de paquete que implementado por el sistema de distribución inalámbrico o WDS (Wireless Distribution System). Gracias a este sistema, es posible interconectar APs mediante WDS “canales punto a punto” y hacer bridging a Nivel 2 entre todas las estaciones registradas en los puntos de accesos interconectados mediante WDS.
¿Porqué se necesita un formato especial de paquete? ¿Si hay interconexión entre un par de estaciones, una de ellas como AP y la otra como cliente, ¿no bastaría?. Sí, bastaría, pero sólo si la “interconexión” se hace a nivel de IP (similar al mostrado en figura 2, auque con redes distintas), donde se definen las rutas que se han de seguir manualmente o usando algún algoritmo de enrutamiento dinámico, tipo RIP o OSPF.
Figura2: Enrutado IP
Pero en el caso que quisiésemos interconectar dos redes LAN de forma “transparente”, es decir haciendo bridging a Nivel 2, mediante un enlace wireless (figura 3), no queda más remedio que usar las extensiones WDS del 802.11.
Figura 3: Interconexión de dos LAN a través de wireless
Campos adicionales en el paquete WDS
Las conexiones wireless entre dos estaciones se realizan siempre enviando la dirección MAC de la tarjeta wireless del origen y del destino. La dirección MAC del destino sirve para que la tarjeta del receptor reciba y procese el paquete localmente. Es decir, estos tipos de paquetes estándares sólo permiten la conexión entre un par de ordenadores, normalmente un AP y una estación registrada.
En el caso que se quieran interconectar a Nivel 2 un par de redes LAN, estos datos no bastan. Supongamos el siguiente caso, donde un ordenador A envía un paquete de datos a otro ordenador B en otra LAN distinta, interconectada por un enlaces inalámbrico:
Figura 4: Envío de paquetes entre A y B a través del WDS
Para que A (con MAC 00:00:00:00:00:11) y B (con MAC 11:00:00:00:00:11) se puedan comunicar a Nivel 2 ambas necesitan conocer la dirección MAC de la otra (de eso se encarga el protocolo ARP) y las tramas Ethernet que se envían usan dichas direcciones como origen y destino.
Si no tuviésemos la extensión WDS sería imposible realizar esta conexión, ya que en AP-A y AP-B perderíamos las direcciones MAC originales que serían reemplazadas por las direcciones MAC de los APs (00:00:00:00:00:00 y 11:00:00:00:00:00 respectivamente). Este problema se soluciona con la extensión WDS, que agrega dos campos adicionales para mantener las direcciones MAC del remitente y destino originales.
Por ejemplo, si AP-A envía una trama de A hacía B conectado al AP-B, los campos del paquete wireless tendrán (sección 7.1.2 del estándard,(2) definidas como address 1, address 2, address 3 y address 4):
Destinatario (o receptor, RA): 11:00:00:00:00:00
Origen (o transmisor, TA): 00:00:00:00:00:00
Destinatario original (DA): 11:00:00:00:00:11
Remitente original (SA): 00:00:00:00:00:11
...
Configuración del HostAP para AP-A y AP-B
Ahora veremos como configurar un Linux con el HostAP (y el bridging habilitado, leed el artículo(4)) y habilitar la extensión WDS para que funcione la configuración mostrada en la figura 4. Es decir, tenemos configurados dos puntos de acceso independientes (AP-A y AP-B), cada uno sirviendo a sus propias estaciones y red local, y con visibilidad de radio entre los dos AP.
Nos interesa ahora conectar ambas redes y todas las estaciones wireless dentro de una misma red de Nivel 2, como si fuese sólo una red LAN. O dicho de otra forma, queremos hacer funcionar un ESS completo con enlace WDS.
La condicición inicial es que ambos APs ya están configurados y funcionando como puntos de acceso. Ahora tenemos que asegurarnos que ambos estén en el mismo canal (con el iwconfig channel #) y crear una interfaz que será wlan#wds# que será el “punto a punto” con el otro AP. Cada una de dichas interfaces sólo funciona con un AP, por lo que hay que definir una para cada AP con el que queremos enlazar. En nuestro ejemplo cada AP tendrá sólo una interfaz adicional.
En los comandos listados a continuación lo que hacemos es:
Crear una interfaz wds (en ambos casos serán wlan0wds0) enlazándola con la MAC del otro AP.
Configurarla la IP en 0.0.0.0
Agregar dicha interfaz al bridge.
Estos ejemplos están explicados en el fichero README.prism2(5) que viene con el HostAP.
Configuración AP-A
iwpriv wlan0 wds_add 11:00:00:00:00:00
ifconfig wlan0wds0 0.0.0.0
brctl addif br0 wlan0wds0
Configuración AP-B
iwpriv wlan0 wds_add 00:00:00:00:00:00
ifconfig wlan0wds0 0.0.0.0
brctl addif br0 wlan0wds0
Una vez realizados estos comandos y después de unos breves segundos ya deberías ver como se actualiza el bridge de cada ordenador:
ponti:~# iwconfig
...
wlan0 IEEE 802.11-b ESSID:"Antoli"
Mode:Master Frequency:2.437GHz Access Point: 00:50:C2:01:96:14
Bit Rate:11Mb/s Tx-Power:7 dBm Sensitivity=1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:XXXXXXXXXXXXXXXXXXX Encryption mode:restricted
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:1907 Invalid misc:1540 Missed beacon:0
wlan0wds IEEE 802.11-b ESSID:"Antoli"
Mode:Master Frequency:2.437GHz Access Point: 00:50:C2:01:96:14
Bit Rate:11Mb/s Tx-Power:7 dBm Sensitivity=1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key: XXXXXXXXXXXXXXXXXXX Encryption mode:restricted
Power Management:off
ponti:~# ifconfig
...
wlan0 Link encap:Ethernet HWaddr 00:50:C2:01:96:14
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:659454 errors:0 dropped:36941 overruns:0 frame:0
TX packets:79931 errors:1897 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:7410 (7.2 KiB) TX bytes:3679847 (3.5 MiB)
Interrupt:10 Base address:0x100
wlan0wds0 Link encap:Ethernet HWaddr 00:50:C2:01:96:14
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60946 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3926524 (3.7 MiB) TX bytes:42698209 (40.7 MiB)
Interrupt:10 Base address:0x100
ponti:~#
ponti:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0050c2019614 yes eth0
wlan0
wlan0wds0
NOTA: la elección de la dirección MAC 00:00:00:00:00:00 ha sido una muy mala idea, porque dicho número tiene un significado especial. Pero es sólo un ejemplo, ya tengo las figuras acabadas y seguramente usaréis lo que viene a continuación, la configuración automática :-)
Enlace automático con los otros AP
Habéis visto que hay que especificar manualmente la dirección MAC de cada AP con el que queremos crear un enlace. Pero hay una forma de hacerlo que sea automático. Esto es muy útil, sobre todo si estáis haciendo pruebas con tarjetas distintas, donde cada una de ellas tienen diferentes MACs, y el procedimiento de cambiar la configuración cada vez es muy tedioso.
En el caso de que queramos hacer los enlaces automáticamente, primero hay que crear todas las interfaces wlan#wds# que hagan falta, una para cada posible AP. Luego hay que habilitar en enlace automático con el comando iwpriv (incluido en el paquete wireless-tools) y el prism2_param que viene en el subdirectorio utils del hostap.
El procedimiento completo para todos los APs es el siguiente (en el ejemplo creamos dos interfaces wds, para enlazar con dos APs distintos):
# la primera interfaz wds
iwpriv wlan0 wds_add 00:00:00:00:00:00
ifconfig wlan0wds0 0.0.0.0
brctl addif br0 wlan0wds0
# la segunda interfaz wds
iwpriv wlan0 wds_add 00:00:00:00:00:00
ifconfig wlan0wds1 0.0.0.0
brctl addif br0 wlan0wds1
# habilitamos en enlace automático
prism2_param wlan0 autom_ap_wds 1
prism2_param wlan0 other_ap_policy 1
# agregamos ambas interfaces al bridge
brctl addif br0 wlan0wds0
brctl addif br0 wlan0wds1
Si todo funciona correctamente, podéis mirar en el /var/log/syslog y tenéis que ver un mensaje como el mostrado a continuación cuando se crear la conexión entre los dos AP:
... wlan0: adding automatic WDS connection to AP 00:50:c2:01:96:14
... wlan0: using pre-allocated WDS netdevice wlan0wds0
Por supuesto, siempre es de mucha ayuda en estos casos ver el estado de las tablas del bridge:
ponti:~# brctl showmacs br0
port no mac addr is local? ageing timer
1 00:04:76:26:96:c7 no 0.12
3 00:05:5d:d6:4b:da no 0.43
3 00:30:65:1d:e6:3a no 222.69
1 00:40:43:05:66:00 no 19.21
3 00:50:c2:01:96:14 yes 0.00
2 00:50:c2:01:96:14 yes 0.00
1 00:60:08:b3:6c:b7 yes 0.00
Repetidor
Por si no os habéis dado cuenta, si no le configuráis una interfaz LAN (ethernet), el AP funcionará solamente como repetidor wireless. Fácil y guapo ¿no?. Pero tened en cuenta que ambos están en el mismo canal, por lo que el tráfico se duplica o triplica y además se crean interferencias (ver las consideraciones finales). Pero sirve muy bien para poner a ambos a suficiente distancia y así ampliar el alcance de la red inalámbrica (mientras mayor sea la distancia entre las estaciones conectadas a ambos AP, menor será la interferencia entre ellas).
Configuración en Debian
Si, ya lo sé, ejecutar todos los comandos de configuración manualmente es un cmuy tedioso. Poner en un script especial para ejecutar al arranque no es nada elegante. Lo ideal es Hacerlo Donde Toca © :-) Por eso os muestro mi ejemplo de cómo lo he especificado en el /etc/network/interfaces de una Debian (que es la única distro que uso para las pruebas, el apt-get es insuperable y siempre tengo las últimas versiones :-).
En mi caso se tratan de dos portátiles, cada uno con una Ethernet y una Conceptronic PCMCIA (insisto, antes de hacer estas pruebas, aseguraros que todo funciona correctamente en modo Master leyendo el artículo(3) que mencioné anteriormente).
Como ifup/ifdown son bastantes estrictos (demasiado), puede dar error si se especifica la dirección 0.0.0.0 en la línea del address, por lo que a continuación se hace ésto manualmente con el ifconfig una vez que la interfaz ya está en marcha (especificando la stanza [sic] up) para ponerla en modo promiscuo.
Aseguraros que el comando prism2_param (es un script del shell) está en el PATH del root, sino fallará al ejecutarse el ifup y quedarán las interfaces mal configuradas (verificar que no haya errores en el /var/log/syslog).
Como podéis ver, lo que se hace es crear automáticamente al arranque (auto br0) el bridge br0. Luego para cada interfaz de red (eth0 y wlan0) las agrega al bridge br0 en cuanto están configuradas. En el caso de la interfaz wlan0 también crea el wlan0wds0, especifica la política de conexión automática, y también agrega esta interfaz al bridge br0.
Todo muy simple y lineal (en realidad se podrían poner más cosas, especialmente para cuando se “baja” la interfaz y para hacer un reset, pero eso ya os dejo como trabajo para casa :-)
# /etc/network/interfaces
# The loopback interface
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.0.3
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.1
bridge_ports none
bridge_stp on
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
up /usr/sbin/brctl addif br0 eth0
iface wlan0 inet static
address 192.168.0.2
netmask 255.255.255.0
wireless_essid Antoli
wireless_mode Master
wireless_key s:poner_tu_clave
wireless_channel 6
up ifconfig wlan0 0.0.0.0
up /usr/sbin/brctl addif br0 wlan0
up iwpriv wlan0 wds_add 00:00:00:00:00:00
up ifconfig wlan0wds0 0.0.0.0
up prism2_param wlan0 autom_ap_wds 1
up prism2_param wlan0 other_ap_policy 1
up /usr/sbin/brctl addif br0 wlan0wds0
down ifconfig wlan0wds0 down
Consideraciones finales
Por supuesto no todo es maravilloso, algunos de los problemas conocidos y que me he encontrado son:
- Ambos AP tienen que usar el mismo canal, por lo que el tráfico se duplica o triplica. Por ejemplo supongamos que hay tráfico entre A, una estación wireless conectada al AP-A y la estación B, conectada al AP-B. Los paquetes de A hacia B primero van hacia AP-A, luego a AP-B y recién a B, es decir que triplicamos en tráfico en el mismo canal, así que no lograréis pasar de los 2 Mbps.
gallir@sofi:~$ wget http://192.168.0.10/~gallir/www.tgz
...
Connecting to 192.168.0.10:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15,763,198 [application/x-tar]
100%[=====....===========>] 15,763,198 161.43K/s ETA 00:00
23:17:22 (161.43 KB/s) - `www.tgz.10' saved [15763198/15763198]
- En mis pruebas he observado que si los AP están muy cerca entre ellos se producen muchos descartes de paquetes haciendo que las tarjetas están bajando y subiendo continuamente la velocidad de transmisión en caso de tráfico elevado:
...
... wlan0: STA 00:05:5d:d6:4b:da TX rate raised to 55
... wlan0: STA 00:05:5d:d6:4b:da TX rate raised to 110
... wlan0: STA 00:05:5d:d6:4b:da TX rate lowered to 55
- Si una estación está primero registrado en el AP-A y luego se registra en AP-B, se pierde la conectividad entre la estación y AP-A durante unos cuantos minutos (5, aproximadamente). Este efecto sólo ocurre con la conectividad entre la estación y el AP-A, no así entre la estación móvil y las otras registradas en el AP-A (si, es muy extraño). Este problema se solucionará con el protocolo IAPP, que está en desarrollo en el HostAP, para notificar inmediatamente de las bajas y registros a nuevos APs.
- Por un bug en las versiones anteriores al 1.4.9 del firmware STA de las tarjetas PRISM2, el formato del paquetes WDS no es estándar, por lo que esas tarjetas no funcionarán con otros AP que no sean del HostAP (y OpenAP, que tienen un formato similar).
- En las versiones nuevas del HostAP (del CVS) ya se puedes recibir paquetes WDS con el formato estándar, pero sólo en modo Managed (en éste artículo lo hacemos todo en modo Master).
- Como las tarjetas tienen una sola radio es imposible con una única tarjeta usar dos canales distintos, que sería lo ideal para interconectar dos redes o hacer de repetidor con el WDS y dar conectividad a las estaciones clientes por otro canal distinto para evitar las limitaciones de ancho de banda e interferencias. Dada esta limitación, lo ideal sería poner dos tarjetas en un ordenador, usar una para el WDS en modo repetidor (siguiente tema que trataré en otro artículo), y la otra para las estaciones inalámbricas.
Por último, tened en cuenta que estamos haciendo ésto para conectar redes LAN (o hacer de repetidor) en forma transparente para tener una sólo red IP. Si tenéis redes IP distintas, el problema es más sencillo de solucionar a nivel de wireless, aunque un poco más complejo a nivel de encaminamiento IP.
En otro artículo hablaremos de configuración de DHCP, autentificación 802.1X, Radius e IAPP, pero eso después que lo haya terminado de instalar y configurar en mi laboratorio, es decir en mi casa :-)
Lista de enlaces de este artículo:
- http://standards.ieee.org/getieee802/802.11.html
- http://standards.ieee.org/getieee802/download/802.11-1999.pdf
- http://bulmalug.net/body.phtml?nIdNoticia=1309
- http://bulmalug.net/body.phtml?nIdNoticia=1309&nIdPage=4
- http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/*checkout*/hostap/README.prism2?rev
- http://hostap.epitest.fi/
- http://bulmalug.net/~gallir/BULMA/LasPalmas2002/
- http://mnm.uib.es/~gallir/LasPalmas2002/wireless.pdf
- http://bulmalug.net/~gallir/fotos/LasPalmas2002/
- http://mnm.uib.es/~gallir/LasPalmas2002/laspalmas2002.ogg
- http://www.gulic.org
E-mail del autor: Esta dirección electrónica esta protegida contra spam bots. Necesita activar JavaScript para visualizarla
Podrás encontrar este artículo e información adicional en: http://bulmalug.net/body.phtml?nIdNoticia=1624
Technorati Tags:
WDS DS 802.11 BSS ESS linux Bridging lan wireless wifi hostAP redes host debian ubuntu >>
Agregue su comentario
Facebook conecta
Sitios Amigos
InfoMet
Total visitas
Quien está en linea
Conectan
Nos visitan desde
Puedes seguirme en twitter, fuente de información instantánea, actualiza tus conocimientos y los de los demás.
Puedes compartir en facebook tu experiencia, sígueme en facebook con tus amigos
Más de 65 millones de profesionales utilizan LinkedIn para intercambiar información, ideas y oportunidades