Introducci´n a la Administraci´n de una Red Local basada
          o                   o
en Internet
Charles L. Hedrick
Tr...
1. El problema.                                                                                                        2

...
2. Asignaci´n de direcciones y enrutamiento.
           o                                                                 ...
3. Eligiendo una estructura de direcciones.                                                                 4



encuentra...
3. Eligiendo una estructura de direcciones.                                                                5



ordenador ...
3. Eligiendo una estructura de direcciones.                                                                 6



      Eth...
3. Eligiendo una estructura de direcciones.                                                               7



entre dos c...
3. Eligiendo una estructura de direcciones.                                                                 8



encontrar...
3. Eligiendo una estructura de direcciones.                                                                 9



  2. Tamb...
3. Eligiendo una estructura de direcciones.                                                                10



direcci´n...
3. Eligiendo una estructura de direcciones.                                                              11



servidor SL...
3. Eligiendo una estructura de direcciones.                                                            12



En la parte m...
4. Servicios a nivel de red, nombres.                                                                       13



Desafort...
4. Servicios a nivel de red, nombres.                                                                     14



Si estamos...
4. Servicios a nivel de red, nombres.                                                                      15



En la con...
5. Configurando el enrutamiento de cada ordenador                                                             16



concept...
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Intro admon-redes-v1.1
Upcoming SlideShare
Loading in …5
×

Intro admon-redes-v1.1

766 views
717 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
766
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Intro admon-redes-v1.1

  1. 1. Introducci´n a la Administraci´n de una Red Local basada o o en Internet Charles L. Hedrick Traducido por Juanjo Mar´ juanjo96@arrakis.es ın Maquetaci´n SGML por Paco Brufal pbrufal@ctv.es y Fernando ffddoo@openbank.es v 1.1, 27 de Julio o de 1999 Introducci´n para aquellos que pretenden administrar una red basada en los protocolos de red de Internet o (TCP/IP). ´ Indice General 1 El problema. 2 1.1 Terminolog´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ıa. 3 2 Asignaci´n de direcciones y enrutamiento. o 3 3 Eligiendo una estructura de direcciones. 4 3.1 ¿Debemos subdividir nuestro espacio en direcciones? . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Subredes y m´ltiples numeros de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . u 6 3.3 C´mo asignar las subredes o los numeros de red. . . . . . . . . . . . . . . . . . . . . . . . . . o 7 3.4 Trabajar con m´ltiples subredes ”virtuales”en una red. . . . . . . . . . . . . . . . . . . . . . . u 7 3.4.1 Otra forma de trabajar con m´ltiples subredes. . . . . . . . . . . . . . . . . . . . . . . u 8 3.4.2 M´ltiples subredes: Consecuencias en el Broadcasting. . . . . . . . . . . . . . . . . . . u 9 3.5 Eligiendo una clase de direcci´n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 9 3.6 Lineas IP y micro gateways: direcciones asignadas din´micamente. . . . . . . . . . . . . . . . a 10 3.6.1 L´ ıneas IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6.2 Micro gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 Servicios a nivel de red, nombres. 13 5 Configurando el enrutamiento de cada ordenador 16 5.1 Como enrutar los datagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2 Rutas fijas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3 Reconducir el enrutamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4 Otros m´todos para que los hosts encuentren rutas . . . . . . . . . . . . . . . . . . . . . . . . e 22 5.4.1 Espiar el enrutamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4.2 Proxy ARP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.4.3 Establecer nuevas rutas tras fallos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
  2. 2. 1. El problema. 2 6 Puentes y gateways 28 6.1 Dise˜os alternativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 29 6.1.1 Una red de l´ ıneas punto a punto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1.2 Tecnolog´ de los circu´ ıa ıtos de conmutaci´n. . . . . . . . . . . . . . . . . . . . . . . . . o 30 6.1.3 Redes de un s´lo nivel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 31 6.1.4 Dise˜os mixtos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . n 32 6.2 Introducci´n a las distintas tecnolog´ de conmutaci´n o ıas o . . . . . . . . . . . . . . . . . . . . . 32 6.2.1 Repetidores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2.2 Bridges y gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2.3 M´s sobre bridges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 35 6.2.4 M´s sobre gateways. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 36 6.3 Comparando las tecnolog´ de conmutaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . ıas o 37 6.3.1 Aislamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.3.2 Prestaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.3.3 Enrutamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.3.4 Administraci´n de Redes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 41 6.3.5 Una evaluaci´n final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 43 7 Configurando gateways 43 7.1 Configurando el enrutamiento de los gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8 Anexo: Copyright 47 1 El problema. Este trabajo trata fundamentalmente sobre los aspectos ”l´gicos”de la arquitectura de red. Lo que puede o o no puede hacer una red est´ generalmente determinado por los protocolos que dicha red soporta y la calidad a de sus implementaciones, m´s que por la tecnolog´ concreta de red usada, como Ethernet, Token Ring, etc. a ıa Adem´s, en la pr´ctica, la elecci´n de la tecnolog´ de red est´ basada en decisiones puramente pragm´ticas: a a o ıa a a qu´ tipo de red soporta el tipo de ordenadores que queremos conectar, las distancias entre los equipos, las e caracter´ ısticas del cableado, etc. Por regla general, se suele usar Ethernet para sistemas de media escala, Ethernet o una red basada en el cableado de par trenzado para peque˜as redes, o redes de alta velocidad n (t´ ıpicamente Token Ring) para la red principal de un campus y para redes de superordenadores, que ejecutan aplicaciones de altas prestaciones. Por tanto, vamos a asumir que hemos llegado a conectar ”f´ısicamente¨nas redes individuales, del tipo Et- u hernet o Token Ring. Ahora nos enfrentamos a los siguientes problemas interrelacionados: • configurar el software necesario, • conectar las distintas Redes Ethernet, Token Ring, etc, para formar una unica red de forma coherente, ´ • conectar las redes al mundo exterior, o sea, Internet.
  3. 3. 2. Asignaci´n de direcciones y enrutamiento. o 3 Las anteriores decisiones requieren un peque˜o an´lisis. De hecho, la mayor´ de las redes necesitan una n a ıa a rquitectura”, que determina la manera en que se asignan las direcciones, c´mo se hace el enrutado y otras o elecciones, sobre c´mo los ordenadores interaccionan con la red. Estas decisiones deben hacerse para la red o en su conjunto, preferiblemente cuando se esta procediendo a su instalaci´n inicial. o 1.1 Terminolog´ ıa. Vamos a usar el t´rmino IP para referirnos a las redes dise˜adas para trabajar con TCP/IP. IP es el protocolo e n a nivel de red de la familia de protocolos TCP/IP, usados en Internet. Es una pr´ctica com´n usar el t´rmino a u e IP cuando nos referimos a direcciones, enrutamiento y otros elementos a nivel de red. La distinci´n muchas o veces no es lo suficientemente clara. As´ que, en la pr´ctica, los t´rminos Internet TCP/IP e IP pueden ı a e parecer incluso intercambiables. Los t´rminos paquete y datagrama tambi´n suelen parecer intercambiables. Conceptualmente, un pa- e e quete es la unidad f´ ısica de m´s bajo nivel, mientras que datagrama se refiere a la unidad de datos a nivel a IP. Sin embargo, en la mayor´ de las redes no se pueden distinguir porque coinciden, as´ que la gente suele ıa ı usar los dos t´rminos indistintamente. e Otro t´rmino conflictivo es el de pasarela (gateway) y enrutador (router). Pasarela es el t´rmino e e original usado en Internet. Sin embargo, la comunidad OSI empez´ a usar esta palabra con un significado o distinto, as´ que la gente empez´ a usar enrutador para evitar dicha ambig¨edad. Nosotros, no obstante, ı o u seguiremos usando el t´rmino gateway. e 2 Asignaci´n de direcciones y enrutamiento. o Muchas de las decisiones que se necesitan para la configuraci´n de una red IP depende del enrutamiento. En o general, un datagrama IP pasa a trav´s de numerosas redes mientras se desplaza entre el origen y el destino. e Veamos un ejemplo t´ ıpico: Red 1 Red 2 Red 3 128.6.4 128.6.21 128.121 ============================== ========== ==================== | | | | | | | ___|______ _____|____ __|____|__ __|____|____ ___|________ 128.6.4.2 128.6.4.3 128.6.4.1 128.6.21.1 128.121.50.2 128.6.21.2 128.121.50.1 ___________ __________ __________ ____________ ____________ ordenador A ordenador B gateway R gateway S ordenador C Este gr´fico muestra tres ordenadores, 2 gateways y tres redes. Las redes pueden ser Ethernet, Token Ring a o de cualquier otro tipo. La red 2 podr´ ser una l´ ıa ınea punto a punto que conecta los gateways R y S. El ordenador A puede enviar datagramas al B directamente, usando la red 1. Sin embargo, no puede llegar al ordenador C directamente, puesto que no est´n en la misma red. Hay varias maneras de conectar redes. a En el gr´fico asumimos el uso de gateways (m´s adelante veremos otras alternativas). En este caso, los a a datagramas que van desde A a C deben ser enviados a trav´s del gateway R, red 2 y gateway S. Todos e los ordenadores que usan TCP/IP necesitan que se les suministre la informaci´n y algoritmos apropiados o para que puedan saber cu´ndo un datagrama debe ser enviado a trav´s de un gateway, y elegir el gateway a e apropiado. El enrutado est´ ´ a ıntimamente relacionado con la asignaci´n de direcciones. Podemos apreciar que la direcci´n o o de cada ordenador comienza con el n´mero de la red a la que pertenece. Por tanto, 128.6.4.2 y 128.6.4.3 se u
  4. 4. 3. Eligiendo una estructura de direcciones. 4 encuentran en la red 128.6.4. Luego los gateways, cuyo trabajo es conectar dos redes, tienen una direcci´n o de ambas redes. Por ejemplo, el gateway R conecta la red 128.6.4 y 128.6.21. Su conexi´n a la red 128.6.4 o tiene la direcci´n 128.6.4.1. Su conexi´n a la red 128.6.21 tiene la direcci´n 128.6.21.2. o o o Debido a esta relaci´n entre direcciones y redes, las decisiones de enrutado deben basarse estrictamente en o el n´mero de red de destino. La informaci´n de enrutamiento del ordenador A tendr´ el siguiente aspecto: u o a red gateway m´trica e ----------- --------- ------- 128.6.4 - 0 128.6.21 128.6.4.1 1 128.121 128.6.4.1 2 En esta tabla, el ordenador A puede enviar datagramas a los ordenadores de la red 128.6.4 directamente, y para los datagramas a los ordenadores de las redes 128.6.21 y 128.121 es necesario usar el gateway R. La ”m´trica”ser´ usada por alg´n tipo de algoritmo de enrutamiento, como medida de la lejan´ del destinatario. e a u ıa En nuestro caso, la m´trica simplemente indica cuantos diagramas tiene que atravesar para llegar a su destino e (conocida como ”cuenta de saltos”). Cuando el ordenador A est´ listo para enviar un datagrama se examina la direcci´n del destinatario. Com- a o paramos el inicio de dicha direcci´n de red con las direcciones de la tabla de enrutamiento. Las distintas o entradas de la tabla indican si el datagrama debe ser enviado directamente, o a un gateway. Un gateway consiste simplemente en un ordenador conectado a dos redes diferentes, y est´ habilitado para a enviar datagramas entre ellos. En muchos casos es m´s eficiente usar un equipo especialmente dise˜ado a n para desempe˜ar el papel de gateway. Sin embargo, es perfectamente posible usar un ordenador, siempre y n cuando tenga m´s de un interfaz de red y un software capaz de enviar datagramas. a Un gateway tiene varias direcciones, una para cada red a la que est´ conectado. Aqu´ encontramos una e ı diferencia entre IP y otros protocolos de red: cada interface de un ordenador tiene una direcci´n. Con otros o protocolos, cada ordenador tiene una unica direcci´n, aplicable a todos sus interfaces. Un gateway entre ´ o las redes 128.6.4 y 128.6.21 tendr´ una direcci´n que comience por 128.6.4 (por ejemplo, 128.6.4.1). Esta a o direcci´n se refiere a su conexi´n a la red 128.6.4. Tambi´n tendr´ una direcci´n que comience con 128.6.21 o o e a o (por ejemplo, 128.6.21.2). Esta se refiere a su conexi´n a la red 128.6.21. o El t´rmino ”red”generalmente se suele identificar a dispositivos del tipo Ethernet, en la cual varias m´quinas e a est´n conectadas. Sin embargo, tambi´n se aplica a l´ a e ıneas punto a punto. En el gr´fico anterior, las redes a 1 y 3 podr´ estar en ciudades distintas; la red 2 podr´ ser una l´ ıan ıa ınea serie, un enlace sat´lite, u otro e tipo de conexi´n punto a punto. Una l´ o ınea punto a punto es tratada como una red que consta s´lo de dos o ordenadores. Como cualquier otra red, una l´ ınea punto a punto tiene una direcci´n de red (en este caso, o 128.6.21). Los sistemas conectados por la l´ ınea (gateways R and S) tienen direcciones en dicha red (en este caso, 128.6.21.1 y 128.6.21.2). Es posible dise˜ar software que no necesite distintos n´meros de red para cada l´ n u ınea punto a punto. En este caso, el interface entre el gateway y la l´ınea punto a punto no tiene una direcci´n. Esta soluci´n o o es apropiada cuando la red es tan grande que peligra el hecho de que nos quedemos sin direcciones. Sin embargo, tales ”interfaces an´nimas”pueden dificultar bastante el manejo de la red. Puesto que no tienen o direcci´n, el software de red no tiene manera de referirse a dicho interface, y, por tanto, no es posible o obtener informaci´n sobre el flujo y los errores de la interface. o 3 Eligiendo una estructura de direcciones. Antes de comenzar a montar una estructura de IP, necesitamos uno o m´s n´meros de red oficiales. Una a u direcci´n IP tiene un aspecto como el siguiente: 128.6.4.3. Esta direcci´n s´lo podr´ ser usada por un o o o a
  5. 5. 3. Eligiendo una estructura de direcciones. 5 ordenador de la Universidad de Marx. La primera parte de dicha direcci´n, 128.6, es un n´mero de red o u asignado a dicha Universidad por una autoridad central. Por tanto, antes de asignar direcciones a nuestros ordenadores, deberemos obtener una direcci´n oficial de red. Sin embargo, alguna gente configura sus redes o usando, o bien una direcci´n aleatoria o usando una direcci´n gen´rica suministrada por defecto en el equipo. o o e Esta forma de trabajar podr´ funcionar en peque˜as redes, pero seguramente no lo har´ en una mayor. ıa n a Adem´s, es posible que quisi´ramos conectar nuestra red con la red de otra organizaci´n. Incluso si nuestra a e o organizaci´n tuviese un gran control de seguridad, es posible que tuvi´ramos un ordenador dedicado a la o e investigaci´n que estuviese conectado a una universidad u otra organizaci´n investigadora. Esta universidad o o o entidad estar´ seguramente conectada a una red de nivel nacional. Tan pronto como uno de nuestros ıa datagramas salga de nuestra red local va a provocar un estado de confusi´n en la organizaci´n con la que o o nos comuniquemos, porque la direcci´n que aparece en nuestros datagramas est´ probablemente asignada o a oficialmente a alguien distinto. La soluci´n es simple: obtener una direcci´n propia desde el principio. Adem´s, no cuesta nada. o o a La decisi´n m´s importante que tenemos que hacer para configurar una red es, sin lugar a dudas, c´mo o a o asignar las direcciones IP a los ordenadores. Esta elecci´n debe de hacerse desde el punto de vista de c´mo o o nuestra red puede crecer. Si no se hiciese as´ es casi seguro que tendremos que cambiar las direcciones en ı, un futuro. Y cuando tengamos varios cientos de ordenadores, cambiar tantas direcciones es casi imposible. Las direcciones son muy importantes porque los datagramas IP son enrutados en base a dicha direcci´n. o Por ejemplo, las direcciones de la Universidad Rutgers tienen una estructura de dos niveles. Una direcci´no t´ ıpica puede ser 128.6.4.3. La direcci´n 128.6 es la asignada a dicha Universidad. Visto desde el exterior, o 128.6 es una simple red. Cualquier datagrama enviado desde el exterior, que comience por 128.6, se dirigir´ a al gateway m´s cercano de la Universidad Rutgers. Sin embargo, dentro de Rutgers dividimos el espacio a de direcciones en ”subredes”. Usamos los siguientes 8 bits de direcci´n para indicar a qu´ subred pertenece o e el ordenador. As´ 128.6.4.3 pertenece a la subred 128.6.4. Generalmente, las subredes se corresponden con ı, ısicaso reales, por ejemplo una red Ethernet; sin embargo, veremos algunas excepciones m´s adelante. redes ”f´ a Los sistemas dentro de Rutgers, a diferencia de los de fuera, contienen informaci´n sobre la estructura de o subredes de Rutgers. As´ una vez que un datagrama para 128.6.4.3 llega a Rutgers, la red de Rutgers lo ı, enrutar´ hacia la Ethernet, Token Ring o cualquier otro tipo de red del departamento que tiene asignado la a subred 128.6.4. Cuando queremos configurar una red, hay varias decisiones de direccionamiento que debemos afrontar: • ¿Dividimos nuestro espacio de direcciones? • Si lo hacemos, ¿usamos subredes o direcciones de clase C? • ¿C´mo debe ser de grande el espacio de direcciones que necesitamos? o 3.1 ¿Debemos subdividir nuestro espacio en direcciones? No es absolutamente necesario usar subredes. Hay mecanismos que permiten actuar a un campus o compa˜´ nıa completa como una simple y gran Ethernet, as´ que no es necesario un enrutamiento interno. Si usamos estas ı tecnolog´ entonces no necesitaremos dividir nuestro espacio de direcciones. En este caso, la unica decisi´n ıas, ´ o que tenemos que tomar es la de qu´ clase de direcci´n debemos de usar. Sin embargo, recomendamos usar e o un enfoque de subredes o cualquier otro m´todo de subdividir nuestro espacio de direcci´n en varias redes: e o • En la secci´n 6.2. discutiremos que los gateways internos son recomendables para todas las redes, m´s o a all´ de su simplicidad. a • Incluso si no necesitamos gateways en estos momentos, podemos descubrir que tarde o temprano necesitaremos usarlos. De esta manera, probablemente tiene sentido asignar direcciones como si cada
  6. 6. 3. Eligiendo una estructura de direcciones. 6 Ethernet o Token Ring fuera una subred separada. Esto permitir´ hacer conversiones a subredes reales, a si esto es necesario. • Por razones de mantenimiento, es conveniente tener direcciones cuya estructura corresponda con la estructura de la red. Por ejemplo, si vemos un datagrama extraviado procedente del sistema 128.6.4.3, es de bastante ayuda saber que todas las direcciones que comienzan por 128.6.4 se en cuentran en un determinado edificio. 3.2 Subredes y m´ ltiples numeros de red u Supongamos que estamos convencidos de que es una buena idea imponer alguna estructura en nuestras direcciones. La siguiente cuesti´n es cu´l es la m´s adecuada. Hay dos enfoques b´sicos: subredes y o a a a m´ltiples n´meros de red. u u Los est´ndares de Internet especifican el formato de las direcciones. Para las direcciones que comienzan entre a 128 y 191 (las m´s usadas actualmente), los dos primeros octetos forman el n´mero de red; por ejemplo, en a u 140.3.50.1, 140.3 es el n´mero de red. Los n´meros de red est´n asignados a una organizaci´n particular. u u a o ¿Qu´ hacemos con los dos siguientes octetos que le siguen?. Podr´ e ıamos optar por hacer al siguiente octeto un n´mero de subred, u otro esquema completamente distinto. Los gateways dentro de nuestra organizaci´n u o deben configurarse para conocer qu´ esquema de divisi´n de redes estamos usando. Sin embargo, fuera de la e o organizaci´n nadie sabr´ si 140.3.50 es una subred y 140.3.51 es otra; simplemente, fuera se sabe que 140.3 es o a una organizaci´n. Desafortunadamente, esta habilidad de a˜adir una estructura adicional a las direcciones, o n mediante el uso de subredes, no estaba presente en las especificaciones originales y, por tanto, un software antiguo ser´ incapaz de trabajar con subredes. Si una parte importante del software que hemos de usar ıa tiene este problema, entonces no podremos dividir nuestra red en subredes. Algunas organizaciones usan un enfoque distinto. Es posible que una organizaci´n use varios n´meros de o u red. En lugar de dividir un simple n´mero de red, por ejemplo 140.3, en varias subredes, como de 140.3.1 a u 140.3.10, podr´ ıamos usar 10 n´meros distintos de red. De esta manera har´ u ıamos una asignaci´n desde 140.3 o hasta 140.12. Todo el software IP sabr´ que estas direcciones se corresponden con redes distintas. a A pesar de que usando n´meros de red distintos todo funciona correctamente dentro de la organizaci´n, hay u o dos serias desventajas. La primera, y menos importante, es que se malgasta un gran espacio de direcciones. Hay solamente sobre unas 16.000 posibles direcciones de clase B. No queremos malgastar diez de ellas en nuestra organizaci´n, a no ser que sea bastante grande. Esta objecci´n es menos seria, porque podr´ o o ıamos pedir una direcci´n C para este prop´sito y hay sobre 2 millones de direcciones C. o o El problema m´s serio para usar varias direcciones de red, en lugar de subredes, es que sobrecarga las tablas a de enrutamiento en el resto de Internet. Como comentamos anteriormente, cuando dividimos nuestro n´merou de red en subredes, esta divisi´n s´lo es conocida dentro de la organizaci´n, pero no fuera. Los sistemas o o o externos a la organizaci´n s´lo necesitan una entrada en sus tablas para ser capaces de llegar. Por tanto, o o otras Universidades tienen entradas en sus tablas de enrutamiento para 128.6, similar al n´mero de la red u de Rutgers. Si usa un rango de redes en lugar de subredes, dicha divisi´n ser´ visible en todo Internet. Si o a usamos los n´meros 128.6 a 128.16, en lugar de 128.6, las otras universidades necesitar´ tener una entrada u ıan para cada uno de estos n´meros de red en sus tablas de enrutamiento. La mayor´ de los expertos de TCP/IP u ıa recomiendan el uso de subredes, en lugar de m´ltiples redes. La unica raz´n para considerar m´ltiples redes u ´ o u es el uso de un software que no puede manejar subredes. Esto era un problema hace algunos a˜os, pero n actualmente es poco frecuente. Una ultima indicaci´n sobre subredes: Las subredes deben ser adyacentes”. Esto significa que no podemos ´ o conectar la subred 128.6.4 con la subred 128.6.5 mediante otra red, como la 128.121. Por ejemplo, Rutgers tiene campus en Simon City y Garfunken City. Es perfectamente posible conectar redes en ciudades distintas que sean subred de 128.6. Sin embargo, en este caso, las l´ ıneas entre Simon City y Garfunken City deben ser parte de 128.6. Supongamos que decidimos usar una red regional como la RegionaLnet para comunicarnos
  7. 7. 3. Eligiendo una estructura de direcciones. 7 entre dos campus, en lugar de usar su propia l´ ınea. Puesto que RegionaLnet tiene de n´mero de red u 128.121, los gateways y l´ ıneas de serie que usar´ empezar´ por 128.121. Esto viola las reglas. No ıan ıan est´ permitido tener gateways o l´ a ıneas que son parte de 128.121 conectando dos partes de 128.6. As´ si ı, queremos usar RegionaLnet entre nuestros dos campus, tendr´ıamos que obtener diferentes n´meros de red u para los dos campus. (Esta regla es un resultado de las limitaciones de la tecnolog´ de enrutamiento. ıa Eventualmente podr´ desarrollarse un software para un gateway para manejar configuraciones cuyas redes ıa no son contiguas). 3.3 C´mo asignar las subredes o los numeros de red. o Ahora, una vez decidido si vamos a usar subredes o m´ltiples n´meros de red, tenemos que asignarlos. u u Normalmente es bastante f´cil. Cada red f´ a ısica, ya sea Ethernet o Token Ring, ..., se le asigna un n´mero u distinto de subred. Sin embargo, existen otras opciones. En algunos casos, puede que tenga sentido asignar varios n´meros de subred a una unica red f´ u ´ ısica. En Rutgers hay una unica Ethernet que ocupa tres edificios, usando repetidores. Est´ claro que a medida que ´ a vayamos a˜adiendo ordenadores a esta Ethernet se ir´ dividiendo en varias Ethernets separadas. Para evitar n a tener que cambiar de direcciones cuando esto suceda, hemos asignado tres n´meros de red distintas a esta u Ethernet, una por edificio. (Esto podr´ ser util, incluso, si no hubi´semos dividido la Ethernet con el fin de ıa ´ e ayudar a localizarlos). Pero, antes de hacer esto, debemos estar muy seguros de que el software de todos los ordenadores puede manejar una red que tiene tres n´meros de red. Esta pr´ctica se ver´ m´s detalladamente u a a a en la secci´n 3.4. o Tambi´n hemos de elegir una ”m´scara de subred”, que ser´ usada por el software del sistema para separar e a a la parte de subred del resto de la direcci´n. Hasta ahora hemos asumido que los dos primeros octetos son el o n´mero de red y el siguiente es el n´mero de subred. Para las direcciones de clase B, el est´ndar especifica u u a que los dos primeros octetos pertenecen al n´mero de red. Y, por otro lado, tenemos libertad para establecer u el l´ımite del n´mero de subred y el resto de la direcci´n. Es bastante usual utilizar un octeto de n´mero u o u de subred, pero no es la unica posibilidad. Veamos de nuevo esta direcci´n de clase B, 128.6.4.3. Es f´cil ´ o a deducir que, si el tercer octeto es usado como n´mero de subred, entonces habr´ 256 posibles subredes y, u a en cada subred, habr´ 256 posibles direcciones. (En realidad es m´s acertado decir que disponemos de 254, a a ya que no es buena idea usar 0 ´ 255 como n´meros de subred o direcci´n). Supongamos que sabemos que o u o nunca vamos a tener m´s de 128 ordenadores por subred, pero es probable que necesitemos m´s de 256 a a subredes (por ejemplo, un campus con una gran cantidad de peque˜os edificios). En ese caso, podr´ n ıamos establecer 9 bits como n´mero de red, dejando 7 bits para el direccionamiento de cada subred. Esta decisi´n u o queda plasmada en una m´scara de bits, usando unos para los bits usados por los n´meros de red y de a u subred y ceros para los bits usados para el direccionamiento individual. La m´scara de red m´s com´n es a a u 255.255.255.0. Si elegimos 9 bits para el n´mero de subredes y 7 para las direcciones, la m´scara de subred u a ser´ 255.255.255.128. ıa Generalmente, es posible especificar la m´scara de subred como parte de la configuraci´n del software a o IP. Los protocolos IP tambi´n permiten a los ordenadores que env´ un mensaje preguntando cu´l es su e ıen a m´scara de subred. Si nuestra red soporta el env´ de estos mensajes, y hay, al menos, un ordenador o a ıo gateway de la red que conoce dicha m´scara de subred, posiblemente ser´ innecesario especificarlo en cada a a uno de los restantes ordenadores. Pero esta posibilidad puede traer muchos problemas. En caso de que nuestra implementaci´n TCP/IP diera una m´scara de subred err´nea, se causar´ una mala configuraci´n o a o ıa o en toda la red. Por lo tanto, es m´s seguro poner cada m´scara de subred expl´ a a ıcitamente en cada sistema. 3.4 Trabajar con m´ ltiples subredes ”virtuales”en una red. u La mayor´ del software est´ desarrollado bajo el supuesto de que cada red local tiene el mismo n´mero de ıa a u subred. Cuando existe un flujo hacia una m´quina con un distinto n´mero de subred, el software espera a u
  8. 8. 3. Eligiendo una estructura de direcciones. 8 encontrar un gateway que pueda dirigirlo hacia esa subred. Veamos detalladamente qu´ ocurre en este e caso. Supongamos que tenemos las subredes 128.6.19 y 128.6.20 en la misma Ethernet. Consideremos las cosas que ocurren desde el punto de vista de un ordenador con direcci`n 128.6.19.3. Dicho ordenador no o tendr´ problemas para comunicarse con las m´quinas de direcci´n 128.6.19.x. Estas m´quinas est´n en la a a o a a misma subred, y nuestro ordenador simplemente deber´ enviar los datagramas al 128.6.20.2. Puesto que esta a direcci´n indica que est´ en una subred distinta, la mayor´ del software esperar´ encontrar un gateway que o a ıa a haga de puente entre ambas subredes. Por supuesto, no existe un gateway entre las ”subredes”128.6.19 y 128.6.20, puesto que est´n en la misma Ethernet. De aqu´ se deduce que tenemos que encontrar una manera a ı de indicarle al software que el 128.6.20 se encuentra realmente en la misma Ethernet. La mayor´ de las implementaciones TCP/IP pueden manejar m´s de una subred en la misma red. Por ıa a ejemplo, el Berkeley Unix nos permite hacerlo usando una ligera modificaci´n del comando usado para o definir gateways. Si, por ejemplo, queremos que para pasar de la subred 128.6.19 a la subred 128.6.4 se use el gateway con direcci´n 128.6.19.1, podemos usar el comando o route add 128.6.4.0 128.6.19.1 1 Esto indica que para llegar a la subred 128.6.4 el flujo debe ser enviado a trav´s del gateway 128.6.19.1. e El ”1”se refiere a la ”m´trica de enrutamiento”. Si usamos la m´trica ”0”, estamos diciendo que la subred e e de destino est´ en la misma red y, por consiguiente, no se necesita ning´n gateway. En nuestro ejemplo, a u deberemos usar en el sistema 128.6.19.3 route add 128.6.20.0 128.6.19.1 0 La direcci´n usada en el lugar de 128.6.19.1 es irrelevante. La m´trica ”0”nos informa de que no va a usarse o e ning´n gateway, luego no se usar´ dicha direcci´n. Sin embargo, deber´ ampliarse una direci´n legal de la u a o a o red local. 3.4.1 Otra forma de trabajar con m´ ltiples subredes. u Hay otro modo de manejar varias subredes sobre una red f´ ısica. Este m´todo supone la desconfiguraci´n e o de nuestros anfitriones o hosts y, por ello, es potencialmente peligrosa, si no sabemos exactamente lo que estamos haciendo. Sin embargo, puede resultar m´s c´modo cuando trabajamos con una gran cantidad de a o subredes en una red f´ısica. Un ejemplo de este tipo ser´ una instalaci´n que use bridges, y usa subredes ıa o simplemente por facilidades de administraci´n. El truco est´ en configurar el software de nuestros hosts o a como si no usasen subredes. As´ nuestros hosts no har´n ninguna distinci´n entre las distintas subredes y, ı, a o por tanto, no habr´ problemas para trabajar con todas ellas. Ahora, el unico problema es c´mo comunicarnos a ´ o con subredes que no est´n en esta red de m´ltiples subredes. Pero, si nuestros gateways manejan proxy e u ARP, ellos resolver´n este problema por nosotros. Este enfoque est´ especialmente indicado cuando la a a misma red contiene m´ltiples subredes y, particularmente, si se van a a˜adir algunas m´s en un futuro. u n a Desgraciadamente, tiene dos problemas: 1. Si tenemos hosts con m´ltiples interfaces, deberemos ser muy cuidadosos. En primer lugar, s´lo u o deber´ haber m´quinas con un interface en la red con m´ltiples subredes. Por ejemplo, supongamos ıa a u que disponemos de una red que consta de varias Ethernets conectadas mediante bridges; no podemos tener una m´quina con interfaces en dos de estas Ethernets, pero podemos tener un sistema con un a interface en esta red de subredes m´ltiples y otra en otra subred apartada de ´sta. En segundo lugar, u e cualquier m´quina con m´ltiples interfaces deber´ conocer la verdadera m´scara de subred, y necesitar´ a u a a a estar informada expl´ ıcitamente de cu´les de las subredes est´n en la red de m´ltiples subredes. Estas a a u restricciones son consecuencia de que un sistema con m´ltiples interfaces tiene que conocer qu´ interface u e ha de usar en cada caso.
  9. 9. 3. Eligiendo una estructura de direcciones. 9 2. Tambi´n deberemos prestar atenci´n a la facilidad ICMP de la m´scara de subredes. Esta facilidad e o a permite a los sistemas emitir una consulta para conocer cu´l es la m´scara de subred. Si la mayor´ de a a ıa los hosts piensan que la red no est´ dispuesta en subredes, pero los gateways y los hosts con varias a interfaces piensan lo contrario, tenemos aqu´ un foco potencial de confusi´n. Si un gateway o hosts ı o con varios interfaces env´ una r´plica a una ICMP de m´scara de red, dando la verdadera m´scara ıa e a a de subred, alguno de los restantes hosts puede interceptarlo. La situaci´n contraria tambi´n ser´ o e ıa posible. Esto significa que tendremos que: • deshabilitar las r´plicas a las ICMP de m´scara de subred en todos aquellos sistemas que conocen e a la m´scara real de subred (esto es especialmente f´cil si solamente los gateways lo conocen); a a • asegurar que nuestros hosts ignoran las r´plicas ICMP. e A medida que establecemos una m´scara de subred expl´ a ıcitamente, se supone que los hosts ignoran los ICMP de m´scara de subred, as´ que deberemos ser capaces de establecer diferentes m´scaras en diferentes hosts a ı a sin causar ning´n problema, siempre y cuando podamos establecer la m´scara expl´ u a ıcitamente en todos ellos. Sin embargo, existen implementaciones IP que cambiar´n su m´scara de subred cuando vean una r´plica de a a e ICMP de m´scara de subred. a 3.4.2 M´ ltiples subredes: Consecuencias en el Broadcasting. u Cuando tenemos m´s de una subred en una misma red f´ a ısica, hay que tener cuidado respecto a las direcciones de broadcasting. De acuerdo con los ultimos est´ndares, hay dos formas distintas para que un host de ´ a la subred 128.6.20 pueda enviar un broadcast en la red local. Una es usar la direcci´n 128.6.20.255. La o otra es usar la direcci´n 255.255.255.255. La direcci´n 128.6.20.255 dice, expl´ o o ıcitamente, ”todos los hosts de la subred 128.6.20”; la 255.255.255.255 expresa ”todos los hosts de mi red local”. Normalmente, ambas tienen el mismo efecto. Pero no lo tienen cuando hay varias subredes en una red f´ ısica. Si la red 128.6.19 est´ en la misma red, tambi´n recibir´ el mensaje enviado a 255.255.255.255. Sin embargo, los hosts con a e a n´meros 128.6.19.x no escuchar´n los mensajes enviados a 128.6.20.255. El resultado es que ah´ tenemos dos u a ı tipos distintos de direcciones de broadcast con dos significados distintos. Esto conlleva que debemos tener cuidado configurando el software de red, para asegurarnos de que nuestros broadcasting llegan a donde queremos que lo hagan. 3.5 Eligiendo una clase de direcci´n. o Cuando solicitamos un n´mero oficial de red se nos preguntar´ qu´ clase de n´mero de red necesitamos. Las u a e u posibles respuestas son A, B y C. La decisi´n elegida limitar´ nuestro espacio de direcciones a usar. Las o a direcciones de clase A ocupan un octeto; las de clase B, dos octetos, y la clase C, tres octetos. Luego, hay m´s direcciones de clase C que direcciones de clase A, pero las de clase C no pueden tener muchos hosts. a La idea que podemos sacar de lo anterior es que deber´ haber pocas grandes redes, un n´mero moderado ıa u de redes de tama˜o mediano y bastantes peque˜as redes. En la siguiente tabla observamos dicha distinci´n: n n o Clase Rango 1er. octeto red resto direcciones posibles A 1 - 126 p q.r.s 16777214 B 128 - 191 p.q r.s 65534 C 192 - 223 p.q.r s 254 Por ejemplo, la red 10 es de la clase A y por tanto tiene direcciones entre 10.0.0.1 y 10.255.255.254. Esto signfica 2543, que son sobre unos 16 millones de posibles direcciones (realmente, la red 10 tiene algunas direcciones con octetos a cero, as´ que habr´ algunas direcciones posibles m´s). La red 192.12.88, una ı a a
  10. 10. 3. Eligiendo una estructura de direcciones. 10 direcci´n de clase C, tendr´ sus hosts entre el 192.12.88.1 y el 192.12.88.254 y, por lo tanto, habr´ 254 o a a posibles hosts. En general, deberemos elegir la clase menor que nos proporcione suficientes direcciones capaces de direccionar nuestra red, con sus posibles futuras ampliaciones. Aquellas organizaciones que usan ordenadores en varios edificios, probablemente necesitar´n una direcci´n de clase B, suponiendo que vamos a usar subredes. (Y a o si vamos a tratar con distintos n´meros de red, deber´ u ıamos solicitar varias direcciones de clase C). Las direcciones de clase A, normalmente, s´lo se usan en grandes redes p´blicas y algunas pocas redes de grandes o u corporaciones. En la asignaci´n de Direcciones IP, la autoridad m´xima es la IANA (Internet Assigned Number Authority). o a A escala continental, la IANA delega grandes bloques de direcciones IP a los denominados registros regionales, de los que, de momento, existen tres en el mundo: • El RIPE NCC (RIPE Network Coordination Center) es el registro delegado de Internet a nivel europeo y se encarga, entre otras tareas, de la asignaci´n de bloques de direcciones IP a los proveedores de o servicios Internet en Europa y su ´rea de influencia. a • El AP-NIC lleva a cabo la tarea de asignaci´n de bloques de direcciones IP a los proveedores de la o regi´n del Asia-Pac´ o ıfico. • El InterNIC se encarga de la asignaci´n de bloques de direcciones IP a los proveedores de Internet en o Am´rica del Norte y, de momento, en el resto del mundo. e Las organizaciones y usuarios finales han de obtener las direcciones IP necesarias para conectarse a Internet a trav´s de su proveedor de acceso a Internet, quien a su vez las habr´ obtenido bien de su proveedor de e a tr´nsito, bien del registro regional correspondiente. a 3.6 Lineas IP y micro gateways: direcciones asignadas din´micamente. a En la mayor´ de los casos, cada uno de los ordenadores tendr´ su propia direcci´n IP permanente. No ıa a o obstante, hay algunas situaciones donde tiene m´s sentido asignar direcciones din´micamente. La mayor´ a a ıa ıneas IP constan de gateways destinados principalmente a microcomputadoras. de los casos que manejan l´ 3.6.1 L´ ıneas IP. Es posible usar IP sobre l´ ıneas telef´nicas. Uno de los protocolos para hacer esto es el SLIP (”Serial line o IP”). SLIP se usa frecuentemente en, al menos, dos circunstancias distintas: • Como una alternativa barata a l´ıneas punto a punto permanentes, para aquellos casos en los que no est´ suficientemente justificado una l´ a ınea dedicada. • Como una manera de conectar individualmente un PC a una red, cuando se encuentran localizados en edificios que no tienen Ethernets o cualquier otro tipo LAN. Vamos a usar el t´rmino ”servidor SLIP”para referirnos a un sistema de ordenador(es) que incluye una e serie de modems, con los que otros sistemas pueden conectarse usando SLIP. Se trata de un sistema que proporciona un gateway de nuestra red para usuarios de PC, o para otras redes que se conectan usando SLIP. Si tenemos varios PC’s conectados mediante SLIP, muchas veces no es pr´ctico usar una direcci´n IP propia a o para cada PC. Una de las razones puede ser que no haya suficientes direcciones. Para que el enrutamiento funcione correctamente, estos sistemas conectados deben tener sus direcciones en la misma subred que el
  11. 11. 3. Eligiendo una estructura de direcciones. 11 servidor SLIP. Por lo general, hay solamente del orden de 256 direcciones disponibles en cada subred. Si el n´mero de PC’s que pueden conectarse es mayor que esa cifra, no podremos asignarles su propia direcci´n. u o Si, adem´s, tenemos servidores SLIP en m´s de una subred, la asignaci´n permanente de direcciones se hace a a o a´n m´s complicada. Si un usuario es capaz de llamar a dos servidores, su PC necesitar´ dos direcciones, u a ıa una para cada subred. Para solucionar estos problemas, la mayor´ de las implementaciones SLIP asignan las direcciones ıa din´micamente. Cuando un PC se conecta con el servidor SLIP, el servidor busca una direcci´n IP que a o no se est´ usando y se la asigna al PC. La forma m´s simple de manejar esto es dando a cada servidor SLIP e a un rango de direcciones IP que controle y pueda asignar. Cuando usamos este esquema, el software SLIP debe comunicar al PC, de alguna manera, qu´ direcci´n e o debe usar. Si cada PC tiene una direcci´n permanente, tendr´ o ıamos el problema contrario: cuando un PC se conecta con un servidor debe de haber alg´n m´todo para que el PC comunique al servidor su direcci´n. u e o Este problema debe ser estudiado cuidadosamente, porque en otro caso alguien podr´ usar la direcci´n de ıa o otro y tener acceso a sus ficheros. Desafortunadamente, no hay un est´ndar para manejar estos problemas de direccionamiento con SLIP. Hay a varias implementaciones SLIP que lo hacen, pero todav´ no hay un est´ndar. Hasta que no se elabore ıa a ´ste, deberemos tener cuidado con el software SLIP. Tenemos que asegurarnos de que dicha asignaci´n de e o direcci´n se lleva a cabo de la manera que queremos y que nuestro servidor SLIP y los PC’s tienen claro la o forma en que se asignan las direcciones. Recomendamos dar direcciones permanentes a los PC’s en aquellos casos en que los dem´s ordenadores tienen a que ser capaces de conocer con qu´ PC est´n hablando. Este podr´ ser el caso de un PC para recibir correo e a ıa privado, o cualquier otro servicio con transacciones delicadas. Y recomienda el direccionamiento din´mico a cuando tenemos un gran n´mero de PC’s y las aplicaciones que utilizan para acceder a la red tienen sus u propios mecanismos de seguridad. Cuando usemos SLIP para conectar dos redes, hay que considerar tres elecciones para el manejo de direcciones (teniendo en cuenta que no todo el software SLIP puede controlar los tres apartados): • Tratar a las conexiones SLIP como si se tratasen de l´ıneas punto a punto que no est´n disponibles a permanentemente. Si podemos conectar con m´s de un ordenador, cada par de ordenadores que se a comunican tienen un n´mero de red distinto del que ellos usar´ cuando se comunican con el otro. u ıan • Usar un software de enrutamiento que permita interfaces an´nimos. En este caso, no ser´ necesarias o ıan las direcciones. • Asignar direcciones din´micamente cuando la conexi´n est´ abierta, tan pronto como el PC haya a o a contactado. Si hacemos s´lo una o dos conexiones a otro sistema, es bastante razonable usar un n´mero de red para cada o u conexi´n. Este m´todo es f´cil de usar y limita los errores estad´ o e a ısticos. Si tenemos muchas conexiones distintas, probablemente es mejor usar interfaces an´nimos. Aunque si los o sistemas de enrutamiento no lo soportan, debemos usar asignaci´n din´mica. o a Al igual que SLIP, PPP ”Point to Point Protocol”es un protocolo serie distinto utilizado para enviar data- gramas a trav´s de una conexi´n serie, pero mejora algunas de las carencias del anterior. El PPP permite a e o las partes comunicantes negociar opciones como las direcciones IP y el tama˜o m´ximo de los datagramas n a al comenzar la conexi´n, y proporciona permisos de conexi´n a los clientes (autorizaciones). Para cada una o o de estas capacidades, el PPP tiene un protocolo concreto. A continuaci´n, citaremos los elementos b´sicos que constituyen el PPP. Esta descripcion esta muy lejos o a de ser completa; si quiere saber mas sobre el PPP, lea sus especificaciones en el RFC 1548, asi como en la docena de RFCs que le acompa˜an.n
  12. 12. 3. Eligiendo una estructura de direcciones. 12 En la parte m´s baja del PPP est´ el protocolo de Control de Conexi´n de Datos de Alto-Nivel, abrevia- a a o damente HDLC. ( En realidad, el HDLC es un protocolo mucho m´s general publicado por la Organizaci´n a o Internacional de Est´ndares, ISO ) que define los l´ a ımites de las tramas PPP individuales, y proporciona un control de errores de 16 bit. Al contrario de lo que ocurr´ en las encapsulaciones SLIP m´s antiguas, ıa a una trama PPP es capaz de llevar paquetes de otros protocolos distintos al IP, como los IPX de Novell o Appletalk. El PPP consigue esto a˜adiendo a la trama b´sica HDLC un campo de control que identifica el n a tipo de paquete contenido en la trama. El LCP, Protocolo de Control de Enlace, es utilizado en la parte m´s alta del HDLC para negociar las a opciones concernientes a la conexi´n de datos, tales como la Unidad M´xima de Recepci´n (MRU) que o a o establece el tama˜o m´ximo del datagrama que una de las partes de la conexi´n acepta recibir. n a o 3.6.2 Micro gateways. Es perfectamente posible que un microcomputador forme parte de una red IP. Pero hay una tendencia de que los micros utilicen distintas tecnolog´ de red que la de los grandes sistemas. Esto es debido a que ıas muchos de los usuarios de micros empiezan a demandar un software de red dise˜ado espec´ n ıficamente para las necesidades de un micro, incluso para un particular tipo de micro. Muchos usuarios est´n interesados a en usar TCP/IP sin tener que abandonar su red especial de micro, a la que est´n acostumbrados. Por esta a raz´n, hay un creciente n´mero de productos, especialmente gateways, que dan acceso a los PC’s tanto a o u redes orientadas a micros como a TCP/IP. En esta secci´n vamos a hablar del AppleTalk, de Apple, a modo de ejemplo. No obstante, existen productos o similares para otros tipos de redes de micros. Hay que aclarar que el t´rmino AppleTalk se asocia a los e protocolos de red de Apple, mientras que LocalTalk se asocia a una tecnolog´ espec´ ıa ıfica de par trenzado, en la que AppleTalk fue inicialmente implementada. Por tanto, el AppleTalk es an´logo a los protocolos a TCP/IP, mientras que LocalTalk es an´logo a medio Ethernet. a Algunas compa˜´ ofrecen gateways para conectar una red AppleTalk corriendo sobre LocalTalk, con redes nıas IP corriendo sobre Ethernet. A pesar de que hay varios productos de este tipo, la mayor´ de ellos incluyen ıa los siguientes servicios: • Las aplicaciones TCP/IP de un PC pueden conectarnos a sistemas TCP/IP de la Ethernet. Se definen utilidades especiales para permitirnos llevar datagramas IP desde el PC hasta el gateway, a trav´s e del LocalTalk. Las aplicaciones TCP/IP de PC han sido escritas usando unas librer´ especiales que ıas mezclan AppleTalk y TCP/IP. Las utilidades AppleTalk se necesitan para llevar los datagramas hasta el gateway, donde se transformar´n en datagramas 100% TCP/IP, antes de dejarlos en la Ethernet. a • Se pueden escribir aplicaciones AppleTalk para grandes sistemas, de tal manera que un PC podr´ a usarlos como servidores. Dichas aplicaciones tambi´n han sido escritas haciendo uso de una librer´ e ıa especial que mezcla AppleTalk y TCP/IP. Pero, en esta ocasi´n, son utilidades TCP/IP para dejar o datagramas en el gateway, donde se transformar´n totalmente en AppleTalk, antes de dejarlos en la a AppleTalk y lleguen al PC. • Una red IP de un campus o una corporaci´n puede ser usada para conectar redes AppleTalk. Los o gateways de cada Apple realizar´n las conversiones necesarias antes de enviar los datagramas a la red a IP. Adem´s, algunos gateways pueden hacer traducciones a nivel de aplicaci´n. Por ejemplo, algunos gateways a o pueden hacer traducciones entre el sistema de ficheros de Apple y el sistema de fichero de red de Sun (NFS). Esto permite a un PC acceder al sistema de ficheros Unix, donde el PC usa el sistema de ficheros Apple, y el acceso al sistema Unix se hace mediante el uso del sistema NFS, o sistema de ficheros de red (Network File System ), de Sun.
  13. 13. 4. Servicios a nivel de red, nombres. 13 Desafortunadamente, la gran flexibilidad de estos productos se traduce en una gran complejidad. El tema de direcciones es especialmente complicado. Por las mismas razones que SLIP, y PPP estos gateways usan frecuentemente asignaci´n din´mica de direcciones IP. Para ello asignaremos un rango de direcciones IP a o a cada gateway. Cuando un PC intenta abrir una conexi´n TCP/IP, el gateway se hace con una direcci´n o o IP libre y se la asigna al PC. Al igual que SLIP, en muchos casos necesitaremos elegir si queremos que las direcciones se asignen de esta manera, o bien queremos que cada PC tenga su propia direcci´n. Otra vez, o la elecci´n depender´ del n´mero de PC’s que tengamos y de si tenemos aplicaciones capaces de usar la o a u direcci´n IP para identificar qu´ PC, en particular, es el que est´ conectado. o e a El direccionamiento es mucho m´s complejo, debido a que AppleTalk tiene su propia estructura de direcciones. a Deberemos establecer una correspondencia entre direcciones AppleTalk y n´meros de red IP. Tambi´n habr´ u e a una correspondencia entre direcciones IP y AppleTalk, que se establecer´ din´micamente en los gateways. a a 4 Servicios a nivel de red, nombres. Si vamos a tener una red TCP/IP, hay algunas tareas importantes que realizar. Algunas de ellas son simplemente de tipo administrativo. La m´s importante es crear un registro central de nombres y direcciones a IP. Existen organizaciones que realizan esta labor para toda la red Internet. Si estamos conectados a Internet, el administrador de nuestro sistema necesita registrarse a una de estas organizaciones, para que cualquier demanda por parte de otra instituci´n sobre nuestros hosts sean dirigidos a nuestros servidores. o Queremos mantener una base de datos que contenga la informaci´n de cada sistema de la red. Como o m´ınimo, necesitaremos el nombre y la direcci´n IP de cada sistema. Probablemente, el registro central ser´ o a el encargado de asignar las direcciones IP. Si nuestra red est´ estructurada en subredes, o si usamos varios a n´meros de clase C, el registro posiblemente asignar´ los n´meros de red a las nuevas redes o subredes. u a u Pero, habitualmente, se permitir´ que los propios administradores de los hosts elijan el nombre del host. a Sin embargo, el registro debe de, al menos, verificar que no haya nombres duplicados. Si estamos trabajando con una gran red, puede que sea buena idea delegar algunas de estas tareas a subregistros, posiblemente uno para cada departamento. Se recomienda asignar las direcciones de la forma m´s simple: empezando por 1. As´ si nuestra red es a ı, la 128.6, podr´ıamos asignar como 128.6.1 a la primera subred; 128.6.2, a la segunda, etc. La asignaci´n o de direcciones IP para hosts individuales podr´ empezar por 2. De esta manera reservamos la direcci´n ıan o 1 de cada subred para que sea usada por el gateway correspondiente. Por consiguiente, el primer host de la subred 128.6.4 ser´ el 128.6.4.2; el siguiente ser´ 128.6.4.3, y as´ sucesivamente. Hay una raz´n ıa ıa ı o b´sica para mantener las direcciones tan cortas como sean posibles. Si tenemos una gran organizaci´n, a o podr´ıamos quedarnos sin n´meros de subred. Si esto ocurriera, y nuestros hosts tienen n´meros de red u u bajos, podr´ıamos asignar otro bit para el direccionamiento de las subredes. Si, por ejemplo, usamos el tercer octeto como n´mero de subred, en tanto en cuanto nuestros hosts tengan unos n´meros inferiores a 128, u u podremos ampliar el n´mero de red a 9 bits. As´ por ejemplo, la subred 128.6.4 podr´ dividirse en dos u ı, ıa subredes distintas: 128.6.4.0 y 128.6.4.128. Si hubi´semos asignado a los hosts n´meros por encima de 128, e u la divisi´n habr´ sido imposible. o ıa La asignaci´n de nombres de los hosts no es tan sistem´tica. Pueden ser cualquier expresi´n compuesta de o a o letras, n´meros y guiones. Es m´s seguro que el primer car´cter sea una letra. Y, desde el punto de vista u a a de los usuarios, es recomendable que los nombres sean lo m´s cortos posibles (incluso hay software que a tiene problemas trabajando con nombres m´s largos de 16 caracteres). Muchas veces, los departamentos o a proyectos eligen un tema o nombre relacionado con ellos. Por ejemplo, las m´quinas usadas por los estudiantes a de Inform´tica de Rutgers tienen nombres de bandas de rock: OASIS, BLUR, IRONMAIDEN, SAVOY, etc. a Nuestro departamento de Matem´ticas usa el nombre de famosos matem´ticos: GAUSS, FERMAT, etc. Si a a la instituci´n no tiene ninguna relaci´n con el mundo exterior, cualquier nombre es adecuado. o o
  14. 14. 4. Servicios a nivel de red, nombres. 14 Si estamos conectados a Internet, nuestra organizaci´n necesitar´ un ”nombre de dominio”(domain name). o a Al igual que en el caso del espacio de direcciones IP, la autoridad m´xima del espacio de nombres de Internet a (DNS, Domain Name System) es la IANA (Internet Assigned Number Authority). La ra´ del DNS es ız gestionada por el InterNIC por delegaci´n de la IANA. Bajo la ra´ se encuentran los distintos dominios de o ız primer nivel (Top Level Domains o TLD’s) gestionados por distintos registros delegados de Internet. Algunos de ellos son: Dominios ”especiales”como COM, ORG, NET, EDU,... controlados por InterNIC ( nodo central del Network Internet Center ); y dentro de los dominios nacionales, el dominio ES, correspondiente a Espa˜a, n est´ delegado a ES-NIC. a A diferencia del n´mero de red, podremos arregl´rnosla sin ´l si la red est´ aislada. Si posteriormente lo u a e a necesitamos, es f´cil de a˜adir un nombre de dominio. (Recomendamos usar un n´mero de red desde el a n u principio, porque cambiar n´meros de red posteriormente puede ser traum´tico). Los nombres de dominio, u a normalmente, terminan en .EDU para las instituciones educativas, .COM, para las compa˜´ etc. Por ejem- nıas, plo, la Universidad de Rutgers tiene como nombre de dominio RUTGERS.EDU. El formato de los nombres completos de dominio consiste en un nombre interno, seguido del nombre de dominio de la organizaci´n. As´ o ı, si un ordenador es conocido internamente como GAUSS, su nombre completo ser´ GAUSS.RUTGERS.EDU. a Si tenemos una gran organizaci´n, es posible tener subdominios. Por ejemplo, puede que haya un subdominio o para cada departamento; esto a˜adir´ otro t´rmino en los nombres. Si, por ejemplo, el departamento de Ma- n ıa e tem´ticas decide crear su subdominio, el anterior ordenador se llamar´ GAUSS.MATHS.RUTGERS.EDU. a ıa Una vez asignado el nombre de dominio, se procede a cambiar los ficheros de configuraci´n donde aparece o la forma completa del nombre. En algunos casos, se pueden usar apodos o nombres cortos, de manera que no ser´ necesario incluir el nombre completo. a Si tenemos m´s de uno o dos sistemas, necesitaremos tener alg´n mecanismo para tener al d´ la informaci´n a u ıa o de los distintos hosts. El software TCP/IP necesita ser capaz de traducir nombres de hosts en direcciones IP. Cuando un usuario intenta conectarse con otro sistema, generalmente se referir´ a ´l usando su nombre. a e El software tendr´ que traducir el nombre en una direcci´n IP, para poder abrir la conexi´n. La mayor´ a o o ıa del software incluye dos vias para hacer esta traducci´n: una tabla est´tica o un servidor de nombres. La o a soluci´n de la tabla est´ indicada para peque˜as organizaciones, siempre y cuando no est´n conectadas a o a n e otra red. Simplemente se crea un fichero que lista los nombres y direcciones de todos los hosts. Veamos parte de una tabla de este tipo: HOST: 128.6.4.2, 128.6.25.2: ARAMIS.RUTGERS.EDU, ARAMIS: SUN-3-280: UNIX :: HOST: 128.6.4.3: GAUSS.RUTGERS.EDU, GAUSS: SUN-3-180: UNIX :: HOST: 128.6.4.4, 128.6.25.4: ATHOS.RUTGERS.EDU, ATHOS: SUN-4-280: UNIX :: Como se puede apreciar, el formato es el siguiente: una l´ ınea para cada sistema y listar sus direcciones, nombres y otra informaci´n sobre ´l. En el ejemplo, tanto ARAMIS como ATHOS est´n en dos redes, as´ que o e a ı tienen dos direcciones. Adem´s, ambos tienen un nombre principal, por ejemplo ARAMIS.RUTGERS.EDU, a y apodos, por ejemplo ARAMIS. En caso de estar conectados a Internet, el nombre principal ser´ el nombre a de dominio completamente especificado. Se incluyen apodos cortos, para facilitar la tarea a nuestros usuarios. Hay otro formato muy frecuente para las tablas de hosts. Veamos un ejemplo: 128.6.4.2 aramis.rutgers.edu aramis 128.6.25.2 aramis.rutgers.edu aramis 128.5.4.3 gauss.rutgers.edu gauss 128.6.4.4 athos.rutgers.edu athos 128.6.25.4 athos.rutgers.edu athos En este formato, cada l´ ınea representa una direcci´n IP. Si el sistema tiene dos interfaces, hay dos l´ o ıneas de ´l en la tabla. Se debe procurar poner, en primer lugar, aquellas direcciones de uso m´s com´n. La e a u documentaci´n de su sistema le informar´ sobre el formato usado por ´l. o a e
  15. 15. 4. Servicios a nivel de red, nombres. 15 En la configuraci´n m´s simple, cada ordenador tiene su propia copia de la tabla de hosts en /etc/hosts. o a En caso de elegir esta configuraci´n, deberemos establecer procedimientos para asegurarnos que todas las o copias son actualizadas regularmente. En una red peque˜a no es dif´ mantener una tabla /etc/hosts en n ıcil cada m´quina, y modificarla al agregar, eliminar o modificar nodos. Aunque resulta complicado cuando hay a muchas m´quinas, ya que, en principio, cada una necesita una copia de /etc/hosts. a Una soluci´n a esto es compartir ´sta y otras bases de datos con el NIS, o sistema de informaci´n de red o e o ( Network Information System ), desarrollado por Sun Microsystems y conocido tambi´n como p´ginas e a amarillas o YP. En este caso, las bases de datos como la de /etc/hosts se mantienen en un servidor NIS central y los clientes acceder´n a ellas de forma transparente al usuario. En todo caso, esta soluci´n s´lo a o o es aconsejable para redes peque˜as o medianas, ya que implican mantener un fichero central /etc/hosts que n puede crecer mucho, y luego distribuirlo entre los servidores NIS. En redes grandes, y todos aquellos que est´n conectados a Internet, debemos adoptar un nuevo siste- a ma, el DNS o sistema de nombres por dominios (Domain Name System) dise˜ado por Paul Mockapetris. n T´cnicamente, el DNS es una inmensa base de datos distribu´ jer´rquicamente por toda la Internet; exis- e ıda a ten infinidad de servidores que interact´an entre si para encontrar y facilitar a las aplicaciones clientes que u los consultan la traducci´n de un nombre a su direccion de red IP asociada, con la que poder efectuar la o conexi´n deseada. Cada parte de la base de datos est´ replicada en, al menos, dos servidores, lo que asegura o a una debida redundancia. Un servidor de nombres es un programa que se ejecuta en algunos de nuestros sistemas para tener conocimiento de los nombres. Cuando un programa necesita buscar un nombre, en lugar de hacerlo en una copia de la tabla de host, env´ una petici´n al servidor de nombres. Este enfoque tiene ıa o dos ventajas: • Para los grandes sistemas, es m´s f´cil tener al d´ las tablas en algunos servidores de nombres que en a a ıa todo el sistema. • Si nuestra red est´ conectada a Internet, nuestro servidor de nombres ser´ capaz de dialogar con los a a servidores de nombres de otras organizaciones, para buscar nombres de cualquier sitio. Usar un servidor de nombres es el unico camino para tener un acceso completo a la informaci´n del resto de ´ o los hosts de Internet. Es importante comprender la diferencia entre un servidor de nombres y un resolvedor. Un servidor de nombres es un programa que tiene acceso a una base de datos de hosts, y responde peticiones de otros programas. Un resolvedor es un conjunto de subrutinas que pueden cargarse con un programa. El resolvedor genera las peticiones que se enviar´n al servidor de nombres, y procesa sus correspondientes respuestas. a Cada sistema deber´ usar un resolvedor (en general, el resolvedor es cargado por cada programa que va a ıa hacer uso de la red, puesto que s´lo es un conjunto de subrutinas). Hay que recalcar que s´lo se necesitar´n o o a unos pocos servidores de nombres. Mucha gente confunde los dos enfoques y llega a creer que es necesario tener un servidor de nombres en cada ordenador. Para usar un resolvedor, cada ordenador necesitar´ un fichero de configuraci´n, u otro m´todo, para espe- a o e cificar la direcci´n del servidor de nombres al que enviar nuestras peticiones. Por regla general, se pueden o declarar varios servidores de nombres, para el caso de que alguno de ellos no funcione correctamente. En el caso de que nuestro sistema no pudiera contactar satisfactoriamente con ning´n servidor, la mayor´ de u ıa nuestro software empezar´ a fallar. Por tanto, hay que ser muy cuidadoso y declarar tantos servidores ıa como podamos para intentar asegurar un buen funcionamiento. Los servidores de nombres, generalmente, tienen un conjunto de opciones para su configuraci´n. En lugar de o dar algunos consejos sobre c´mo configurar un servidor de nombres, vamos a recomendar dos documentos o oficiales de los est´ndares de Internet. El RFC 1032 contiene las instrucciones sobre c´mo conseguir un a o nombre de dominio del Centro de Informaci´n de Red, incluyendo los formularios necesarios. El RFC 1033 o contiene las instrucciones sobre c´mo configurar un servidor de nombres. Todos estos documentos son de tipo o
  16. 16. 5. Configurando el enrutamiento de cada ordenador 16 conceptual. Seguramente, tambi´n necesitar´ documentaci´n sobre el software espec´ e a o ıfico de su servidor de nombres. En algunos casos, puede que se necesiten, a la vez, tablas y servidores de nombres. Si tenemos alguna implementaci´n de TCP/IP que no incluyan resolvers, estamos obligados a instalar tablas de hosts en o estos sistemas. Si nuestra red est´ conectada a Internet, vamos a tener problemas con aquellos sistemas que a no dispongan de resolvers, ya que Internet es demasiado grande para tener unas tablas de hosts de todos sus hosts. Por lo tanto, lo que se puede hacer es incluir una tabla de hosts con los hosts que realmente se tiene pensado usar. InterNIC tiene a su cargo una tabla de host que puede ser un buen punto de comienzo, aunque no es completa de ning´n modo. As´ que tendremos que a˜adir los hosts favoritos de los usuarios. u ı n Los sistemas que usan resolvers no tendr´n este problema, puesto que un servidor de nombres es capaz de a traducir cualquier nombre legal de host. Los nombres de hosts y la asignaci´n de n´meros son los unicos elementos que deben de tener una estructura o u ´ centralizada. Sin embargo, puede haber otros elementos susceptibles de centralizaci´n. Es bastante frecuente o tener uno o dos ordenadores que se hagan cargo de todo el correo electr´nico. Si estamos conectados a o Internet, es bastante simple establecer comunicaciones con otros ordenadores de Internet. No obstante, hay muchas instituciones que quieren comunicarse con sistemas de otras redes, como Bitnet o Usenet. Hay gateways entre varias de estas redes. Pero la elecci´n del gateway correcto, y transformar la direcci´n de o o correo electr´nico correctamente, es una tarea muy especializada. Por esto, en muchas ocasiones se configura o el software apropiado s´lo en un lugar, y todo el correo externo (o todo el correo externo a hosts que no o est´n en Internet) se dirige a este sistema. a 5 Configurando el enrutamiento de cada ordenador Todas las implementaciones TCP/IP necesitan alguna configuraci´n en cada host. En algunos casos, esto se o hace durante la instalaci´n del sistema de forma casi autom´tica. En otros casos, mediante la configuraci´n o a o de ciertos programas o ficheros. Y, por ultimo, otros sistemas obtienen la informaci´n de configuraci´n a ´ o o trav´s de la red de un ”servidor”. e A pesar de que los detalles de la configuraci´n pueden diferir bastante, existen ciertos datos que deben o incluirse en todos los casos. Entre ellos: • par´metros que describan a una m´quina en particular, como su direcci´n IP; a a o • par´metros que describan la red, como su subm´scara de red (si hubiera); a a • software de enrutamiento y las tablas que use; • otros programas necesarios para el funcionamiento de otras tareas de red. Antes de que se instale un ordenador en una red, un coordinador deber´ asignarle un nombre de red y su a direcci´n IP, como describimos anteriormente. Una vez otorgado un nombre y una direcci´n estamos en o o disposici´n de configurarlo. En numerosas ocasiones, lo que debemos hacer es poner la direcci´n y el nombre o o en un fichero de configuraci´n. Sin embargo, algunos ordenadores (especialmente aquellos que no disponen de o un disco propio en el que dicha informaci´n pueda ser almacenada) deben obtener esta informaci´n a trav´s o o e de la red. En el momento en que un sistema arranca, se realiza un broadcast a la red con la petici´n ”¿qui´n o e soy?”. En el caso de poseer ordenadores de este tipo, debemos asegurarnos de que nuestra red est´ preparada a para responder adecuadamente. La pregunta l´gica es: ¿c´mo otro sistema sabe qui´n eres?. Generalmente, o o e esto se soluciona haciendo uso de las direcciones Ethernet (o las direcciones an´logas para otro tipo de redes). a Las direcciones Ethernet son asignadas por los fabricantes hardware. Est´ garantizado que s´lo una m´quina a o a en todo el mundo tiene una determinada direcci´n Ethernet. Por lo general, dicha direcci´n est´ grabada en o o a una ROM en la tarjeta Ethernet de la m´quina. La m´quina, probablemente, no conozca su direcci´n IP, a a o

×