Introducción a la Administración de una Red Local basada en Internet - Configurando gateways

Vamos a ver algunos aspectos específicos de la configuración de gateways. Aquellos gateways que entienden el protocolo IP son, al mismo tiempo, hosts de Internet y, por tanto, podemos poner en práctica lo visto para configurar las direcciones y el enrutamiento en los hosts. No obstante, la forma exacta de cómo debemos configurar un gateway depende del modelo en concreto. En algunos casos, deberemos editar algunos ficheros incluídos en un disco del propio gateway. Sin embargo, por razones de fiabilidad, la mayoría de los gateways no tienen discos propios; en su lugar, esta información se almacena en una memoria no volátil o en ficheros que se cargan desde uno o varios hosts de la red.

Como mínimo, para configurar el gateway hay que especificar la dirección IP y la máscara de cada interface, y activar un protocolo de enrutamiento adecuado. Normalmente será deseable configurar otros parámetros.

Un parámetro importante a tener en cuenta es la dirección de broadcast. Como explicamos con anterioridad, hay cierto software antiguo que no funciona bien cuando se envían broadcasts usando los nuevos protocolos de direcciones de broadcast. Por esta razón, algunos modelos nos permiten elegir una dirección broadcast para cada interface. Por tanto, en ese caso, se deberán configurar teniendo en cuenta los ordenadores que hay en la red. En general, si los ordenadores soportan los actuales estándares, podrá usarse una dirección del tipo 255.255.255.255. No obstante, antiguas implementaciones deben comportarse mejor con otro tipo de direcciones, especialmente con aquellas direcciones que usan ceros para los números del host (para la red 128.6 ésta tendría que ser 128.6.0.0. Para mantener la compatibilidad con redes que no soportan sub-redes deberíamos usar 128.6.0.0 como dirección de broadcast, incluso para una subred del tipo 128.6.4). Podemos observar nuestra red con un monitor de red y ver los resultados de las distintas elecciones de direciones de broadcast; en caso de que hagamos una mala elección, cada vez que hagamos un broadcast para actualizar el enrutamiento, muchas máquinas de nuestra red nos responderían con errores ARP o ICMP. Hay que hacer notar que cuando cambiamos las direcciones de broadcast en el gateway, necesitaremos cambiarla también en cada uno de los ordenadores. Lo que se suele hacer es cambiar la dirección de aquellos sistemas que podemos configurar, para hacerlos compatibles con los otros sistemas que no podemos configurar.

Hay otros parámetros de la interface que pueden que sea necesario configurar para trabajar con las peculiaridades de la red a la que se conectan. Por ejemplo, muchos gateways comprueban sus interfaces a Ethernet para asegurarse de que el cable al que se conectan y el transceiver funcionan correctamente. Algunos de estos tests no funcionan correctamente con la antigua versión 1 de transceiver Ethernet. En caso de que usemos un transceiver de este tipo, deberemos desactivar este tipo de test. De forma similar, los gateways conectados a líneas en serie normalmente hacen este tipo de test para verificar su buen funcionamiento, y también hay situaciones en las que necesitaremos deactivar el test.

Es bastante usual que tengamos que activar las opciones necesarias para el software que tengamos que usar. Por ejemplo, muchas veces es necesario activar explícitamente el protocolo de administración de red, y dar el nombre o la dirección del host donde se ejecuta el software que acepta traps (mensajes de error).

La mayoría de los gateways tienen opciones relacionadas con la seguridad. Como mínimo, hay que indicar un password para poder hacer cambios de forma remota (y una "session name" para SGMP). Si queremos controlar el acceso a ciertas partes de la red, también deberemos definir una lista de control de accesos, o cualquier otro mecanismo que use el gateway en cuestión.

Los gateways cargan la información de la configuración a través de la red. Cuando un gateway arranca, envía una petición broadcast de varias clases, intentando conocer su dirección Internet para luego cargar su configuración. Así, hay que asegurarse que haya algunos ordenadores capaces de responder a dichas peticiones. En algunos casos, hay algún micro dedicado ejecutando un software especial. Otras veces, hay un software genérico que podemos ejecutar en varias máquinas. Por razones de fiabilidad, debemos comprobar que hay más de un host con la información y los programas que necesita. En algunos casos tendremos que mantener varios archivos distintos. Por ejemplo, los gateways usados en Groucho usan un programa llamado "bootp" para que le proporcione su dirección Internet, y luego cargan el código y la información de la configuración usando TFTP. Esto significa que tenemos que mantener un archivo para "bootp" que contiene las direcciones Ethernet e Internet para cada gateway, y un conjunto de archivos para la restante información de cada uno de ellos. Si una red es muy grande, podemos tener problemas para asegurarnos de que esta información permanece consistente. Podemos mantener copias nuestras de todas las configuraciones en un único ordenador y que se distribuya a otros sistemas cuando haya algún cambio, usando las facilidades make y rdist de Unix. Si nuestro gateway tiene la opción de almacenar la información de la configuración en una memoria no volátil, podremos eliminar todos estos problemas logísticos, pero presenta sus propios problemas. El contenido de esta memoria debería almacenarse en alguna localización central, porque de todas maneras es difícil para el personal de administración de la red revisar la configuración si se encuentra distribuída entre los distintos gateways.

Arrancar un gateway que carga la información de su configuración desde una localización distante es especialmente arriesgado. Los gateways que necesitan cargar su información de configuraciòn a través de la red, generalmente emiten una petición broadcast a todas las redes que conectan. Si algún ordenador de una de esas redes es capaz de responder, no habrá ningún problema. Sin embargo, algunos gateways que se encuentren a gran distancia donde los ordenadores de su alrededor no soportan los protocolos necesarios, en cuyo caso es necesario que las respuestas le lleguen a través de una red donde haya unos ordenadores apropiados. Desde un punto de vista estricto, esto va en contra de la filosofía de trabajo de los gateways, ya que normal mente un gateway no permite que un broadcast procedente de una red pase a través de una red adyacente. Para permitir que un gateway obtenga información de un ordenador en una red distinta, al menos uno de los gateways que está entre ellos tendrá que configurarse para que pase una clase especial de broadcast usado para recuperar este tipo de información. Si tenemos este tipo de configuración, tendremos que comprobar este proceso periódicamente, ya que no es raro que nos encontremos con que no podamos arrancar un gateway tras un fallo de energía, debido a un cambio en la configuración en otro gateway que hace imposible cargar esta información.

Configurando el enrutamiento de los gateways

Por último, vamos a tratar cómo configurar el enrutamiento. Este tipo de configuración es más difícil para un gateway que para un host. La mayoría de los expertos TCP/IP recomiendan dejar las cuestiones de enrutamiento a los gateways. Así, los hosts simplemente tienen una ruta por defecto que apunta al gateway más cercano (por supuesto, los gateways no pueden configurarse de esta manera. Ellos necesitan tablas completas de enrutamiento).

Para entender cómo configurar un gateway, vamos a examinar con un poco más de detalle cómo los gateways se comunican las rutas.

Cuando encendemos un gateway, la única red de la que tiene información es aquélla a la que esté directamente conectado (lo que se especifica en la configuración). Para llegar a saber cómo se llega a partes más distantes de la red, marca algún tipo de "protocolo de enrutamiento", que simplemente es un protocolo que permite a cada gateway anunciar a qué redes tiene acceso, y extender esa información de un gateway a otro. Eventualmente, cada gateway debería saber cómo llegar a cada red. Hay distintos tipos de protocolos de enrutamiento; en el más común, los gateways se comunican exclusivamente con los más cercanos; en otra clase de protocolos, cada gateway construye una base de datos describiendo cada gateway del sistema. No obstante, todos estos protocolos encuentran cómo llegar a cualquier destino.

Una métrica es un número, o conjunto de números, usado para comparar rutas. La tabla de enrutamiento se construye recogiendo información de otros gateways. Si dos gateways son capaces de llegar a un mismo destino, debe de haber algún método para decidir cuál usar. La métrica se usa para tomar esta decisión. Todas las métricas indican de alguna forma lo "costoso" de una ruta. Podría ser cuántos dólares costaría enviar un datagrama por una ruta, el retraso en milisegundos, o cualquier otra medida. La métrica más simple es el número de gateways que hay hasta el destino ("cuenta de saltos"), y es la que generalmente se encuentra en los ficheros de configuración.

Como mínimo, una configuración de enrutamiento consistiría en un comando para activar el protocolo de enrutamiento que vayamos a usar. La mayoría de los gateways están orientados para usar un protocolo; a no ser que tengamos razones para usar otro, es recomendable usar dicho protocolo. Una razón habitual para elegir otro protocolo es para hacerlo compatible con otros gateways. Por ejemplo, si nuestra red está conecta da a una red nacional que nos exige usar EGP ("exterior gateway protocol") para que se pueda intercambiar rutas con ella, EGP sólo es apropiado para este caso específico. No deberemos usar EGP dentro de nuestra propia red, sino sólo para comunicarnos con la red nacional. Si tenemos varias clases de gateways, necesitaremos usar un protocolo entendible por todos ellos. En muchas ocasiones este protocolo será RIP (Routing Information Protocol). A veces podremos usar protocolos más complejos entre los gateways que los soporten, y usar RIP sólo cuando nos comuniquemos con gateways que no entiendan estos protocolos.

Si ya hemos elegido un protocolo de enrutamiento y lo hemos puesto en marcha, todavía nos quedan por tomar algunas decisiones. Una de las tareas mas básicas de configuración que tenemos que completar es uministrar la información de la métrica. Los protocolos más simples, como RIP, normalmente usan "cuenta de saltos", de manera que una ruta que pasa a través de dos gateways es mejor que una que pasa por tres. Por supuesto, si la última ruta usa líneas de 1'5 Mbps y la primera líneas de 9.600 bps, sería una mala elección. La mayoría de los protocolos de enrutamiento tienen medios para tomar esto en cuenta. Con RIP, podríamos tratar las líneas de 9.600 bps como si fueran "saltos" adicionales, de manera que la mejor línea (la más rápida) tenga una métrica menor. Otros protocolos más sofisticados tendrán en cuenta la velocidad de la línea de forma automática. Generalmente, estos parámetros deberán asociarse a una interface en particular. Por ejemplo, con RIP deberemos establecer explícitamente el valor de la métrica, si se está conectado con una línea de 9.600 bps. Con aquellos protocolos que tienen en cuenta la velocidad de las líneas, deberemos de especificar la velocidad de las líneas (si el gateway no los puede configurar automáticamente).

La mayor parte de los protocolos de enrutamiento han sido diseñados para que cada gateway se aprenda la topología de toda la red, y elegir la mejor ruta posible para cada datagrama. En algunos casos no estaremos interesados en la mejor ruta; por ejemplo, puede que estemos interesados en que el datagrama se desplace por una parte de la red por razones de seguridad o económicas. Una manera de tener este control es especificando opciones de enrutamiento. Dichas opciones varían mucho de un gateway a otro, pero la estrategia básica es que si el resto de la red no conoce dicha ruta, no será utilizada. Estos controles limitan la forma en la que se van a usar las rutas.

Hay métodos para que el usuario ignore las decisiones de enrutamiento hechas por los gateways. Si realmente necesitamos controlar el acceso a ciertas redes, podemos hacer dos cosas:

• los controles de enrutamiento nos aseguran que los gateways usan sólo las rutas que queremos;
• usar listas de control de acceso en los gateways adyacentes a las redes controladas.

Estas dos opciones trabajan a distinto nivel. Los controles de enrutamiento afectan a lo que ocurre a la mayoría de los datagramas: aquéllos en los que el usuario no ha especificado manualmente una ruta. Nuestro mecanismo de enrutamiento ha de ser capaz de elegir una ruta aceptable para ellos. Una lista de control de acceso añade una limitación adicional, preservándonos de usuarios que incluyesen su propio enrutamiento y pasasen nuestros controles.

Por razones de fiabilidad y seguridad, puede que también haya controles con listas de gateways de las que podemos aceptar información. También es posible hacer una clasificación de prioridad. Por ejemplo, podemos decidir hacer antes los enrutamientos de nuestra propia organización antes que los de otras organizaciones, u otras partes de la organización. Esto tendrá el efecto de dar preferencia al tráfico interno frente al externo, incluso si el externo parece ser mejor.

Si usamos varios protocolos distintos de enrutamiento, probablemente tendremos que afrontar algunas decisiones respecto a la información que se pasan entre ellos. Puesto que el uso de varios protocolos de enrutamiento está frecuentemente asociado a la existencia de varias organizaciones, deberemos de tomar la precaución de hacer estas decisiones consultando con los administradores de las redes de dichas organizaciones. Este tipo de decisiones puede tener consecuencias en las otras redes bastante difíciles de detectar. Podríamos pensar que la mejor forma de configurar un gateway es que fuese capaz de entender todos los protocolos, pero hay algunas razones por las que esto no es recomendable:

• Las métricas usadas por los distintos protocolos no son compatibles en muchas ocasiones. Si estamos conectados a dos redes externas distintas, podemos especificar que una siempre debe usarse preferentemente a la otra, o que la más cercana es la que debe usarse, en lugar de comparar la métrica recibida de las dos redes para ver cuál tiene la mejor ruta.
• EGP es especialmente delicado, ya que no admite bucles. Por esto hay unas reglas estrictas para regular la información que hay que intercambiar para comunicarse con una red principal usando EGP. En aquellos casos en que se use EGP, el administrador de la red principal debería ayudarnos a configurar el enrutamiento.
• Si tenemos líneas lentas en nuestra red (9.600 bps o menos), puede que no queramos enviar la tabla de enrutamiento completa a través de la red. Si nos conectamos a una red exterior, tenemos la posibilidad de tratarla como una ruta por defecto, en lugar de introducir toda su información en nuestro protocolo de enrutamiento.