Organizacion de las Redes Wireless - v1.2 Simon Mudd C/Hermanos Garcia Noblejas 5, Esc 1, 2B Madrid 28037 Espana/Spain sjmudd@pobox.com Joaquin Bejar Garcia C/Barberan y Collar 22, 1-o D Alcala de Henares 28805 Espana/Spain shuodata@terra.es Angel Moncada Fernandez Paseo de la Estacion 1, 1-o C Alcala de Henares 28807 Espana/Spain c4n99@hotmail.com $Author: sjmudd $ $Date: 2005/03/28 10:12:34 $ $Revision: 1.1 $ Copyright (c) 2001 por Simon Mudd y MadridWireless Copyright (c) 2002 por Simon Mudd, Angel Moncada "c4n", Joaquin Bejar "ShuoData" Redistribution and use in source (SGML DocBook) and 'compiled' forms (SGML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code (SGML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. 2. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Importante: THIS DOCUMENTATION IS PROVIDED BY THE AUTHORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Se ha aumentado enormemente el interes en las redes inalambricas en los ultimos anos, especialmente desde hace poco ya que el coste del hardware ha bajado y su disponibilidad ha mejorado de manera significativa. Este documento intenta marcar las pautas generales que cada grupo wireless en Espana podria seguir para conseguir un diseno adecuado de sus propias redes y para permitir la facil conexion con las redes de otros grupos. If there is interest in me producing a version of this document in English then please send me a note. ---------------------------------------------------------------------- Tabla de contenidos 1. Estado de este Documento 2. Introduccion 3. Forma de una red Wireless 4. Direcciones IP 5. Hosts, dominios y DNS 6. Alta de un nodo nuevo 7. Enrutamiento 8. Topologia de la Red 9. Firewalls, Seguridad, QoS, NAT y enrutamiento con Internet 10. Robot de actualizacion de DNS 11. User Authentication 12. Roaming 13. Hardware 14. Grupos Wireless 15. Comunidades 16. Referencias ---------------------------------------------------------------------- 1. Estado de este Documento Este documento especifica unas recomendaciones de los entandares a utilizar para la construccion de las distintas redes wireless en Espana. La distribucion de este documento esta permitido sin limitacion. Se pide comentarios y sugerencias para la mejora de este documento. Se puede encontrar la ultima version de este documento en http://www.pobox.com/~sjmudd/wireless/network-structure. ---------------------------------------------------------------------- 2. Introduccion Este documento intenta dar informacion sobre la estructura de las redes wireless, las cuestiones de como se forman los nodos y sus clientes y el enrutamiento de trafico IP entre diferentes nodos llevados por una persona o un grupo. Teniendo en cuenta que distintos grupos estan trabajando con el mismo fin, de montar redes wireless, el documento tambien intenta dar informacion sobre las maneras de conectar los grupos entre si y las posibles conexiones con Internet. Este documento podria usarse como base para la implementacion de redes wireless en zonas o ciudades con el minimo de modificaciones. El uso de unas normas y estructuras de redes comunes simplifica las tareas de interconexion de estas redes y minimiza los labores de gestion comunes en cada red. ---------------------------------------------------------------------- 3. Forma de una red Wireless Cada grupo wireless sera compuesto de una red de redes inalambricas conectadas entre si para crear una red metropolitana (MAN) en la zona de su ubicacion. Existen varios protocolos de comunicacion inalambrico de los cuales 802.11a, 802.11b, 802.11g y AX25 son ejemplos. En la actualidad 802.11b parece ser el mas comun debido en parte al coste y acceso al hardware. Cada red wireless estara compuesta de varios PCs o otros aparatos que se comunican directamente utilizando el protocolo IP. Se llamara a esta red un nodo. Dentro de cada nodo habra al menos un host configurado para conectarse de la manera mas conveniente a otros nodos de la red de su grupo. Los nodos pueden ser interconectados por enlaces de radio u otros medios. Se puede usar el termino nodo tambien para referirse al host que gestiona su propia red. Los clientes de esta red, la gente que se conectara desde sus casas o oficinas conectaran a los nodos, asi formando la red completa. Los nodos sin clientes forman la infraestructura de cada grupo. Tipos de Nodos de una red wireless. ---------------------------------------------------------------------- 4. Direcciones IP En este documento se habla exclusivamente del uso de IP version 4, ya que en este momento se requiere una infraestructura minima de red y es mas facil formar una red utilizando un protocolo y herramientas ya probados. No obstante, seria posible implementar una red IPv6 al mismo tiempo que la red IPv4 sin llegar a influir. Tambien es cierto que el futuro de las redes y de Internet es IPv6 y ya existen redes complejas y en produccion basadas exclusivamente en IPv6. La recomendacion sobre la metodologia de asignacion de direcciones IPv6 experimentales queda por definirse. Para montar una red wireless se requiere el uso de unas direcciones IP de uso comun. El direccionamiento IP que se podria utilizar y como se podria repartir tanto a nivel global (de los distintos grupos wireless en Espana), como a nivel grupo wireless o a nivel de un nodo de un grupo en concreto se explica en las siguientes secciones. ---------------------------------------------------------------------- 4.1. Direcciones IP - Globales para un Grupo Wireless Cada grupo wireless necesita de un rango de direcciones IP para posibilitar la conexion de los nodos con los equipos de los clientes, la conexion de los nodos entre si y finalmente para posibilitar la conexion con otros grupos wireless, otros entes externos y Internet. Varios grupos wireless internacionales que ya han montado sus propias redes wireless han empezado a usar direcciones IPs privadas por la facilidad de usar estas direcciones IP sin tener que consultar a nadie y para evitar pagar por ellas. Al pedir direcciones IP oficiales existe un compromiso de conectar estas direcciones IP a Internet y de justificar el numero pedido y su uso, algo a menudo dificil para proyectos un proyecto nuevo. En este momento no se considera necesario esta peticion de direcciones IPs publicas aunque no se descarta la posibilidad en el futuro. Los tres grupos de direcciones IP reservados para uso privado son: * 10.0.0.0/8 * 172.16.0.0/12 * 192.168.0.0/16 El grupo RedLibre ha planteado un uso de direcciones IP en todo Espana utilizando la red 10.0.0.0/8, dividiendo este rango entre diferentes provincias y ciudades. Ver http://www.redlibre.net/direccionamiento.php para mas informacion. En principio su planteamiento parece correcto y se puede aplicar. Es necesario asegurar que las direcciones IP de un grupo no coinciden con las de otro porque asi se haria imposible la interconexion de los grupos. Se recomienda que si un grupo nuevo necesita de un grupo de direcciones IP que habla con el resto de los grupos wireless en Espana para conseguir un rango de direcciones que evitara conflictos en el futuro. Un ejemplo de esto es el caso de Madrid, donde RedLibre, MadridWireless y AlcalaWireless necesitan de direcciones IP que no llevan conflictos. RedLibre habia planteado la asignacion de direcciones en Madrid utilizando el rango 10.0.0.0-10.15.0.0, inicialmente para sus propias redes. Sin embargo habia adaptado este planteamiento para que otros grupos podrian utilizar un subrango de direcciones IP, de mutuo acuerdo y los dos grupos no se interferiran entre si. De esta manera cualquier red wireless que pueda aparecer en Espana o en una ciudad grande se asegura un rango de direcciones IP propias y libres permitiendo ademas la futura conexion entre estas. Este punto es muy importante. Recientemente ha llegado a mi atencion una propuesta mundial de direcciones IP por diferentes grupos wireless. Esta propuesta de direccionamiento tiene conflictos con la propuesta del grupo Red Libre por lo que queda pendiente ver como mejor resolver esta situacion. Como se vera mas adelante tambien sera necesario asignar direcciones IP para la conexion de los nodos entre si, para formar el backbone de la red de un grupo wireless. En este caso se usara el rango de direcciones IP 172.16.0.0/12. Se usara otro subrango, todavia sin definir de las direcciones IP 172.16.0.0/12 para la asignacion de puntos de interconexion entre diferentes grupos. En el caso de que un grupo agotara del bloque de direcciones IP antes acordado y necesite una posterior asignacion de direcciones el grupo debe volver a hablar con el resto de los grupos para acordar un nuevo bloque de direcciones que podria usar, siguiendo el esquema propuesto por RedLibre o otro acordado entre los distintos grupos si no hay inconveniente. ---------------------------------------------------------------------- 4.2. Direcciones IP - Asignadas a un nodo 4.2.1. Asignacion local de IPs La asignacion local de las IPs a cada nodo, es decir, el direccionamiento privado que cada nodo utilizara dentro de un grupo, estara centralizado en unos miembros de cada grupo wireless. Estos miembros decidiran los procedimientos de asignacion de IPs a un nodo y los requisitos que los nodos deben cumplir para darse de alta. ---------------------------------------------------------------------- 4.2.2. Asignacion estandar A cada nodo se le asignara un bloque de direcciones que vienen del bloque global de direcciones IP mencionado en la seccion anterior. Cada nodo consistira de un bloque de al menos 32 direcciones, de las cuales 30 seran utiles. En principio una direccion sera utilizada por el propio nodo/router dejando las direcciones restantes disponibles para otros fines como por ejemplo la asignacion a clientes. Al considerar el alcance habitual de las senales que se estara utilizando este rango de direcciones probablemente sera mas que suficiente. Los bloques de 32 direcciones estaran compuestas de la siguiente forma: +-------------------------------------------------------+ | 10.x.y.0 | Direccion IP de la red | |-------------+-----------------------------------------| | 10.x.y.1 | Direccion IP del router o nodo | |-------------+-----------------------------------------| | 10.x.y.2-30 | Direcciones IP de los clientes del nodo | |-------------+-----------------------------------------| | 10.x.y.31 | Direccion IP de broadcast | +-------------------------------------------------------+ La mascara de red en este caso seria 255.255.255.224. Cada red de clase C, 10.x.y.0/24, se compondra de 8 sub-redes cuyo ultimo digito termina en .0, .32, .64, .96, .128, .160, .192 y .224. La asignacion a clientes de las direcciones IP 2-30, podria realizarse de cualquier manera, pero lo mas practico en una red wireless seria la asignacion dinamica utilizando el protocolo DHCP, asignado por el nodo/router. La ventaja del uso del protocolo DHCP para el cliente es que en el momento de asignarle la direccion IP al cliente tambien se le puede dar informacion adicional como: * la direccion IP del router dentro de la red * las direcciones IP de los servidores de nombres a utilizar * el nombre del dominio de la red, o su nodo Asi se minimiza las necesidades de configuracion de su equipo. ---------------------------------------------------------------------- 4.2.3. Asignacion de bloques mas grandes La asignacion de bloques de 32 direcciones IP puede ser insuficiente en zonas urbanas con mucha densidad de poblacion, por lo que sera necesario considerar la asignacion de bloques de 64, 128 y hasta 256 direcciones IP, cada bloque con su direccion de red y mascara de red apropiadas. En este sentido se recomendaria la asignacion de estos bloques grandes solo cuando se le considera necesario, aunque en principio seria una decision local de cada grupo. La estructura del bloque de direcciones grande debe ser la misma que se ha visto en la seccion anterior, con la diferencia que se amplia el numero de direcciones IP que se asignan a los clientes. ---------------------------------------------------------------------- 5. Hosts, dominios y DNS Se plantea la utilidad de utilizar el DNS para nombrar cada direccion IP relacionada con el nodo, de permitir la traduccion de un nombre de host a un IP y viceversa. En principio cada grupo wireless sera responsable por su propio dominio y la asignacion de nombres a las direcciones IP de sus nodos. Si se ofrece un servicio de este tipo se recomienda que el servidor DNS para este dominio tambien sera disponible en Internet. En este documento se representara el nombre de dominio utilizado de manera generica como ${GROUP}, pero podria ser por ejemplo: redlibre.net, madridwireless.net o un subdominio de un dominio gestionado por el grupo correspondiente. Todas los nodos y clientes se podrian nombrar de una forma parecida para facilitar su identificacion: Primero se dara un nombre a cada nodo: NODE="nodo". El nombre del nodo debe ser corto. Seria conveniente que cada grupo tenga una pagina web publica con informacion de sus nodos y la configuracion y ubicacion de cada uno. De esta manera los posibles clientes podrian localizar el nodo mas cercano. ---------------------------------------------------------------------- 5.1. Resolucion de nombres DNS Dentro de cada nodo se nombrara todos los hosts/nodos/clientes como un subdominio de ${NODE}.${GROUP}, de la forma: "nombre".${NODE}.${GROUP}. Los nombres recomendados a incluir en el DNS seran los siguientes: +------------------------------------------------------------------------+ | Nombre | Descripcion | Direccion IP | |-----------+------------------------------------------+-----------------| | network | la direccion de la red | 10.x.y.0 | |-----------+------------------------------------------+-----------------| | router | el router principal del nodo | 10.x.y.1 | |-----------+------------------------------------------+-----------------| | client1 | la direccion ip de primer cliente del | 10.x.y.2 | | | nodo | | |-----------+------------------------------------------+-----------------| | ... | | | |-----------+------------------------------------------+-----------------| | client29 | la direccion ip del ultimo cliente del | 10.x.y.62 | | | nodo | | |-----------+------------------------------------------+-----------------| | broadcast | la direccion de broadcast de la red | 10.x.y.63 | |-----------+------------------------------------------+-----------------| | netmask | el netmask de la red | 255.255.255.224 | +------------------------------------------------------------------------+ Debemos destacar que el alta de esta informacion en el DNS es para un motivo sencillo: la ayuda con la identificacion del trafico IP dentro de la red. Es muy util. Se podria asignar en el DNS otros nombres de host, y esta posibilidad sera opcional y cuestion del gestor del nodo correspondiente si es un subdominio de su nodo o del gestor de DNS global si es un nombre "global". Por ejemplo la asignacion del nombre www.nodo23.madridwireless.net sera cuestion del gestor del nodo23 de MadridWireless, y la signacion del nombre www.madridwireless.net, como es logico, del administrador de madridwireless.net. ---------------------------------------------------------------------- 5.2. Resolucion DNS Inversa A la vez que existira un relacion nombre -> ip, tambien se configurara un servidor de nombres para permitir la resolucion inversa: ip -> nombre. Este uso es muy comodo para la resolucion de problemas y para identificar la fuente de trafico IP en la red. Asi que hara falta unos registros del tipo: 0.0.64.10.in-addra.arpa. IN PTR network.${NODE}.${GROUP}. 1.0.64.10.in-addra.arpa. IN PTR router.${NODE}.${GROUP}. ... El servidor de nombres para resolver la direcciones inversas esta todavia pendiente de definir. Debemos indicar que en el caso de la resolucion del DNS inversa, podria ser necesario disponer de un servidor DNS comun que sea capaz de resolver direcciones ip a nombres para mas que un grupo. Es una situacion diferente a la resolucion "normal" donde cada grupo lo puede gestionar de manera independiente. [Se podria delegar el DNS inverso tambien: es algo que se debe estudiar en el futuro si esta opcion conviene mas.] Se surgiere que NO se modifique el DNS inverso, al menos para los nombres estandar: network, router y broadcast para cada nodo. Para facilitar la gestion de estos multiples nombres se plantea el uso de unas herramientas web o email, como el robot del dominio ampr.org. Ver abajo para una explicacion de su funcionamiento. ---------------------------------------------------------------------- 6. Alta de un nodo nuevo Los pasos a realizar para pedir el alta de un nodo nuevo en los distintos grupos wireless estaran determinados en otro documento y hara falta contactar con el grupo correspondiente. El alta de un nodo iniciara un proceso de creacion de los nombres recomendables en el DNS. Al ser posible se hara en tiempo real, y de no ser asi se intentara actualizar la informacion de manera diaria. Al realizar un alta de un nodo seria util tener los siguientes datos: * name: Nombre de nodo (alfanumerico, utilizable en el DNS) * description: Descripcion de nodo (texto libre) * admin: Nombre de Gestor de nodo * password: password encryptado para actualizar datos * email: Email de gestor de nodo * tel: Telefono de gestor de nodo (*) * location: Ubicacion del nodo: formato libre, pero sugeriendo "zona, ciudad, codigo postal, pais" * frequency: Frecuencia/canal utilizado * type: tipo de nodo (AP/Ad-hoc) * comments: observaciones (*) * ip-range: rango ips * dns-delegated: dns delegado: si/no, (inicialmente no) * dns-main: servidor dns principal: direccion ip (*) * dns-secondary: servidor dns secundario: direccion ip (*) * links: lista de nombres de los nodos con conexion directa (*) * internet: enlace con Internet (si/no) (*) * created: fecha/hora alta de nodo * deleted: fecha/hora baja de nodo [normalmente sin datos] * change-last: fecha/hora ultimo cambio de datos "del nodo" * change-by: persona/email ultimo cambio de datos "del nodo" * change-num: numero de cambio (numero secuencial de cambio) Los campos marcados con (*) serian opcionales. Toda esta informacion se podria guardar dentro del propio DNS, sin tener que utilizar bases de datos externos, dando cada campo el nombre indicado y asignandolo a un registro de tipo TXT. Sin embargo por motivos de privacidad puede que no toda informacion se hace publica y al ser asi haria guardarla en alguna base de datos. Por ejemplo sabiendo que hay un nodo23 para grupo ${GROUP} el comando dig txt admin.nodo23.${GROUP} nos daria: admin.nodo23.${GROUP} IN TXT "Simon Mudd" Al modificar cualquier informacion correspondiente al nodo se modificaria los ultimos 3 campos. Con los datos indicados arriba se podria generar la siguiente informacion DNS de manera automatica: (1) Informacion del dominio Los registros de direccion IP, como se ha indicado anteriormente. network.${NODE}.${GROUP} IN A 10.x.y.0 router.${NODE}.${GROUP} IN A 10.x.y.1 cliente1.${NODE}.${GROUP} IN A 10.x.y.2 ... cliente29.${NODE}.${GROUP} IN A 10.x.y.62 broadcast.${NODE}.${GROUP} IN A 10.x.y.63 netmask.${NODE}.${GROUP} IN A 255.255.255.224 (2) Informacion inversa X registros tipo PTR para permitir la resolucion del hostname desde el IP: z.y.x.10.in-addra.arpa. IN PTR xxx.${NODE}.${GROUP}. ---------------------------------------------------------------------- 7. Enrutamiento Dada la posibilidad de existir muchos nodos en un grupo wireless y de tener enlaces con otros grupos con intereses parecidos la gestion de las rutas entre las diferentes redes sera bastante compleja. ---------------------------------------------------------------------- 7.1. Enrutamiento dinamico vs. estatico Basicamente existen dos maneras de enrutar a otros hosts fuera del nodo local y son utilizando enrutamiento estatico o enrutamiento dinamico. Cada metodo tiene ventajas e inconvenientes, pero cuando una red crece finalmente el enrutamiento dinamico es la unica manera factible de gestionar la red. Por este motivo se plantea la necesidad de utilizar protocolos de enrutamiento dinamico en vez de usar rutas estaticas en todos los nodos. Existen programas para llevar el enrutamiento dinamico en la mayoria de los sistemas operativos, por lo que no debe ser complicado instalarlos en un nodo. Para sistemas UNIX existe un programa, zebra, que puede gestionar los protocolos de enrutamiento estaticos mencionados en este documento. Ademas zebra es software gratuito con licencia GPL. Hay que destacar que el uso de estos protocolos sera transparente al usuario final y sera exclusivamente un tema para los gestores de nodos en caso que el nodo conecte a otros. Desde el punto de vista del cliente el enrutamiento sera resuelto mediante la configuracion DHCP automatica cuando el cliente conecta al nodo. Como no es obligatorio que un nodo conecta a otros, el uso de estos protocolos y el enrutamiento dinamico no es obligatorio. En algunos casos una ruta estatica puede ser suficiente para realizar la conexion. ---------------------------------------------------------------------- 7.2. Enrutamiento entre nodos Para realizar la conexion entre dos nodos se utilizara otro rango de direcciones IP, distintas a las direcciones de la propia red de un grupo wireless (10.x.x.x), utilizando conexiones punto-a-punto. Las IPs usadas para estas conexiones seran del bloque 172.16.0.0/12, empezando por 172.16.64.0/30 y continuando con 172.16.64.4/30, 172.16.64.8/30, ... segun el numero de enlaces usados. Siendo los enlaces punto a punto la mascara de red sera 255.255.255.252 y contendra 2 direcciones IP utiles (las direcciones IP de los dos extremos). Debido al gran numero de redes que podrian existir dentro de cada grupo wireless el enrutamiento entre los distintos nodos sera bastante complejo. Para resolver este problema sera necesario utilizar un protocolo de enrutamiento dinamico de tipo IGP (Interior Gateway Protocols) como RIP (Routing Information Protocol) o OSPF (Open Shortest Path First), el ultimo siendo un protocolo mas complejo y sofisticado. Si la red de un grupo esta compuesto de un numero reducido de nodos se podria contemplar el uso de enrutamiento estatico. El uso del enrutamiento dinamico evitara las modificaciones manuales y asegurara que la conexion a nuevos nodos sea inmediata en toda la red. Por este motivo se recomienda su uso cuando sea posible. Por los mismos motivos elaborados anteriormente con las direcciones IP de los clientes, el uso de las direcciones IP 172.16.0.0/12 utilizadas para interconectar los nodos dentro de un grupo wireless NO deben coincidir con direcciones IP utilizadas por otros grupos wireless. Si esto ocurriera no afectaria al enrutamiento entre las direcciones IP de los clientes, pero si imposibilitaria la depuracion de trafico que se mueva de la red de un grupo a la red de otro, y por lo tanto no se recomienda en absoluto. Sera necesario elaborar otro documento que explica la configuracion minima necesaria para poner en marcha un programa como zebra que enruta utilizando los protocolos IGP como RIP o OSPF, aunque debido a la flexibilidad que ofrece el segundo protocolo se preferiria el uso de OSPF. ---------------------------------------------------------------------- 7.3. Enrutamiento con otros grupos Se puede plantear el uso del mismo tipo de protocolos (IGP) para conectar con redes externas a un grupo wireless pero probablemente seria mas apropiado el uso de protocolos EGP (Exterior Gateway Protocol). Este es el procedimiento habitual al menos en el Internet. Siempre que se plantea la conexion con sistemas externos a un grupo wireless en otras ciudades, paises o zonas hay que asegurarse de que no haya conflictos de direcciones IP o de otro tipo importante. El enrutamiento con estas zonas probablemente debe realizarse a traves de protocolos EGP como BGP (Border Gateway Protocol) y sera una cuestion de estudiar en el futuro. La ventaja de este enfoque es que cada sistema sera autonomo y no sera necesario conocer las rutas internas de sistemas externos, solo los puntos de acceso a ellos y las redes contenidas alli dentro. Las direcciones utilizadas para la interconexion de diferentes grupos quedar por definirse. Lo mas apropiado seria la asignacion de un rango de direcciones explicitamente para este fin y probablemente utilizando un rango de las direcciones IP 172.16.0.0/12. Este rango puede ser bastante reducido porque no se espera un gran numero de interconexiones entre los diferentes grupos. Se tendra que elaborar un documento de configuracion para explicar la mejor forma de configurar un nodo que actua de enlace a otros grupos. En cualquier caso si un grupo wireless se considera como sistema autonomo (AS) se le asignaria un numero usando algun codigo que identifique la localizacion. Como sera habitual la mayoria de los casos el grupo no tendra un numero AS propio. Se recomienda que el grupo que necesita de un nuevo numero AS contacte con los otros grupos wireless y se asigna un numero no utilizado dentro del rango de AS privados recomendados en el RFC 1930. Este rango de numeros AS es 64512-65534. Seria util tener un registro de los numeros AS asignados y utilizados por los distintos grupos wireless en un lugar publico. El numero AS en si no es importante, simplemente es un identificador de cada sistema autonomo. De la misma manera que hay que evitar duplicados de direcciones IP es imprescindible que un nuevo grupo no usa un numero de AS ya asignado, porque esto llegara a confundir los routers de manera considerable. ---------------------------------------------------------------------- 7.4. OSPF Open Shortest Path first (OSPF) es un protocolo de routing link-state no propietario, esto quiere decir principalmente dos cosas: Primero que es de libre uso y suele estar soportados por la mayoria de los equipos destinados a ofrecer servicios a la red y Segundo el ser un link-state quiere decir que a diferencia de RIP o IGRP que son Distance-vector, no mandan continuamente la tabla de rutas a sus vecinos sino que solo lo hacen cuando hay cambios en la topologia de red, de esta forma se evita el consume de ancho de banda innecesario. En un cambio de topologia OSPF envia el cambio inmediatamente de forma que la convergencia de la red es mas rapida que en los distance-vector donde depende de timers asignados, de forma que en un link-state el tiempo de convergencia puede ser de 4 o 5 segundos segun la red en RIP puede se de 180 segundos. La topologia de OSPF esta basada en areas conectadas de forma jerarquica. El sistema autonomo de OSPF puede ser fraccionado en diferentes areas y todas las areas estas conectadas al area de Backbone o area 0 representada en la siguiente figura: Open Shortest Path First (OSPF) Los router que forman parte de la red con OSPF se les denomina segun su situacion y su funcion dentro de la red de la siguiente forma: Internal router: Un router con todas las redes directamente conectadas a la misma area. Estos solo mantienen una copia del algoritmo de routing. Area Border Router: ABRs es un router que une un area al area 0 comparte la informacion entre las dos area y gestiona que redes se tiene que compartir entre ellas. Backbone Routers: Son los routers que pertenecen al area 0 y responsable de la propagacion de las redes entre distintas areas. Autonomous System Boundary Routers: Son routers conectados a otros AS o Internet. Tambien suele ser el router que intercambia entre protocolos de routing IGP y EGP. ---------------------------------------------------------------------- 7.5. OSPF Wireless En el siguiente dibujo podemos observar las distintas formas en que podriamos conectar las areas o nodo a nivel de routing a partir de redes wireless. Tambien se ha incluido una opcion por VPN que resultaria muy util sobre todo en la union de distintas redes wireless entre ciudades o cuando la distancia entre dos nodos resulta muy larga y es necesaria la comunicacion por medio de Internet. De esta forma se definiria un area 0 donde se situaria el nodo principal y preferiblemente con la salida a Internet con mayor ancho de banda, y a donde se conectarian las demas redes. En el caso de que existan nodos que no se puedan unir directamente al area 0 normalmente o por VPN se utilizara un virtual-link para unirla al area 0. ---------------------------------------------------------------------- 7.6. OSPF vs. Otros Protocolos En ocasiones puede que existan casos en que por cierto APs o ciertos sistemas operativos no se soporte OSPF, en tal caso el se podra utilizar otro protocolo como RIP siempre que sea classless es decir version 2 en el caso de RIP o EIGRP en el caso de Cisco IGRP. A pesar de todo el ABR debera soportar OSPF para no perder la concordancia en el resto de la red. Sera importante a la hora de unir redes completas utilizar sumarizacion de redes siempre que sea posible y evitar que se solape el direccionamiento. En Redlibre se puede ver el direccionamiento de una clase A asignada a las distintas ciudades y provincias dentro de Espana. ---------------------------------------------------------------------- 7.7. BGP El protocolo Border Gateway Protocol (BGP) esta definido en el RFC1771 y actualmente esta en su version numero 4. Es el protocolo mas popular de los protocolos EGP y se utiliza casi sin cambios desde el ano 1995. La funcion de BGP es similar a la funcion de un router IGP como OSPF que aprende las rutas mas optimas para llegar al resto de los nodos y redes dentro de un sistema autonomo (AS). La diferencia es que BGP trabaja con redes de diferentes sistemas autonomos, publicando sus propias redes y determinando a traves de que otro sistema autonomo se puede llegar a un tercero. BGP tambien tiene varias funciones de filtrado para permitir informar o no sobre las rutas que tiene y a que router externo AS lo dice. Debido a esta funcionalidad se recomienda el uso de BGP para interconectar distintos grupos wireless, en vez de seguir el uso de un protocolo IGP como OSPF. ---------------------------------------------------------------------- 8. Topologia de la Red Hasta ahora se ha hablado de las direcciones IP que se utilizaran dentro de la red para conectar los clientes, los nodos y los distintos grupos. Tambien se ha hablado del enrutamiento entre estos componentes, pero solamente en cuanto a los protocolos utilizados y no la forma de interconectar los distintos nodos. La interconexion de nodos en una red compuesta de mas de cinco nodos puede realizarse de muchas maneras. En cuanto el numero de nodos aumente tambien va aumentando las posibles maneras de interconectar la red. Sin embargo una estructura aleatoria no es la mas indicada por muchos motivos. Normalmente cuando se disena una red se estudia de antemano su trafico, el numero de maquinas conectadas, las necesidades de los usuarios y varias cosas mas para organizar la estructura para dar el mejor servicio posible. Las redes wireless al crecer de una manera no controlada requeriran un diseno o ajuste posterior para que se estructura mantenga cierta orden. Los siguientes puntos son los que se debe tener en cuenta cuando disenamos una red: * Evitar la congestion en un punto unico de la red. * Reducir el numero de saltos entre un nodo y otro. * Intentar tener multiples enlaces a la red a traves de distintos nodos. Si uno falla se puede usar el otro. Si ademas se utiliza enrutamiento dinamico este cambio sera transparente. * Utilizar herramientas para monitorizar la red y asi poder prevenir problemas futuros. * Separar el trafico de clientes con el trafico con otros nodos. * Evitar en cuanto sea posible las configuraciones manuales y utilizar configuraciones estandar para los diferentes componentes instalados. * Utilizar enlaces entre nodos con el mayor velocidad de transmision posible (por radio). * Mantener una buena comunicacion entre los gestores de los nodos. Normalmente la gente que lleva la red en una compania gestion toda la red: en el caso de una red wireless cada gestor gestiona su nodo por lo que la comunicacion entre gestores es muy importante para minimizar el tiempo necesario para resolver problemas que podrian surgir. Sera importante durante las primeras fases de crecimiento de la red discutir la adicion de nuevos nodos y el mejor punto de conexion como decidir en una herramientas de monitorizacion de varios aspectos de la red que se podria utilizar para comparar el comportamiento de sus diferentes partes. ---------------------------------------------------------------------- 9. Firewalls, Seguridad, QoS, NAT y enrutamiento con Internet 9.1. ?Necesitamos un firewall? Hasta ahora se ha hablado de las redes wireless como las unicas redes que existian. Realmente muchos de los potenciales gestores de nodos tendran su nodo conectado a otras redes, como una red interna de empresa o de casa, o quiza a Internet. En este sentido la informacion que se mueve fuera de las redes de radio podria necesitar proteccion por una de varias razones. Puede ser que el gestor no quiere que alguien entre en su propia red interna, pero no le importa ofrecer el servicio radio y los enlaces a otros nodos sin problema. Para solucionar este tipo de problema la unica solucion razonable es la de poner un firewall, una tecnica claramente explicada en varios sitios en Internet, cuyo objetivo es simplemente filtrar el trafico que esta pasando entre las distintas redes de un nodo, filtrando y dejando pasar o no la informacion que parece oportuno. Partiendo de la base de que queremos montar un firewall, tenemos que tener en cuenta varias cosas, para poder ponerlo en marcha. Hay varias soluciones posibles, algunas son dependiente del sistema operativo utilizado y ademas hay soluciones comerciales que funcionan en distintos sistemas operativos. En linux hay varias opciones que dependeran de la version del kernel instalado: las principales siendo IPCHAINS y IPTABLES. FreeBSD y las otras versiones de BSD tienen ipfw. La ventaja de estas opciones es que vienen con el propio sistema operativo aunque no siempre estan soportados por el kernel instalado por defecto. Ver los manuales correspondientes para mas informacion. Un enlace para configurar un firewall con IPTABLES en linux es http://www.boingworld.com/workshops/linux/iptables-tutorial/iptables-tutorial/iptables-tutorial.html Tambien existen varios documentos HOWTO para Linux que explican la configuracion de un firewall. Hay que seguir una serie de normas en la configuracion de un firewall, es decir, a partir de un diseno del nodo hay que tener en cuenta varios factores entre ellos: * los distintos interfaces a que el firewall esta conectado * las distintas redes y las direcciones ip asociadas conectadas al firewall * La deseabilidad que el trafico desde una red a otra pasa a traves un interfaz en concreto * Los distintos servicios IP permitidos o denegados (http, smtp, dns, ping) usando tcp, udp, icmp, etc. * Si es necesario convertir la direccion ip al salir del interfaz (NAT) a otra distinta Un firewall va a tener habitualmente las siguientes conexiones/redes a tratar: * Direcciones ip de la red de su nodo * Direcciones ip de la red de su grupo wireless * Direcciones ip de la(s) red(es) de enlace a otro(s) nodo(s) * Direcciones ip de su red interna * Un enlace a Internet (que usa el resto de las direcciones IP) Solamente viendo la matriz de posibles conexiones entre una red y otra, y teniendo en cuenta que tenemos que tratar trafico ip en los dos sentidos (de ida y vuelta), nos damos cuenta que la configuracion de un firewall es bastante compleja. La mayoria de las configuraciones de un firewall permiten que no solo podemos decidir si aceptar o denegar el trafico a traves del firewall, pero tambien podemos guardar en un log los intentos de hacer pasar trafico IP que esta prohibida. La politica que hay que seguir con los logs que genera el firewall es mantenerlos por un tiempo determinado, quiza 3 meses, por si acaso ocurriera algun incidente tener un registro de lo ocurrido. Se deberia comentar que un nodo no deberia filtrar trafico cuya fuente y destino es de su propia red wireless, porque esto obstruiria el correcto funcionamiento de la red. Si un grupo wireless decide conectarse a otro grupo entonces tampoco deberia estar filtrado el trafico con el otro grupo wireless. Si varios nodos tienen configurados un firewall se les deberia avisar con tiempo suficiente para poder cambiar la configuracion de su firewall antes de confirmar la interconectividad con el otro grupo. Una recomendacion a hacernos, es la utilizacion de un IDS (Detector de Intrusion) ya que facilitaria las cosas al tener que detectar un intento de ataque, bien desde nuestra red wireless o desde otras redes wireless externas. Existen varios IDS que se podria utilizar entre ellos es el snort http://www.snort.org y la politica a seguir sobre los logs del IDS seria la misma que se aplica en el caso de los firewalls. ---------------------------------------------------------------------- 9.2. Conexion a Internet Mucha gente esta interesada en las redes wireless como medio barato de acceder a Internet usando la conexion de otro. En principio se puede ofrecer la conexion a Internet desde un nodo pero tenemos que tener en cuenta que todos las conexiones de esta manera requeriran la modificacion de la direccion IP de origen (un proceso que se llama NAT) al menos cuando se usan direcciones IP privadas. En estos casos tampoco sera posible conectar desde Internet "hacia dentro" por el mismo motivo: las direcciones IP de las redes wireless no son publicas y desde Internet no se puede enrutar a una red privada. No obstante la conexion a Internet, incluso con NAT, permite el uso de un monton de servicios como DNS, correo, web, ftp entre otros. Debemos tambien hacer constar que la velocidad maxima de las redes wireless 802.11b permite hasta un 11Mb/s algo bastante superior a la velocidad tipica de una conexion a Internet desde casa que incluso con ADSL no suele pasar de 256kb/s de entrada. Asi que los que deciden ofrecer acceso a Internet podrian ver su conexion saturada por los usuarios wireless si no toman medidas oportunas. ---------------------------------------------------------------------- 9.3. Multiples Rutas por defecto Finalmente se menciona que no solo existira la posibilidad de tener acceso a Internet sino que este servicio podria estar ofrecido en varios puntos de la red wireless. La gestion de las multiples rutas dentro de la red hacia la ruta por defecto puede complicarse mucho y haria faltar determinar la mejor forma de su gestion. ---------------------------------------------------------------------- 9.4. QoS Quality of Service va aqui ---------------------------------------------------------------------- 10. Robot de actualizacion de DNS Una manera de evitar el mantenimiento manual de informacion del DNS seria usar un robot que permite la actualizacion de la informacion de manera remota. Se podria "controlar" el robot via email, o quiza via web y seria algo que haria falta estudiar en mas detalle. Un ejemplo que se usa en la actualidad es el robot del dominio ampr.org, que gestiona la actualizacion de los nombres de host e IPs, todo via email. Se envia un email a la direccion email del robot enviando comandos en un formato determinado. Basado en el robot DNS del dominio ampr.org he escrito uno algo mas sofisticado, que permite los siguientes comandos: 1. Anadir una direccion IP, registro de correo, gestor de nombres, registro de texto o cname nuevo nombre ADD A 1.2.3.4 nombre ADD CNAME otro-nombre nombre ADD MX prioridad nombre-mx nombre ADD NS servidor.de.nombres nombre ADD TXT "algun texto" 2. Borrar los mismos datos nombre DEL A 1.2.3.4 nombre DEL CNAME otro-nombre nombre DEL MX prioridad nombre-mx nombre DEL NS servidor.de.nombres nombre DEL TXT "algun texto" 3. Visualizar la informacion guardada nombre INFO nombre ? Despues de realizar cualquier modificacion el robot confirme sus acciones y finalmente manda un mensaje al originador del mensaje con los resultados de sus acciones. El formato tal y como se usa en ampr.org no funcionaria para un grupo wireless por varios motivos: 1. Cada grupo wireless funciona de manera independiente - haria falta un robot por dominio. 2. Probablemente seria necesario asignar un password al gestor de un nodo y solo permitirle modificar datos de su nodo. 3. Haria falta tener unos passwords que permiten la modificacion de datos globales (de un grupo wireless), limitando estos accesos a un grupo de personas que tiene control global sobre el dominio. 4. Lo ideal seria que este robot estuviera alimentado de manera automatica a traves de una aplicacion que asignara direcciones IP nuevas a un nodo y que generara los datos nuevos a incluir en el DNS. Como el robot ya existe si alguien esta interesado en utilizarlo que me mandan un email a . Actualmente una vez que se modifican los datos guardados se actualizara el fichero utilizado por el servidor de nombres y este actualiza los datos en seguida. Su uso requiere de perl y poco mas para que funcione correctamente. ---------------------------------------------------------------------- 11. User Authentication ---------------------------------------------------------------------- 12. Roaming ---------------------------------------------------------------------- 13. Hardware Los siguientes enlaces da informacion de hardware que se podria usar para ser un nodo o un cliente en un grupo wireless. * http://www.3com.com * http://www.cisco.com * http://www.orinocowireless.com * http://www.stechcomm.com ---------------------------------------------------------------------- 14. Grupos Wireless La siguiente lista incluye algunos de los grupos que estan trabajando en wireless dentro de Espana y el resto del mundo. ---------------------------------------------------------------------- 14.1. Grupos Wireless en Espana La siguiente lista de grupos y sus URLs indica el mejor sitio para empezar de encontrar informacion sobre cada grupo. La mayoria de los grupos mantienen listas de correo y hay cierta duplicidad de trafico entre las distintas listas. * Alcala Wireless http://www.alcalawireless.com * Barcelona Wireless http://www.barcelonawireless.net * MadridWireless http://www.madridwireless.net * Malaga Wireless http://malagawireless.xphera.net * http://www.palamos.net * http://www.pucelawireless.net * Redlibre http://www.redlibre.net * Santiago de Compostela Wireless http://www.scqwireless.com * Sevilla Wireless http://www.sevillawireless.net * Zaragoza Wireless http://www.zaragozawireless.net ---------------------------------------------------------------------- 14.2. Otros Grupos en el Mundo * CanadaWireless http://www.canada-wireless.net * IrishWan http://www.irishwan.org * BC Wireless http://www.bcwireless.net * http://www.nora-wireless.net * http://www.nycwireless.net * http://www.seattlewireless.net * France Wireless http://www.la-grange.net/2001/02/openwireless.html ---------------------------------------------------------------------- 15. Comunidades * Open Wireless Network Forum http://www.opennetworks.rg3.net * http://www.freenetworks.org * http://www.personalteco.net ---------------------------------------------------------------------- 16. Referencias BGP, Border Gateway Protocol * RFC 1771 RIP, Routing Internet Protocol * Version 1, RFC 1058 * Version 2, RFC 2453 OSPF, Open Shortest Path First * Version 2, RFC 2328 DHCP, Dynamic Host Control Protocol * RFC 2131 * R. Droms, "Dynamic Host Configuration Protocol", 3/97. http://www.dhcp.org Zebra, A routing software package for TCP/IP networks * http://www.zebra.org Wireless Router HOWTO * http://www.rage.net/wireless/wireless-howto.html Building Wireless Community Networks * O'Reilly and Associates, January 2002 * Rob Flickenger * ISBN 0-596-00204-1 Designing Large-Scale LANs * O'Reilly and Associates, January 2002 * Kevin Dooley * ISBN 0-596-00150-9 El protocolo 802.11b * http://standards.ieee.org/getieee802/portfolio.html?agree=ACCEPT ----------------------------------------------------------------------