:: Novedades :: Tarjetas wifi :: COMO: PA con OpenBSD :: Enlaces ::

obsd-wifi

Bienvenido a mi modesta página sobre OpenBSD y redes wireless.

Novedades

4 de Noviembre 2005

Pequeñas correcciones y añadidos.

24 de Febrero 2004

He hecho una revisión general de documento. No voy a enumerar los cambios, pero hay algunos ;)

15 Octubre 2003

He añadido una nota referente a crear clientes para túneles SSH cuando se usa PuTTY (un cliente popular para Win32, entre otros). Este programa no permite crear túneles sin hacer login y requiere un trato especial al descrito.

24 Septiembre 2003

He actualizado el COMO en lo que respecta a la configuración de SQUID para cerrar un puerto UDP que no se usará habitualmente en nodos wireless.

22 Septiembre 2003

La guía rápida también está disponible aquí.

18 Septiembre 2003

Esta página a veces es un poco complicada de consultar, por lo que he pasado los contenidos básicos a una guía rápida que se ha publicado en CertMX. Además he empleado sgml y Docbook así que, además de la versión html para consultar online, hay un ps/pdf para imprimir.

La máquina que hospeda Elche Wireless ha sufrido un pequeño percance. Durante el día de hoy se evaluarán los daños, aunque seguramente tendremos el servidor caido unos días.

30 Junio 2003

He hecho visible el servidor HTTP del nodo en http://reidrac.dyndns.org. Cuando el nodo tenga acceso a internet, esta dirección funcionará. Cuando no, pues no :-)

27 Junio 2003

Actualización del COMO: más sobre túneles SSH en los clientes.

26 Junio 2003

Actualización del COMO: proporcionar salida a internet con Squid y túneles SSH.

23 Junio 2003

Actualización del COMO: proporcionar salida a internet con NAT.

13 Junio 2003

Ayer a las 20:54:50 UTC tuve mi primera conexión al nodo. He actualizado el COMO porque se me olvidó poner la tasa de transferencia a 1Mbps ;-) Gracias a josefu por el aviso.

10 Junio 2003

Queda innagurada esta web :-) Mi nodo en elxwifi está en pruebas.

^ top

Tarjetas

La lista completa de tarjetas soportadas la puedes encontrar en wi(4), aunque pueden haber más.

Dar con una tarjeta compatible puede ser algo complicado porque muchas de las que aparecen en el listado están descatalogadas o no se prodigan mucho por el mercado español.

También hay que asegurarse que es la tarjeta que creemos que es ya que, por ejemplo, la DWL-520 no tiene nada que ver con la DWL-520+ porque esta última emplea otro chipset.

Generalmente podemos arriesgarnos a probar cualquier tarjeta que emplee uno de los siguientes chips: Lucent Hermes, Intersil PRISM-2, Intersil PRISM-2.5, Intersil PRISM-3 o Symbol Spectrum24.

Lo malo es que casi siempre resulta complicado averiguar que chip emplean las tarjetas :-( Es recomendable buscar concienzudamente en la página web del fabricante.

Hay tres opciones en cuanto a tarjetas según el bus: PCMCIA, PCI y usando un adaptador PCMCIA->PCI (o ISA).

Hay dos opciones en cuanto a tarjetas según la antena: con antena removible (podremos ponerle una más potente) y con antena fija.

Por último necesitamos una tarjeta que soporte hostap si queremos montar un punto de acceso, por lo que habrá que fijarse bien en las especificaciones de la tarjeta. Si solo queremos la tarjeta para conectar a otros puntos de acceso, cualquier tarjeta nos vale.

Me costó 3 días de research y una buena dosis de suerte encontrar una tarjeta 802.11b compatible a buen precio, pero es posible ;-)

La criatura es una Connection N&C W-LPS, que no está en la lista de tarjetas soportadas (bueno, sí está como Intersil Mini-PCI... -pese a que NO es mini pci- pero como el fabricante no dice que es esa tarjeta, pues no podemos saberlo).

En Elche Wireless mantenemos una interesante lista de tarjetas.

^ top

COMO: PA con OpenBSD

Contenidos



Introducción

Estos son los pasos que seguí para montar un punto de acceso para redes 802.11b con OpenBSD.

El nodo tiene acceso a una red local desde la cual puede salir a internet (opcionalmente) gracias a otra máquina que hace NAT.

Objetivos

Lo que se busca conseguir es:



El hardware

El hardware empleado es el siguiente:

CPU:Pentium 100 Mhz
RAM:64 Mbs
HDD:840 Mbs
RED: D-Link DFE-538TX (Ethernet 10/100 PCI)
Connection N&C W-LPS (Wireles 802.11b PCI, con Intersil Prism 2.5)

Debido a que me dió por hacer modding y al final me aburrí, la carcasa es negra y el frontal no, pero bueno. La máquina se llama blackshell, que mola bastante XD

blackshell
Detalle de blackshell ;-)

El software

Todo el software necesario viene en la instalación base de OpenBSD (3.3-RELEASE). De hecho solo me limité a quitar el set game33.tgz de los seleccionados por defecto.

No es necesario recompilar el kernel, ya que todo el hardware usado está soportado en GENERIC y la máquina lo mueve sin problemas con sus 64 Mbs de RAM. Más adelante quizás recompile para optimizar un poco (y posiblemente me cargue algo XD).

Ya que no siempre se va a dar acceso a internet, se cuidó que el espacio del disco quedara bien distribuido para ofrecer servicios locales (web, ftp anónimo, etc).

La instalación del sistema se hizo empleando un disquete y bajando los sets vía ftp desde la red local (blackshell tiene el CDROM estropeado).

Aquí se puede consultar la salida de dmesg(8) tras la instalación del sistema.

Asignaremos al nodo la dirección 10.1.1.21 de la red elxwifi, configurado a 1Mbps y en modo hostap. Mediante DHCP repartiremos las direcciones desde 10.1.1.22 a 10.1.1.30.

Configurando la tarjeta

Primero configuramos la tarjeta.

Levantamos la interface a mano hasta que demos con lo que queremos:

ifconfig wi0 inet 10.1.1.21 netmask 255.255.255.0 up nwid elxwifi media DS1 mediaopt hostap

Si comprobamos el resultado, vemos: 

# ifconfig wi0
wi0: flags=8843 mtu 1500
        address: 00:90:4b:23:89:8a
        nwid elxwifi
        powersave off
        media: IEEE802.11 DS1 hostap
        status: active
        inet6 fe80::290:4bff:fe23:898a%wi0 prefixlen 64 scopeid 0x1
        inet 10.1.1.21 netmask 0xffffff00 broadcast 10.1.1.255

El media DS1 es opcional. En ese momento lo puse así porque la máquina no poseía una antena externa y bajando la velocidad se aumenta la cobertura. De todas formas no todas las tarjetas se pueden poner a la velocidad que queramos. De hecho la tarjeta que empleo como mínimo va a 2Mbps. Lo habitual es que las tarjetas, con chip PRISM al menos, trabajen a 2, 5.5 y 11 megas, así que puede que tengamos que hacer pruebas.

Si te equivocas puedes 'bajar' el interface con ifconfig wi0 down.

Cuando todo está como queremos, para que que se levante la interface en cada boot, creamos un fichero llamado hostname.wi0 con la siguiente linea dentro:

inet 10.1.1.21 255.255.255.0 NONE nwid elxwifi media DS1 mediaopt hostap

Con esto nos aseguramos que el sistema levantará el interface cada vez arranque el sistema, con lo que solo nos queda introducir los parámetros de la tarjeta mediante wicontrol(8).

Para ello empleamos ! en nuestro hostname.wi0. Lo que siga a ese signo de exclamación se ejecutará.

Seleccionamos el canal (en este caso el 10):

!wicontrol -f 10

Le damos un nombre al nodo:

!wicontrol -s "blackshell"

Y seleccionamos tasa de transmisión (1Mbps):

!wicontrol -t 1

Quedando el fichero así: 

inet 10.1.1.21 255.255.255.0 NONE nwid elxwifi media DS1 mediaopt hostap
!wicontrol -f 10
!wicontrol -s "blackshell"
!wicontrol -t 1

Otra vez la linea de la tasa de transmisión es opcional, y por lo mismo de antes.

Con esto tenemos la tarjeta configurada.

Configurando dhcpd

Ahora configuramos el servidor DHCP.

Editamos /etc/rc.conf.local y añadimos dhcpd_flags="-q" para que en el siguiente boot arranque el servidor DHCP normalmente (el -q es para quiet, porque el server es demasiado 'escandaloso'). Si no existe rc.conf.local, lo creamos.

Hacemos un:

# echo wi0 > /etc/dhcpd.interfaces

Y luego editamos el /etc/dhcpd.conf a nuestro gusto. En este caso: 

subnet 10.1.1.0 netmask 255.255.255.0 {
        range 10.1.1.22 10.1.1.30;
}

Esta configuración es muy sencilla. Para más información consulta dhcp-options(5).

Es importante hacer touch /var/db/dhcpd.leases antes de ejecutar por primera vez dhcpd, o sino no arrancará porque no encuentra ese fichero.

Servicios locales

Los servicios locales se configuran normalmente, teniendo en cuenta que serán accedidos desde la IP que hemos asignado a wi0 (10.1.1.21).

Para evitar errores haremos siempre bind a la IP que sea necesaria. Si por ejemplo controlo a blackshell vía LAN empleando secure shell, para evitar problemas, el demonio sshd está escuchando la IP de la red local (192.168.0.0), de forma que no sea posible conectar desde la red de la tarjeta wireless (10.1.1.0).

También podemos desentendernos del tema y emplear PF convenientemente ;-)

Dando salida a internet con NAT

Hasta este punto tenemos una configuración básica que ya dejaría a nuestro nodo operativo.

Ahora vamos a ver los pasos necesarios para dar salida a internet a los clientes que conecten al nodo.

En primer lugar hay de dejar claro esta configuración no es segura, ya que no se realiza ninguna clase de autentificación y cualquier cliente del nodo podría emplear la salida a internet a su discrección. Además las conexiones son susceptibles de ser 'escuchadas' por un cliente malintencionado, por lo que tendremos que tener cuidado de emplear canales seguros en caso de enviar/recibir información sensible (SSL, SSH, etc.).

Para dar salida emplearemos PF (Packet Filter), que es el sistema de OpenBSD para controlar el tráfico TCP/IP y realizar NAT. PF también es capaz de acondicionar el tráfico y proveer de control de ancho de banda con priorización de paquetes.

Como tenemos acceso a internet vía LAN y otra máquina nos dará salida al exterior de forma transparente, vamos a hacer NAT con la red local para paquetes que no vayan a la LAN y que vengan de las IPs a las que queremos dar salida, así mantenemos la red local privada y solo damos salida a los clientes que queremos.

Además vamos a limitar el acceso a internet dejando solo 48kbps de ancho de banda. Dispongo de una cutre-conexión en casa, así que no quiero dar mucho caudal. Para navegar es más que suficiente, y así vemos como se puede limitar el caudal con OpenBSD ;-)

Asígnaremos una IP fija según MAC para los usuarios que salgan a internet. El resto de IPs se reparten normalmente. Notar que la configuración vía DHCP es por comodidad (configura la puerta de enlace y los DNS además de la IP), pero no aporta nada a la seguridad.

Configurando PF

Primero vamos a configurar el cortafuegos y la Network Address Translation (NAT).

Activamos el PF editando /etc/rc.conf.local y poniendo pf=YES.

Si no queremos reiniciar, con pfctl -e y pfctl -d activamos/desactivamos PF inmediatamente.

También hay que activar NAT. Hay que añadir en /etc/sysctl.conf: 

net.inet.ip.forwarding=1

Bastará con que descomentemos la linea, que estará comentada por defecto. Con sysctl -w variable=valor podremos activar los cambios sin reiniciar.

Las reglas que aplicará PF están todas en /etc/pf.conf. Es interesante emplear pfctl(8) para comprobar los cambios que vamos haciendo en la configuración (pfctl -nf /etc/pf.conf comprueba la sintaxis del fichero sin aplicar las reglas).

Hay que tener en cuenta que PF compara todas las reglas en orden de entrada y aplica la última que encaja, a no ser que empleemos quick para aplicar esa regla y que deje de buscar en la tabla.

En este ejemplo vamos a suponer que un usuario conocido va a usar internet. Le asignamos la IP 10.1.1.99. Empleamos una macro para meter las direcciones IP de los usuarios conocidos (separadas con comas).

Que quede claro que no soy un experto y que esto no es un tutorial de PF, ¿eh? O:-)

Estas son las reglas que tengo en blackshell: 

#
# pf.conf de blackshell
#
# ne3 -> 192.168.0.0/24 LAN
# wi0 -> 10.1.1.0/24 WiFi
#

# lista de IPs separada con comas
usuarios="10.1.1.99/32"

# activamos las colas en wi0
altq on wi0 cbq bandwidth 10Mb queue { rwifi, rext }

# a la red WiFi, normal (por defecto)
queue rwifi cbq(default)

# a internet, limita a 48Kbps de ancho de banda
queue rext bandwidth 48Kb cbq

# NAT hacia la LAN desde WiFi
nat on ne3 from { $usuarios } to ! 192.168.0.0/24 -> ne3

# predeterminado: no pasa nada
block in all
block out all

# dejamos pasar el loopback a saco, quick hace que se
# aplique la regla sin evaluar nada mas
pass quick on lo0 all

# activamos antispoof
antispoof quick for wi0 inet
antispoof quick for ne3 inet

# libre tráfico para ne3
pass in quick on ne3 from any to ne3
pass out quick on ne3 from ne3 to any

# las reglas comprometidas son las que afectan a la
# inteface wi0, así que a partir de aquí... cuidado

# libre tráfico para internet
pass in on wi0 from { $usuarios } to any queue rext
pass out on wi0 from any to { $usuarios } queue rext

# libre tráfico en WiFi
pass in on wi0 from 10.1.1.0/24 to wi0 queue rwifi
pass out on wi0 from wi0 to 10.1.1.0/24 queue rwifi

# fin pf.conf de blackshell

He usado una macro (usuarios) para meter dentro la lista de IPs, separada con comas, a las que daremos salida a internet.

Configurando dhcpd

Ahora solo nos falta retocar la configuración básica que ya teníamos para dhcpd, que quedaría: 

#
# dhcpd.conf de blackshell
#

subnet 10.1.1.0 netmask 255.255.255.0 {
        range 10.1.1.22 10.1.1.30;
}

# usuarios conocidos

group {
        option domain-name "myisp.com";
        option domain-name-servers 172.10.1.23, 172.10.1.24;
        option routers 10.1.1.21;

        host vortex {
                hardware ethernet 08:00:2b:4c:59:23;
                fixed-address 10.1.1.99;
        }
}

# fin dhcpd.conf

De esta forma añadimos a la configuración básica que ya teníamos un grupo en el que blackshell (10.1.1.21) enruta los paquetes y especificamos los DNS que se emplearán. También hemos asignanado una IP fija asociada a la MAC de nuestro cliente con salida a internet.

Y con esto está todo por parte del punto de acceso, y los clientes no tendrán más que dejar que su cliente DHCP haga todo el trabajo :-)

Solo hay que reiniciar y comprobar que todo funciona correctamente.

Añadiendo nuevos usuarios

Cuando se da de alta un usuario que hará uso de internet seguimos los siguientes pasos:

  1. Pedimos la MAC de la tarjeta con la que el usuario va a conectarse al nodo.
  2. Modificamos /etc/dchpd.conf añadiendo el nuevo host (MAC,IP fija).
  3. Añadimos a /etc/pf.conf la IP del nuevo usuario.
  4. Ejecutamos pfctl -f /etc/pf.conf y listo.

Es importante recordar que este método no es seguro y que virtualmente cualquiera podría conseguir salir a internet sin nuestro permiso.

Internet con Squid y túneles SSH

Existen diferentes opciones para conseguir los dos puntos que no podemos obtener con NAT: autentificación de usuarios y seguridad en las conexiones.

Hay soluciones que nos dan autentificación, como NoCatAuth, Squid usando proxy_auth o IPsec empleando tramas AH.

Por ahora voy a descartar la autentificación a secas porque persistiría el problema de la seguridad.

La seguridad pasa por encriptar las conexiones, y en ese caso IPsec también podemos, o solo encriptar las conexiones, o autentificar y encriptar.

El problema de IPsec es que carga mucho al nodo (tanto en ancho de banda con en CPU) y la conectividad entre las distintas implementaciones no es muy buena. No todos los clientes trabajarán con un BSD, claro :-)

Además los clientes son complicados de configurar y aun tendríamos que dar salida a internet, con NAT por ejemplo, y se dice que NAT e IPsec no son muy buenos amigos.

La verdad es que no he conseguido una solución satisfactoria con IPsec, así que me he decantado por otra opción: un proxy + túneles SSH.

Todos conocemos SSH, y muchos lo usamos con frecuencia como substituto de telnet. Lo que no todos conocemos son sus 'otras funcionalidades', como la de crear túneles encriptados entre dos máquinas.

Básicamente se trata de conectar dos máquinas con SSH, como si de una sesión shell se tratara, pero conectando un puerto de nuestra máquina local con otro de la máquina remota.

En nuestro caso vamos a poner un proxy (Squid) en la máquina remota (el nodo) escuchando su puerto habitual pero en localhost. Generaremos un túnel SSH entre nuestra máquina y ese puerto en localhost de la máquina remota empleando el puerto 13128, por ejemplo. Entonces solo nos queda configurar nuestra aplicación que tiene que hacer uso de internet para que use Squid en el puerto local 13128 de nuestra máquina.

SSH se encargará de cifrar todos los datos haciendo un túnel entre el Squid en el nodo y nuestra aplicación en el cliente.

Gracias a los túneles SSH conseguimos autentificación (es necesario tener una cuenta SSH en el nodo para poder crear el túnel), y seguridad (todo el tráfico está encriptado).

Además la configuración de los clientes es muy sencilla, existiendo clientes SSH para casi cualquier sistema operativo (en muchos casos, como son los UNIX o UNIX-like, viene en la instalación básica del sistema).

En el nodo vamos a montar solo el proxy, porque el demonio de SSH ya viene de casa con OpenBSD (desde obsd se desarrolla OpenSSH así que... X-D).

El nodo

Squid está en los ports de OpenBSD. Con lo que, si tenemos el árbol de ports instalado, es tan sencillo como hacer siendo root: 

# cd /usr/ports/www/squid
# make install

Aunque probablemente nuestra máquina sea vieja como para andar compilando muchas cosas :-) o simplemente no tengamos suficiente disco como para manejar el árbol de ports. En ese caso nos bajamos el paquete binario de nuestra release y punto. Instalamos en ese caso con:

# pkg_add squid-2.5.STABLE1.tgz

La instalación nos dará algunas notas sobre como quedan las cosas en OpenBSD, y consejos sobre lo que debemos hacer a continuación:

Tampoco soy un experto en Squid (¿seré alguna vez experto en algo? X-D). Hay información abundante en la red, no obstante aquí sigue cómo lo he hecho yo.

Las opciones por defecto aparecen comentadas. Las dejaremos así a no ser que tengamos que cambiarlas.

Además veremos que el fichero de configuración está perfectamente comentado: hay que leer para saber que estamos haciendo ;-)

Para nuestro caso vamos a tener que modificar:

Ahora inicializamos el caché de Squid con: 

# /usr/local/sbin/squid -z
2003/06/26 17:40:21| Creating Swap Directories

Arrancamos Squid con:

# /usr/local/sbin/squid

Y por último añadimos en rc.local algo así para que arranque Squid en cada boot: 

if [ -x /usr/local/sbin/squid ]; then
       echo -n ' Squid';  /usr/local/sbin/squid
fi

Como el nodo tiene acceso a internet mediante la red local, Squid desde el nodo tiene acceso a internet.

Hasta aquí acabaría la configuración del nodo a no ser que queramos añadir alguna regla a nuestro PF para limitar el ancho de banda. Viendo el ejemplo sobre como dar salida a internet con NAT no debe ser demasiado complicado limitar a las conexiones a SSH desde WiFi.

Es interesante ejecutar en el nodo tcpdump(8) sobre wi0 para comprobar que todo el tráfico realmente transcurre por el túnel SSH.

Los clientes

La configuración de los clientes es trivial: creamos el túnel SSH y configuramos la aplicación que tendrá acceso a internet para que use Squid desde el túnel.

Obiamente es necesario que tengamos una cuenta SSH en el nodo (aunque no nos dejen hacer login en él), y no es necesario ser root para crear el túnel (por eso empleamos un puerto alto como el 13128).

El siguiente ejemplo es válido para OpenSSH, disponible en cualquier UNIX o UNIX-like libre.

Creamos el túnel con:

$ ssh -l usuario -L 13128:127.0.0.1:3128 -N 10.1.1.21

Donde usuario es el usuario con el que tenemos cuenta en el nodo, 13128 es el puerto local, 127.0.0.1:3128 es donde escucha Squid en el nodo, y 10.1.1.21 es la IP del nodo.

Entonces nuestro cliente SSH nos pedirá la contraseña y, si todo va bien, se quedará esperando que hagamos un Ctrl+C para romper el túnel.

La configuración de la aplicación dependerá da la aplicación, claro. Y ahí no entro, aunque tenemos que recordar el proxy se encuentra en 127.0.0.1:13128 (que es nuestro túnel SSH).

Tenemos que recordar que, aunque nuestra principal baza será hacer túneles contra Squid, también podemos hacer túneles a otras máquinas a las que el nodo tenga acceso.

Si por ejemplo queremos recoger el correo de un servidor POP3, el proxy nos servirá de poco. En este caso haremos el túnel hacia nuestro servidor de correo:

$ ssh -l usuario -L 10110:pop3.myisp.com:110 -N 10.1.1.21

Dónde 10110 será el puerto local a donde conectará nuestro cliente de correo (usando como servidor POP3 127.0.0.1, claro), pop3.myisp.com es el servidor POP3 real donde tenemos el correo, y 110 es el puerto donde está el servicio POP3 en esa máquina externa.

Solo hay que configurar al cliente de correo para que use como servidor POP3 127.0.0.1:10110 y podremos recoger el correo de forma segura, mediante el túnel que hay entre nuestra máquina y el nodo.

Lo mismo haríamos para el servidor SMTP si quisieramos enviar correo.

Hay que resaltar que aunque el túnel sea hacia una máquina en internet, la conexión entre el nodo y esa máquina externa queda fuera del túnel. Pero bueno, ya entramos en la seguridad habitual de internet. La parte 'peligrosa' que es la red wireless ya está superada.

Quizás sea incómodo crear el túnel cada vez que queramos internet o usar un servicio externo, pero es lo mejor. Si automatizamos el túnel (desde nuestro cliente DHCP cuando nos asignen IP, por ejemplo) seguramente podríamos comprometer nuestra contraseña, algo que no es buena idea. Aunque el administrador puede decidir permitir logins sin contraseña y que se autentifique por claves RSA o DSA. Hay muchas posibilidades.

Administrando usuarios

Añadir un usuario para únicamente hacer túneles es muy sencillo:

# useradd -g users -c 'Usuario Tunel' -d /nonexistent -s /sbin/nologin usuario

# passwd usuario

Donde usuario será el nombre del usuario en cuestión.

La primera orden crea a un usuario que nunca podrá hacer login*, y en la segunda le damos una contraseña.

Aunque este usuario nunca podrá hacer login en blackshell, sí que podrá crear túneles SSH, con lo que hay que tener cuidado con todos servicios que tenemos escuchando en el nodo (incluso en localhost). En este caso que el nodo sale a internet vía LAN, también hay que andar con ojo con los servicios que ofrecen las máquinas de la red local.

* Algunos clientes, como PuTTY en versiones viejas, necesitan hacer login para que el túnel quede abierto, por lo que no se podrán crear clientes solo para hacer túneles. Hay ports de OpenSSH para casi cualquier sistema, hasta para Win32.

Todo listo

Como se puede observar todos los pasos son muy sencillos para tener nuestro nodo funcionando con OpenBSD en la configuración básica.

El acceso a internet con NAT tampoco es muy complicado, aunque lamentablemente no es seguro.

Por último hemos visto como Squid con túneles SSH es una opción válida que se ajusta a nuestras necesidades de maravilla, tanto autentificando los usuarios, como encriptando las conexiones. Aunque sea a cambio de una mayor carga en la máquina que gestiona el punto de acceso que el acceso mediante NAT (lógico XD), no es nada que un P100 no pueda soportar dignamente.

Espero que esta receta permita que los que quieran experimentar con redes wireless y este fantástico sistema operativo lo tengan un poco más fácil (si cabe), y puedan aprovecharse un poco de mi experiencia.

La configuración actual de blackshell (Febrero de 2004) no se parece en nada a lo descrito en este documento. Muchas cosas han cambiado, no obstante considero que este texto sigue teniendo validez como referencia.

^ top

Enlaces

Aquí hay algunos enlaces de interés:

^ top

$Id: index.html,v 1.11 2005/11/04 08:27:11 reidrac Exp reidrac $

Copyright © 2003 Juan J. Martínez <REMOVE.MEreidrac@AND.MEusebox.net>
Se permite la libre copia y distribución de este documento, por cualquier medio, siempre y cuando se mantenga esta nota de copyright en todas las copias.

En caso de copiar un fragmento de este documento, se agradecería que se citara la fuente.