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

Otros métodos para que los hosts encuentren rutas

En tanto en cuanto las implementaciones TCP/IP manejan caídas de las conexiones adecuadamente, estableciendo una o más rutas por defecto en el fichero de configuraciones, se produce probablemente la foma más simple de controlar el enrutamiento. No obstante, hay otras dos técnicas de enrutamiento dignas de consideración para algunos casos especiales:

* espiar el protocolo de enrutamiento,

* usar un proxy ARP.

Espiar el enrutamiento

Los gateways, por regla general, tienen un protocolo especial que usan entre ellos. Hay que aclarar que el redireccionamiento no puede ser usado por los gateways, ya que éste es simplemente el mecanismo por el cuál ellos informan a simples hosts que tienen que usar otro gateway. Los gateways deben tener una visión completa de la red y un método para para calcular la ruta óptima a cada subred. Generalmente, los gateways mantienen esta visión mediante el intercambio de información entre ellos. Hay varios protocolos distintos de enrutamiento para este propósito. Una alternativa para que un ordenador siga la pista a los gateways es escuchar los mensajes que se intercambian entre ellos. Hay software capaz de hacer esto para la mayoría de los protocolos. Cuando ejecutamos este software, el ordenador mantendrá una visión completa de la red, al igual que los gateways. Este software normalmente está diseñado para mantener dinámicamente las tablas de enrutamiento del ordenador, así que los datagramas se enviarán siempre al gateway más adecuado. De hecho, el enrutamiento realizado es equivalente a ejecutar los comandos Unix "route add" y "route delete" a medida que la topología cambia. El resultado suele ser una completa tabla de enrutamiento, en lugar de una con unas rutas por defecto. (Este enfoque asume que los gateways mantienen entre ellos una tabla completa. Algunas veces los gateways tienen constancia de todas nuestras redes, pero usan una ruta por defecto para las redes ajenas al campus, etc.).

Ejecutando el software de enrutamiento en cada host resolveremos de alguna manera el problema de enrutamiento, pero hay algunas razones por las que normalmente no es recomendable, reservándola como última alternativa. El problema más serio incorpora numerosas opciones de configuración, que deben mantenerse en cada ordenador. Además, los actuales gateways suelen añadir opciones cada vez más complejas. Por tanto, no es deseable extender el uso de este software en todos los hosts.

Hay otro problema más específico referido a los ordenadores sin discos. Como es natural, un ordenador sin discos depende de la red y de los servidores de ficheros para cargar los programas y hacer swapping. No es recomendable que estos ordenadores escuchen las emisiones de la red. Por ejemplo, cada gateway de la red debe emitir sus tablas de enrutamiento cada 30 segundos. El problema es que el software que escucha estas emisiones debe ser cargado a través de la red. En un ordenador ocupado, los programas que no son usados durante algunos segundos deben guardarse haciendo swapping o paginación. Cuando se activan de nuevo, han de recuperarse. Cuando una emisión de un gateway es enviada en la red, cada ordenador activa su software de red para procesar dicha emisión, lo cual significa que todos ellos intentan hacer una recuperación al mismo tiempo y, por tanto, es probable que se produzca una sobrecarga temporal de la red.

Proxy ARP

Los proxy ARP son otra técnica para permitir a los gateways tomar todas las decisiones de enrutamiento. Son aplicables a aquellas redes que usan ARP (Address Resolution Protocol), o una técnica similar para corresponder las direcciones Internet con direcciones de redes específicas, como las direcciones Ethernet. Para facilitar la explicación, vamos a asumir redes Ethernet. Los cambios necesarios para otros tipos de redes consistirán en poner la correspondiente dirección de red, en lugar de "dirección Ethernet", y protocolo análogo a ARP para dicha red.

En muchos aspectos, los proxy ARP son semejantes al uso de una ruta por defecto y redireccionamiento, y la mayor diferencia radica en que tienen distintos mecanismos para comunicar rutas a los hosts. Con el redireccionamiento se usa una tabla completa de enrutamiento, de forma que en cualquier momento un host sabe a cual gateway debe enviar los datagramas. En cambio, los proxy ARP prescinden de las tablas de enrutamiento y hacen todo el trabajo a nivel de direcciones Ethernet. Los proxy ARP pueden usarse para todos los destinos, tanto para aquellos que están en nuestra red como para algunas combinaciones de destinos. El caso más sencillo de explicar es el de todas las direcciones; para ello ordenamos al ordenador que simule que todos los ordenadores del mundo están conectados directamente a nuestra Ethernet local. En Unix, esto se hace usando el comando

route add default 128.6.4.2 0

donde, 128.6.4.2 es la dirección IP de nuestro host. Como ya hemos visto, la métrica 0 provoca que todo aquello que se identifique con esta ruta se enviará directamente a la red local Ethernet. Alternativamente, otros sistemas nos permiten conseguir el mismo efecto fijando una máscara de red de ceros, en cuyo caso debemos asegurarnos de que no será alterada por un mensaje ICMP de máscara de subred debido a que un sistema conoce la verdadera máscara de red.

Cuando un datagrama va a ser enviado a un destino dentro de la Ethernet local, el ordenador necesita conocer la dirección Ethernet del destino, y para ello, generalmente, se usa la llamada tabla ARP, que contiene las correspondencias entre las direcciones Internet y las direcciones Ethernet. Veamos un ejemplo típico de tabla ARP (en la mayoría de los sistemas se visualiza usando el comando "arp -a". ):

FOKKER.GROUCHO.EDU (128.6.5.16) at 8:0:20:0:8:22 temporary

CROSBY.GROUCHO.EDU (128.6.5.48) at 2:60:8c:49:50:63 temporary

CAIP.GROUCHO.EDU (128.6.4.16) at 8:0:8b:0:1:6f temporary

DUDE.GROUCHO.EDU (128.6.20.16) at 2:7:1:0:eb:cd temporary

W2ONS.MIT.EDU (128.125.1.1) at 2:7:1:0:eb:cd temporary

OBERON.USC.EDU (128.125.1.1) at 2:7:1:2:18:ee temporary

gatech.edu (128.61.1.1) at 2:7:1:0:eb:cd temporary

DARTAGNAN.GROUCHO.EDU (128.6.5.65) at 8:0:20:0:15:a9 temporary

Como dijimos anteriormente, simplemente es una lista de direcciones IP y su correspondiente dirección Ethernet. El término "temporary" indica que la entrada fue añadida dinámicamente usando ARP, en lugar de ser puesta manualmente.

Si hay una entrada para una dirección determinada en la tabla ARP, los datagramas serán puestos en la Ethernet con su correspondiente dirección Ethernet. Si esto no ocurre, se enviará una "petición ARP", solicitando que el host destino se identifique. La petición es, en efecto, una pregunta: "¿Puede decirme el host con dirección Internet 128.6.4.194 cuál es su dirección Ethernet?". Cuando llega una respuesta, esta se añade a la tabla ARP y los futuros datagramas con ese destino serán enviados directamente.

Este mecanismo fue diseñado inicialmente sólo para hosts que estuvieran directamente conectados a una simple Ethernet. Si necesitamos comunicarnos con un host que se encuentra en otra Ethernet, se supone que la tabla de enrutamiento lo dirigirá a un gateway. Dicho gateway, como es obvio, deberá tener una interface en nuestra Ethernet. El host deberá averiguar la dirección de dicho gateway usando ARP. Este procedimiento es más útil que hacer que el ARP trabaje directamente con un ordenador en una red lejana, puesto que no están en la misma Ethernet, no disponemos de una dirección Ethernet para poder enviar los datagramas y, al enviar "peticiones ARP" por ellas, nadie nos responderá.

Los proxy ARP se basan en la idea de que los conceptos actúen como proxyes de hosts lejanos. Supongamos que tenemos un host en la red 128.6.5, con direcciones (es el ordenador A en diagrama siguiente), que va a enviar un datagrama al host 128.6.5.194 (el ordenador C) que se encuentra en una Ethernet distinta (subred 128.6.4). Hay un gateway que conecta ambas subredes, de direcciones 128.6.5.1 (gateway R)

Ahora supongamos que el ordenador A envía una petición ARP al ordenador C, pero C no es capaz de responder por sí mismo. Al estar en redes distintas, C nunca verá la petición ARP; sin embargo, el gateway actuará en su lugar. En efecto, nuestro ordenador pregunta: "¿Puede decirme el host con dirección de Internet 128.6.4.194 cuál es su dirección Ethernet?", y el gateway contesta: "Yo soy 128.6.4.194 es 2:7:1:0:eb:cd", donde 2:7:1:0:eb:cd es la dirección Ethernet del gateway. Este pequeño truco funciona correctamente y hace pensar a nuestro host que 128.6.4.194 está conectado a la Ethernet local con dirección 2:7:1:0:eb:cd, pero, por supuesto, no es cierto. Cada vez que enviamos un datagrama a 128.6.4.194, nuestro host lo envía a la dirección Ethernet especificada y, puesto que es la dirección del gateway R, llega hasta dicho gateway. Y es entonces cuando se envía a su destino.

Veamos que esto tiene el mismo efecto que tener una entrada en la tabla de enrutamiento diciendo que la ruta de 128.6.4.194 al gateway 128.6.5.1 es:

128.6.4.194 128.6.5.1 UGH pe0

Con la excepción de que, en lugar de tener el enrutamiento hecho a nivel de tabla de enrutamiento, se hace a nivel de tabla ARP.

Generalmente, es mejor usar tablas de enrutamiento, pero hay algunos casos en los que tiene sentido los usar proxyes ARP:

* cuando tenemos un host que no trabaja con subredes;

* cuando tenemos un host que no responde adecuadamente al redireccionamiento;

* cuando no queremos elegir un gateway determinado por defecto;

* cuando el software no es capaz de recuperarse de un enrutamiento fallido.

La técnica fue diseñada originariamente para trabajar con hosts que no soportan subredes. Supongamos que tenemos una red dividida en subredes. Por ejemplo, hemos decidido dividir la red 128.6 en subredes, obteniendo las subredes 128.6.4 y 128.6.5. Supongamos también que tenemos un host que no trabaja con subredes y, por tanto, creerá que 128.6 es tan sólo una red. Esto último significa que será difícil establecer las entradas para la tabla de enrutamiento para la configuración vista. No podemos decirle nada sobre la existencia del gateway, de forma explícita, usando "route add 128.6.4.0 128.6.5.1 1", puesto que, al considerar que toda la 128.6 es una simple red, no entenderá que intentamos enviarlo a una subred. En su lugar, interpretará este comando como un intento de configurar una ruta a un host de dirección 128.6.4.0. La única manera que podría hacerlo funcionar sería establecer rutas explícitas a los host, para cada host individual sobre cada subred. Tampoco podríamos depender del gateway por defecto y redireccionar. Supongamos que establecemos "route add default 128.6.5.1 1", en el que fijamos el gateway 128.6.5.1 por defecto; esto no podría funcionar para enviar datagramas a otras subredes. En el caso de que el host 128.6.5.2 quiera enviar un datagrama al 128.6.4.194, puesto que el destino es parte de 128.6, el ordenador lo considerará en la misma red y no se preocupará por buscarle un gateway adecuado.

Los proxy ARP resuelven el problema haciendo ver el mundo de un modo simplista que espera encontrarse. Puesto que el host piensa que todas las restantes subredes forman parte de su propia red, simplemente usará una petición ARP para comunicarse con ellas, esperando recibir una dirección Ethernet que pueda usarse para establecer comunicaciones directas. Si el gateway ejecuta un proxy ARP, responderá con la dirección Ethernet del gateway. Por tanto, los datagramas serán enviados al gateway y todo funcionará correctamente.

Como se puede observar, no se necesita una configuraciòn específica para usar una proxy ARP con hosts que no trabajan con subredes. Lo que necesitamos es que todos nuestros gateways ARP tengan implementado un proxy ARP. Para poder usarlos, deberemos especificar la configuración de la tabla de enrutamiento. Por defecto, las implementaciones TCP/IP esperarán encontrar un gateway para cualquier destino que esté en otra red y, para hacerlo, deberemos explícitamente instalar una ruta de métrica 0, como por ejemplo "route add default 128.6.5.2 0", o poner la máscara de subred a ceros.

Es obvio que los proxy ARP son adecuados cuando los hosts no son capaces de entender subredes. Generalmente, las implementaciones TCP/IP son capaces de manejar mensajes de redirección ICMP correctamente, y, por tanto, normalmente lo que se hará es configurar la ruta por defecto a algún gateway. Sin embargo, en caso de contar con una implementación que no reconoce los redireccionamientos, o no puede configurarse un gateway por defecto, podemos usar proxy ARP.

A veces se usa proxy ARP por conveniencia. El problema de las tablas de enrutamiento es que hay que configurarlas. La configuración más simple es fijar una ruta por defecto; pero, incluso en este caso, hay que incluir un comando equivalente al de Unix "route add default...". En el caso de que hubiese cambios en las direcciones de los gateways, deberíamos modificar este comando en todos los hosts. Si configuramos una ruta por defecto que depende de proxy ARP (con métrica 0), no deberemos cambiar los ficheros de configuración cuando los gateways cambian. Con los proxy ARP, no hace falta poner ninguna dirección de un gateway. Cualquier gateway puede responder a una petición ARP, no importa cuál sea su dirección.

Para evitarnos tener que configurar los sistemas, algunas implementaciones TCP/IP usan ARP por defecto, cuando no tienen otra ruta. Las implementaciones más flexibles nos permiten usar estrategias mixtas. Así, si tenemos que especificar una ruta para cada red en particular, o una ruta por defecto, se usará esa ruta, pero si no hay rutas para un destino lo tratará como si fuese local y usará una petición ARP. En tanto en cuanto sus gateways soporten proxy ARP, esto permitirá que los hosts alcancen cualquier destino sin necesitar ninguna tabla de enrutamiento.

Finalmente, podríamos elegir usar una proxy ARP porque se recuperan mejor de los fallos. La elección dependerá en gran medida de la implementación.

En aquellas situaciones en las que hay varios gateways en una red, veamos cómo los proxy ARP permiten elegir el mejor. Como hemos mencionado anteriormente, nuestro computador simplemente envía un mensaje preguntando por la dirección Ethernet del destino. Suponemos que los gateways están configurados para responder a estos mensajes. Si hay más de un gateway, será necesaria una coordinación entre ellos. Conceptualmente, los gateways tendrán una visión completa de la topología de la red. Por consiguiente, serán capaces de determinar la mejor ruta desde nuestro host a cualquier destino. Si hay una coordinación entre los gateways, será posible que el mejor gateway pueda responder a la petición ARP. En la práctica no es siempre posible, por ello se diseñan algoritmos para evitar rutas malas. Veamos por ejemplo la siguiente situación:

1 2 3

ÄÄÄÄÄÄÄÄÄÄÄÄ A ÄÄÄÄÄÄÄÄÄÄÄÄ B ÄÄÄÄÄÄÄÄÄÄÄ

donde, 1, 2 y 3 son redes; y A y B gateways conectando 2 con 1 ó con 3. Si un host de la red 2 quiere comunicarse con otro de la red 1 es bastante fácil para el gateway A decidirse a contestar, y el gateway B no lo hará. Veamos cómo: si el gateway B acepta un datagrama para la red 1, tendrá que remitirlo al gateway A para que lo entregue. Esto significaría que debería tomar un datagrama de la red 2 y enviarlo de vuelta a la red 2. Es muy fácil manejar las rutas que se dan en este tipo de redes. Es mucho más difícil de controlar en una situación como la siguiente:

1

ÄÄÄÂÄÄÄÄÄÄÄÄÄÄÂÄÄÄ

A B

³ ³

³ ³ 4

3 ³ C

³ ³

³ ³ 5

D E

ÄÄÄÁÄÄÄÄÄÄÄÄÄÄÁÄÄÄ
2

Supongamos que un ordenador en la red 1 quiere enviar un datagrama a otro de la red 2. La ruta vía A y D es probablemente la mejor, porque sólo hay una red (3) entre ambas. También es posible la ruta vía B, C y E, pero este camino probablemente es algo más lento. Ahora supongamos que el ordenador de la red 1 envía peticiones ARP para alcanzar 2. Seguramente A y B responderán a dicha petición. B no es tan buena como A, pero no hay tanta diferencia como en el caso anterior. B no devolverá el datagrama a 1. Además, no es posible determinar qué camino es mejor sin realizar un costoso análisis global de la red. En la práctica no disponemos de tanta cantidad de tiempo para responder a una petición ARP.

Establecer nuevas rutas tras fallos

En principio, IP es capaz de controlar líneas con fallos y caídas de gateways. Hay varios mecanismos para rectificar las tablas de enrutamiento y las tablas de ARP y mantenerlas actualizadas. Pero, por desgracia, muchas de las implementaciones TCP/IP no implementan todos estos mecanismos, por lo que deberemos estudiar detalladamente la documentación de nuestra implementación y, teniendo en cuenta los fallos más frecuentes, deberemos definir una estrategia para asegurar la seguridad de nuestra red. Las principales elecciones son las siguientes: espiar el protocolo de enrutamiento de los gateways, establecer una ruta por defecto y hacer uso del redireccionamiento y usar proxy ARP. Todos estos métodos tienen sus propias limitaciones dependiendo del tipo de red.

Espiar el protocolo de enrutamiento de los gateways es, en teoría, la solución más directa y simple. Si suponemos que los gateways usan una buena tecnología de enrutamiento, las tablas que ellos envían deberían contener la información necesaria para mantener unas rutas óptimas para todos los destinos. Si algo cambia en la red (una línea o un gateway falla), esta información deberá reflejarse en las tablas y el software de enrutamiento deberá ser capaz de actualizar adecuadamente las tablas de enrutamiento de los hosts. Las desventajas de esta estrategia son meramente prácticas, pero, en algunas situaciones, la robustez de este enfoque puede pesar más que dichas desventajas. Veamos cuáles son estas desventajas:

* Si los gateways usan un protocolo de enrutamiento sofisticado, la configuración puede ser bastante compleja, lo que se convierte en un problema ya que debemos configurar y mantener los ficheros de configuración de cada host.

* Algunos gateways usan protocolos específicos de alguna marca comercial. En este caso, es posible que no encontremos un software adecuado para nuestros hosts.

* Si los hosts carecen de disco, puede que haya serios problemas a la hora de escuchar las emisiones.

Algunos gateways son capaces de traducir su protocolo interno de enrutamiento en otro más simple que puede ser usado por los hosts. Esta podría ser una forma de resolver las dos primeras desventajas. Actualmente no hay una solución definitiva para la tercera.

Los problemas de los métodos de rutas por defecto/redireccionamiento y de los proxy ARP son similares: ambos tienen problemas para trabajar con situaciones donde las entradas a las tablas no se usan durante un largo periodo de tiempo. La única diferencia real entre ellos son las tablas que se ven involucradas. Supongamos que un gateway cae, si alguna de las actuales rutas usan ese gateway no podrá ser usada. En el caso de que estemos usando tablas de enrutamiento, el mecanismo para ajustar las rutas es el redireccionamiento. Esto funciona perfectamente en dos situaciones:

- cuando el gateway por defecto no está en la mejor ruta. El gateway por defecto puede dirigirlo a un gateway mejor;

- cuando una línea distante o un gateway falla. Si esto cambia la mejor ruta, el gateway actual nos dirigirá hacia el gateway que ahora es el mejor.

El caso que no está a salvo de problemas es cuando el gateway a que se le envía datagramas falla en ese momento. Puesto que está fuera de servicio, es imposible que redireccione a otro gateway. En muchos casos, tampoco estamos a salvo si el gateway por defecto falla, justo cuando el enrutamiento empieza a enviar al gateway por defecto.

La casuística de los proxy ARP es similar. Si los gateways se coordinan adecuadamente, en principio el gateway indicado responderá adecuadamente. Si algo en la red falla, el gateway que actualmente se está usando nos reconducirá a un nuevo y mejor gateway. (Normalmente es posible usar redireccionamiento para ignorar las rutas establecidas por el proxy ARP). Otra vez, el caso que no podemos proteger de fallos es cuando el gateway actual falla. No hay equivalencia al fallo de los gateways por defecto, puesto que cualquier gateway puede responder a una petición ARP.

Así que el gran problema es el fallo debido a que el gateway en uso no se puede recuperar, por el hecho de que el principal mecanismo para alterar las rutas es el redireccionamiento, y un gateway en mal funcionamiento no puede redirigir. Teóricamente, este problema podría solucionarse a través de la implementación TCP/IP, usando "timeout". Si un ordenador no recibe respuesta una vez terminado el timeout, debería de cancelar la ruta actual y tratar de encontrar otra nueva. Cuando usamos una ruta por defecto, esto significa que la implementación TCP/IP puede ser capaz de declarar una ruta como fallida en base al timeout. En caso de que se haya redirigido a un gateway distinto del de por defecto, y la ruta se declare fallida, el tráfico se devolverá al gateway por defecto. El gateway por defecto puede entonces empezar a manejar el tráfico, o redirigirlo a un gateway diferente. Para manejar los fallos del gateway por defecto es posible tener más de un gateway por defecto; si uno de ellos se declara fallido, se usará el otro. En conjunto, estos mecanismos nos salvaguardan de cualquier fallo.

Métodos similares pueden usarse en sistemas que dependen de proxy ARP. Si una conexión sobrepasa el timeout, la entrada de la tabla ARP usada se debe borrar. Esto causará una petición ARP, que podrá ser contestada por un gateway que funcione correctamente. El mecanismo más simple para llevar esto a cabo podría ser usar los contadores de timeout para todas las entradas ARP. Puesto que las peticiones ARP no son muy costosas en tiempo, cada entrada cuyo timeout concluya será borrada, incluso si estaba funcionando perfectamente. Así, su próximo datagrama será una nueva petición. Las respuestas, normalmente, son suficientemente rápidas para que el usuario no se de cuenta del retraso introducido.

Sin embargo, algunas implementaciones no usan estas estrategias. En Berkeley 4.2 no hay manera de librarse de ningún tipo de entrada, ni de la tabla de enrutamiento ni de la tabla ARP. Estas implementaciones no invalidan las entradas, éstas fallan. Luego si los problemas de fallos de gateways son más o menos comunes, no habrá otra opción que ejecutar un software que escuche el protocolo de enrutamiento. En Berkeley 4.3, las entradas son eliminadas cuando las conexiones TCP fallan, pero no las ARP. Esto hace que la estrategia de la ruta por defecto sea más atractiva que la de proxys ARP, si usamos Berkeley 4.3. Si, además, incluímos más de una ruta por defecto se posibilitará la recuperación de fallos cuando falle un gateway por defecto. Si una ruta está siendo usada sólo por servicios basados en el protocolo UDP, no habrá una recuperación de fallos si el gateway implicado cae. Mientras que los servicios "tradicionales" TCP/IP hacen uso del protocolo TCP, algunos otros, como el sistema de ficheros de red, no lo hacen. Por tanto, la versión 4.3 no nos garantiza una recuperación de fallos absoluta.

Por último, también podemos hablar de otras estrategias usadas por algunas antiguas implementaciones. Aunque están casi en desuso, vamos a describirlas de forma esquemática. Estas implementaciones detectan un fallo de un gateway haciendo comprobaciones de qué gateways están en uso. Para ello, la mejor forma de hacer estas comprobaciones es hacer una lista de gateways que actualmente se estén usando (para lo que se ayuda de la tabla de enrutamiento) y cada minuto se envía una petición de "echo" a cada gateway de la citada lista; si el gateway no envía una respuesta se declara como fallido, y todas las rutas que hacen uso de él se reconducirán al gateway por defecto. Generalmente, se deberá de proporcionar más de un gateway por defecto, de manera que si el gateway por defecto falla se elige uno de los alternativos. En otros casos no es necesario especificar un gateway por defecto, ya que el software, aleatoriamente, eligirá un gateway que responda. Estas implementaciones son muy flexibles y se recuperan bien de los fallos, pero una gran red con esta implementación malgastará el ancho de banda con datagramas "echo" para verificar qué gateways funcionan correctamente. Esta es la razón por la que esta estrategia está en desuso.