Introducción a la administración de una red local basada en Internet - Configurando el enrutamiento de cada ordenador (I)

Todas las implementaciones TCP/IP necesitan alguna configuración en cada host. En algunos casos, esto se hace durante la instalación del sistema de forma casi automática. En otros casos, mediante la configuración de ciertos programas o ficheros. Y, por último, otros sistemas obtienen la información de configuración a través de la red de un "servidor".

A pesar de que los detalles de la configuración pueden diferir bastante, existen ciertos datos que deben incluirse en todos los casos. Entre ellos:

- parámetros que describan a una máquina en particular, como su dirección IP;

- parámetros que describan la red, como su submáscara de red (si hubiera);

- 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 dirección IP, como describimos anteriormente. Una vez otorgado un nombre y una dirección estamos en disposición de configurarlo. En numerosas ocasiones, lo que debemos hacer es poner la dirección y el nombre en un fichero de configuración. Sin embargo, algunos ordenadores (especialmente aquellos que no disponen de un disco propio en el que dicha información pueda ser almacenada) deben obtener esta información a través de la red. En el momento en que un sistema arranca, se realiza un broadcast a la red con la petición "¿quién soy?" . En el caso de poseer ordenadores de este tipo, debemos asegurarnos de que nuestra red está preparada para responder adecuadamente. La pregunta lógica es: ¿cómo otro sistema sabe quién eres?. Generalmente, esto se soluciona haciendo uso de las direcciones Ethernet (o las direcciones análogas para otro tipo de redes). Las direcciones Ethernet son asignadas por los fabricantes hardware. Está garantizado que sólo una máquina en todo el mundo tiene una determinada dirección Ethernet. Por lo general, dicha dirección está grabada en una ROM en la tarjeta Ethernet de la máquina. La máquina, probablemente, no conozca su dirección IP, pero sin duda conoce su dirección Ethernet. Por esta razón, la petición "¿quién soy?" incluye la direcciòn Ethernet. Y habrá sistemas configurados para responder a estas peticiones, buscando en una tabla que hace corresponder a cada dirección Ethernet su dirección IP. Pero, por desgracia, deberemos configurar y actualizar esta tabla perodicamente. Para este fin se usa el protocolo de RARP (Reverse Address Resolution Protocol); existe además otro protocolo, el BOOTP o protocolo de arranque. En general, los ordenadores están diseñados de tal manera que muestran su dirección Ethernet por pantalla, tan pronto como se enciende el mismo. Y, en la mayoría de los casos, disponemos de un comando que muestra esta información del interfaz Ethernet.

Generalmente, la máscara de subred debe especificarse en un determinado archivo (en los sistemas Unix, el comando "ifconfig" , donde "if" significa interface, se usa para especificar tanto la dirección Internet como la máscara de subred). No obstante, hay previsiones en los protocolos IP para permitir un broadcast de un ordenador, preguntando por la máscara de red. La submáscara de red es un atributo de la red y, por ello, es el mismo para todos los ordenadores de una determinada subred. No hay una tabla de subred independiente de la tabla de las correspondencias Ethernet/ Internet, usada para consulta de direcciones. Idealmente, sólo determinados ordenadores contestan peticiones de la máscara de red, pero, en muchas implementaciones TCP/IP, están diseñadas de tal manera que si un ordenador cree conocer la máscara de red debe contestar, y, por tanto, en estas implementaciones, la mala configuración de la máscara de subred en un solo ordenador puede causar un mal funcionamiento de la red.

Por regla general, los ficheros de configuración hacen, a grosso modo, las siguientes cosas:


* Cargar un driver especial para los dispositivos que sean necesarios (esto es bastante usual en los PC's, donde los accesos a red son controlados por una tarjeta controladora y un software que no forma parte del sistema operativo).

* Habilitar cada interfaz de red (Ethernet, líneas serie, etc.). Normalmente, esto conlleva la especificación de una dirección Internet y una máscara de red para cada uno, así como otras opciones especiales de cada dispositivo.

* Establecimiento de la información de enrutamiento de la red, tanto por comandos que establecen rutas, como ejecucando un programa que las obtiene dinámicamente.

* Activar el sistema de dominios (usado para buscar nombres y encontrar la correspondiente dirección Internet -mirar la sección del sistema de dominio, en la Introducción al TCP/IP-). Los detalles dependerán del sistema de dominios usado. En la mayoría de los casos, sólo algunos hosts deberán ejecutar el servidor de nombres de dominios. Los otros hosts, simplemente, necesitan ficheros de configuración, que especifican dónde se encuentra el servidor más cercano.

* Establecer otro tipo de información necesaria para el sistema software, como, por ejemplo, el nombre del propio sistema.

* Lanzar varios demonios ( "daemons"). Hay programas que proveen de servicios de red a otros sistemas de la red, y a los usuarios de estos sistemas. En el caso de los PC's, que en muchos casos no soportan el multiproceso, y dichos servicios, se establecen mediante los llamados "TSR", o mediante los drivers del dispositivo.

Cómo enrutar los datagramas

Si nuestro sistema consiste en una simple Ethernet, o un medio similar, no será necesario prestar demasiada atención al enrutamiento. Pero, para sistemas más complejos, cada una de las máquinas necesita una tabla que contenga el gateway y el interfaz necesario para cada posible destino. Vimos un ejemplo simple en una sección anterior, pero ahora es necesario describir el modo como funciona el enrutamiento, con un poco más de detalle. En la inmensa mayoría de los sistemas, la tabla de enrutamiento tendrá un aspecto similar (este ejemplo ha sido tomado de un sistema con Berkeley Unix, usando el comando "netstat -n -r"; algunas columnas que contienen información estadística han sido omitidas):

Destino         Gateway     Bandera     Interface

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

128.6.5.3         128.6.7.1     UHGD     il0

128.6.5.21        128.6.7.1     UHGD     il0

127.0.0.1         127.0.0.1     UH       lo0

128.6.4           128.6.4.61      U      pe0

128.6.6           128.6.7.26      U      il0

128.6.7           128.6.7.26      U      il0

128.6.2           128.6.7.1       UG     il0

10                128.6.4.27      UG     pe0

128.121           128.6.4.27      UG     pe0

default           128.6.4.27      UG     pe0

El sistema del ejemplo está conectado a dos Ethernet:

Controlador Red Direccion Otras Redes

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

il0 128.6.7 128.6.7.26 128.6.6

pe0 128.6.4 128.6.4.61 ninguna

La primera columna muestra el nombre de la interface Ethernet; la segunda, es el número de red para esa Ethernet; la tercera columna es la dirección Internet de esa red, y, la última muestra otras subredes que comparten la misma red física.

Estudiemos la tabla de enrutamiento; por el momento, ignoraremos las tres primeras líneas. La mayor parte de la tabla consiste en un conjunto de entradas describiendo las redes. Para cada red, las otras tres columnas muestran a dónde deben ser enviados los datagramas destinados a dicha red. Si aparece la bandera "G" en la tercera columna, los datagramas tienen que enviarse a través de un gateway; en caso de no aparecer, el ordenador está directamente conectado a la red en cuestión. Así que los datagramas para dichas redes deben enviarse usando el controlador especificado en la cuarta columna. La bandera "U", de la tercera columna, sólo indica que la ruta especificada por esa línea está activa (generalmente, se asume que estará abierta, a no ser que se produzcan errores tras varios intentos).

Las tres primera líneas muestran "rutas a hosts", indicándose con "H" en la tercera columna. Las tablas de enrutamiento, normalmente, tienen entradas para redes o subredes. Por ejemplo, la entrada

128.6.2 128.6.7.1 UG il0

indica que un datagrama para cualquier ordenador de la red 128.6.2 (es decir, direcciones desde 128.6.2.1 hasta 128.6.2.254) debe enviarse al gateway 128.6.7.1, para llevarlo a cabo. En algunas ocasiones, se establecen rutas para un ordenador específico, en lugar de una red entera. En este caso, se usa una ruta al host. En la primera columna aparece una dirección completa, y la bandera "H" está presente en la columna tres; por ejemplo, la entrada

128.6.5.21 128.6.7.1 UHGD il0

indica que un datagrama, dirigido en concreto a la dirección 128.6.5.21, debe ser enviado al gateway 128.6.7.1. Al igual que en los enrutamientos a redes, la bandera "G" se usa cuando en el enrutamiento se ve involucrado un gateway, y la bandera "D" indica que el enrutamiento fue añadido dinámicamente, usando un mensaje ICMP de redirección desde un gateway (más adelante daremos más detalles).

El siguiente enrutamiento es especial:

127.0.0.1 127.0.0.1 UH lo0

donde, 127.0.0.1 es el dispositivo de "lazo cerrado", o loopback. Cualquier datagrama enviado a través de este dispositivo aparece inmediatamente como entrada. Es muy útil para hacer pruebas. Las direcciones de "lazo cerrado" pueden, también, ser usadas para comunicar aplicaciones que están en el propio ordenador. (¿Por qué molestarnos en usar la red para comunicarnos con programas que se encuentran en la misma máquina?).

Por último, hay una ruta por defecto ("default"), como es

default 128.6.4.27 UG pe0

Esta ruta será seguida por aquellos datagramas que no se correspondan con ninguna de las anteriores. En nuestro ejemplo, se enviarán a un gateway de dirección 128.6.4.27.

Como último ejemplo veamos la tabla de enrutamiento de un sistema Linux conectado a Internet mediante una linea PPP, usando el comando "netstat -n -r"; algunas columnas que contienen información estadística han sido omitidas.

Destino Gateway Bandera Interface

ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

172.16.1.33 0.0.0.0 UH ppp0

128.0.0.1 0.0.0.0 U l0

0.0.0.0 172.16.1.33 UG ppp0

Hay que aclarar que 0.0.0.0 representa al enrutamiento por defecto, es el valor numérico de default. En este ejemplo, al sistema se le ha asignado la dirección IP 172.16.1.3 de forma dinámica, de manera que usa la linea PPP para conectarse con Internet, y 127.0.0.1 es el dispositivo loopback. Antes de la conexión PPP solamente estaba activo el dispositivo de "lazo cerrado", pero una vez establecida la conexión PPP se activa el interface ppp0 ( 0 indica un identificativo de interface ppp; es decir, si hubiera otra línea ppp se etiquetaría como ppp1, etc), se usa el sistema del otro lado de la linea como un gateway por defecto, como se puede apreciar en la última linea.

En muchos sistemas, los datagramas son enrutados consultando la direción de destino en una tabla como la que acabamos de describir. Si la dirección se corresponde con una ruta específica a un host, ésta será usada; en otro caso, si se corresponde con un enrutamiento a red, se usará ésta; y, si nada de lo anterior acontece, se usará el enrutamiento por defecto. En caso de no existir uno por defecto, aparecería un mensaje de tipo "red inalcanzable" ("network is unreachable").

En las siguientes secciones describiremos varias maneras de configurar estas tablas de enrutamiento. Generalmente, la operación de enviar datagramas no depende del método usado en la configuración de estas tablas. Cuando un datagrama va a ser enviado, su destino es consultado en la tabla. Los distintos métodos de enrutamiento son simplemente, más o menos, una serie de sofisticadas formas de configurar y mantener las tablas.

Rutas fijas

La forma más fácil de configurar el enrutamiento es usar comandos que lo fijan. Nuestros archivos de inicialización contienen comandos que configuran el enrutamiento. Si es necesario algún cambio, deberá hacerse, normalmente, usando comandos que añaden y borran entradas de la tabla de enrutamiento (cuando se realice un cambio, no debemos olvidar actualizar el fichero de inicialización también). Este método es práctico para redes relativamente pequeñas, especialmente cuando los cambios no son muy frecuentes.

Muchos ordenadores configuran automáticamente algunas entradas de enrutamiento por nosotros. Unix añade una entrada para las redes a las que estamos directamente conectados. Por ejemplo, un fichero de inicialización podría ser

ifconfig ie0 128.6.4.4 netmask 255.255.255.0

ifconfig ie1 128.6.5.35 netmask 255.255.255.0

Este especifica que hay dos interfaces de red y sus direcciones en ellas. El sistema crea automáticamente estas entradas en la tabla de enrutamiento

128.6.4 128.6.4.4 U ie0

128.6.5 128.6.5.35 U ie1

y, en ésta, se especifica que los datagramas para las redes locales 128.6.4 y 128.6.5 deben ser enviados a las corespondientes interfaces.

Además de éstos, el fichero de inicialización podría contener comandos para definir rutas a cualquier otra red a la que queramos acceder. Por ejemplo,

route add 128.6.2.0 128.6.4.1 1

route add 128.6.6.0 128.6.5.35 0

Estos comandos determinan que para alcanzar la red 128.6.2 debemos usar el gateway de dirección 128.6.5.1, y esa red 128.6.6 es, realmente, un número de red adicional para una red física conectada al interface 128.6.5.35. Otro tipo de software puede usar comandos distintos a estos casos. Unix se diferencia de ellos por el uso de una métrica, que es el número final del comando. La métrica indica cuántos gateways tiene que atravesar un datagrama para alcanzar su destino. Rutas de métrica 1 ó más indican que hay en el camino sólo un gateway hasta el destino. Rutas de métrica 0 indican que no hay ningún gateway implicado -es un número de red adicional para la red local-.

En último lugar, podemos definir un enrutamiento por defecto, usado cuando el destino no está listado explícitamente. Normalmente, se suele acompañar de la dirección de un gateway que tiene suficiente información como para manejar todos los posibles destinos.

Si nuestra red sólo dispone de un gateway, entonces sólo necesitaremos una sola entrada por defecto. En este caso, no deberemos preocuparnos más de la configuración del enrutamiento de los hosts (el gateway, en sí, necesitará más atención, como veremos). Las siguientes secciones nos ayudarán para configurar redes donde hay varios gateways.




Reconducir el enrutamiento

La mayoría de los expertos recomiendan dejar las decisiones de enrutamiento a los gateways. Por tanto, probablemente, será una mala idea tener largas tablas estáticas de enrutamiento en cada ordenador. El problema está en que cuando algo cambia en la red tenemos que actualizar las tablas en demasiados ordenadores. Si el cambio ocurre debido a que cae una línea, el servicio no se restablecerá hasta que alguien se de cuenta del problema y cambie todas las tablas de enrutamiento.

La manera más fácil de tener actualizado el enrutamiento es depender sólo de un único gateway y actualizar su tabla de enrutamiento. Este gateway debe fijarse como gateway por defecto. (En Unix esto significa usar un comando como "route add default 128.6.4.27 1" , donde 128.6.4.27 es la dirección del gateway). Como describimos anteriormente, el sistema enviará todos aquellos datagramas a dicho gateway cuando no haya una ruta mejor. En principio, parece que esta estrategia no es demasiado buena cuando poseemos más de un gateway; máxime, cuando todo lo que tenemos es sólo la entrada por defecto. ¿Cómo usaremos los otros gateways en los casos en los que éstos sean más recomendables? La respuesta es que los datagramas correspondientes serán redirigidos a estos gateways en estos casos. Un "redireccionamiento" es una clase específica de mensaje ICMP (Internet Control Message Protocol), que contiene información del tipo "En el futuro, para llegar a la dirección XXXXX, intenta usar YYYYY en lugar de mí". Las implementaciones que cumplen completamente los protocolos TCP/IP usan estas técnicas de redireccionamiento para añadir entradas a las tablas de enrutamiento. Supongamos que una tabla inicialmente es como sigue:




Destino Gateway Bandera Interface

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿

³ 127.0.0.1 ³ 127.0.0.1 ³ UH ³ lo0 ³

ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ

³ 128.6.4 ³ 128.6.4.61 ³ U ³ pe0 ³

ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄŽ

³ default ³ 128.6.4.27 ³ UG ³ pe0 ³

ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

donde hay una entrada para la red local 128.6.4, y una entrada por defecto del gateway 128.6.4.27. Supongamos que hay también un gateway 128.6.4.30, que es el mejor camino para acceder a la red 128.6.7. ¿Cómo podemos llegar a usar este camino? Supongamos que tenemos unos datagramas para enviar a 128.6.7.23. El primer datagrama llegará al gateway por defecto, puesto que es el único que aparece en la tabla de enrutamiento, y el gateway se dará cuenta de que el mejor camino debe pasar por 128.6.4.30 (Hay distintos métodos para que un gateway determine que debe usarse otro para un mejor enrutamiento). Por tanto, 128.6.4.27 contestará con un mensaje de redireccionamiento especificando que los datagramas para 128.6.7.23 deben enviarse a través del gateway 128.6.4.30. El software TCP/IP añadirá una entrada a la tabla de enrutamiento

128.6.7.23 128.6.4.30 UDHG pe0

De esta manera, los restantes datagramas al 128.6.7.23 se enviarán directamente al gateway apropiado.

Esta estrategia sería perfecta si no fuera por los siguientes tres problemas:

* Necesita que cada ordenador contenga la dirección de un gateway por defecto en los ficheros de configuración.

* En caso de que un gateway falle, las entradas de las tablas de enrutamiento que usan dicho gateway no se eliminan.

* Si la red usa subredes y la implementación TCP/IP usada no las maneja, esta estrategia no podrá emplearse.

El alcance del problema depende del tipo de red de la que disponemos. Para redes pequeñas, apenas supondrá un problema cambiar los ficheros de configuración de algunas máquinas. Sin embargo, para algunas organizaciones este trabajo es difícil de llevar a cabo. Si, por ejemplo, la topología de la red cambia y un gateway es eliminado, cualquier sistema que tenga dicho gateway por defecto deberá ser ajustado. Este problema será especialmente grave si el personal encargado del mantenimiento de la red es distinto del encargado de mantener a los sistemas individualmewnte. La solución más simple consiste en asegurarnos de que la dirección por defecto nunca cambiará. Por ejemplo, podríamos adoptar el convenio de que la dirección 1 de cada subred se corresponde con el gateway por defecto de cada subred; así, en la subred 128.6.7, el gateway por defecto sería siempre el 128.6.7.1. Si dicho gateway es eliminado, habrá que asignarle dicha dirección a algún otro gateway (siempre tendrá que haber, al menos, un gateway, puesto que si no es así estaremos completamente incomunicados).

Hasta ahora hemos visto cómo añadir rutas, pero no cómo deshacernos de ellas. ¿Qué ocurre si un gateway no funciona correctamente?. Nuestro deseo sería que se recondujera a un gateway operativo, pero desgraciadamente, un gateway en mal funcionamiento no tendrá en general esta capacidad de redireccionamiento. La solución más obvia es usar gateways fiables. El redireccionamiento puede usarse para controlar distintos tipos de fallos.

La mejor estrategia para controlar gateways averiados es que nuestra implementación TCP/IP detecte las rutas que no tienen éxito. TCP mantiene varios contadores que permiten al software detectar cuándo una conexión se ha roto. Cuando esto ocurre, se puede marcar esta ruta como fallida y volver al gateway por defecto. Una solución similar puede usarse para manejar fallos en el gateway por defecto. Si configuramos dos gateways por defecto, entonces el software deberá ser capaz de cambiar el gateway cuando las conexiones en uno de ellos empiecen a fallar. Sin embargo, algunas implementaciones TCP/IP no pueden marcar rutas como fallidas y empezar a usar otras. En particular, Berkeley 4.2 Unix no lo hace; pero Berkeley 4.3 Unix sí, lo que empieza a hacerse cada vez más común. Hasta implementaciones de Unix para PC como Linux ya incorporan esta posibilidad (Linux en concreto puede controlar hasta cuatro gateways por defecto).