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.
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:
gateways
usan sólo
las rutas que queremos;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: