El ancho de banda se mide como un cociente de número de bits transmitidos en un segundo. Esto significa que dado suficiente tiempo, la cantidad de información transmisible en cualquier enlace se acerca al infinito. Desafortunadamente, para un período de tiempo finito, el ancho de banda provisto por una conexión de red cualquiera no es infinito. Siempre puede descargar (o cargar) tanto tráfico como quiera; sólo que debe esperar todo lo que sea necesario. Por supuesto que los usuarios humanos no son tan pacientes como las computadoras, y no están dispuestos a esperar una infinita cantidad de tiempo para que su información atraviese la red. Por esta razón, el ancho de banda debe ser gestionado y priorizado como cualquier otro recurso limitado.

Se puede mejorar significativamente el tiempo de respuesta y maximizar el rendimiento disponible mediante la eliminación del tráfico indeseado y redundante de nuestra red. Esta sección describe varias técnicas comunes para asegurarse de que nuestra red solamente está transportando el tráfico que debe y no otro.

Un servidor web proxy es un servidor en la red local que mantiene copias de lo que se ha leído recientemente, páginas web que son utilizadas a menudo, o partes de esas páginas. Cuando la siguiente persona busque esas páginas, las mismas se recuperan desde el servidor proxy local sin ir hasta Internet. Esto resulta, en la mayoría de los casos en un acceso al web más rápido, al mismo tiempo que se reduce significativamente la utilización del ancho de banda con Internet. Cuando se implementa un servidor proxy, el administrador debe saber que existen algunas páginas que no son almacenables, por ejemplo, páginas que son el resultado de programas del lado del servidor, u otros contenidos generados dinámicamente.

Otra cosa que también se ve afectada es la manera como se descargan las páginas web. Con un enlace a Internet lento, una página normal comienza a cargarse lentamente, primero mostrando algo de texto y luego desplegando los gráficos uno por uno. En una red con un servidor proxy, puede haber un retraso durante el cual parece que nada sucede, y luego la página se carga por completo rápidamente. Esto sucede porque la información es enviada a la computadora tan rápido que para el rearmado de la página se toma una cantidad de tiempo perceptible. El tiempo global que toma este procedimiento puede ser sólo de diez segundos (mientras que sin un servidor proxy, puede tomar 30 segundos cargar la página gradualmente). Pero a menos que esto se explique a algunos usuarios impacientes, estos pueden decir que el servidor proxy está haciendo las cosas más lentamente. Generalmente es tarea del administrador lidiar con la percepción de los usuarios acerca de temas como éste.

Existen varios servidores proxy disponibles. Los que siguen son los paquetes de software utilizados más comúnmente:

• Squid. El software libre Squid es el estándar de facto en las universidades. Es gratuito, confiable, sencillo de utilizar y puede ser mejorado (por ejemplo, añadiendo filtros de contenido y bloqueos de publicidad). Squid produce bitácoras (logs) que pueden ser analizadas utilizando software como Awstats, o Webalizer, los cuales son de fuente libre y producen buenos reportes gráficos. En la mayoría de los casos, es más fácil instalarlo como parte de la distribución en lugar de descargarlo desde http://www.squid-cache.org/ (la mayoría de las distribuciones Linux como Debian, así como otras versiones de Unix como NetBSD y FreeBSD vienen con Squid). Una buena guía de configuración de Squid se puede encontrar en:

http://squid-docs.sourceforge.net/latest/book-full.html .

• Servidor Proxy Microsoft 2.0. No está disponible para instalaciones nuevas porque ha sido reemplazado por el servidor Microsoft ISA y ha dejado de tener soporte. Si bien es utilizado por algunas instituciones es mejor no considerarlo para instalaciones nuevas.

• Servidor Microsoft ISA. ISA es un muy buen programa de servidor proxy, pero demasiado caro para lo que hace. Sin embargo, con descuentos académicos puede ser accesible para algunas instituciones. Produce sus propios reportes gráficos, pero sus archivos de bitácora (log) también pueden ser analizados con el popular software Sawmill (http://www.sawmill.net/). Los administradores de un sitio con un Servidor MS ISA deben dedicar tiempo suficiente para obtener la configuración adecuada; por otra parte, el Servidor MS ISA Server puede utilizar gran cantidad de ancho de banda. Por ejemplo, una instalación por omisión puede consumir fácilmente más ancho de banda que lo que el sitio ha utilizado anteriormente, porque las páginas comunes con fechas de expiración cortas (tales como los sitios de noticias) se actualizan continuamente. Por lo tanto, es importante que la captura preliminar (prefetching) se configure correctamente, para que sea realizada durante la noche. El servidor ISA también puede ser asociado a productos de filtrado de contenidos tales como WebSense. Para más información vea el sitio: http://www.microsoft.com/isaserver/ y http://www.isaserver.org/

Si bien eludir la censura de Internet y las políticas de acceso restrictivo a la información son un laudable esfuerzo político, los servidores proxy y los firewalls son herramientas necesarias en áreas con anchos de banda extremadamente limitados. Sin ellos la estabilidad y la usabilidad de la red se ven amenazadas por los propios usuarios legítimos de la red. Las técnicas para eludir un servidor proxy pueden ser encontradas en: http://www.antiproxy.com/. Este sitio es útil para que los administradores vean cómo sus redes pueden enfrentarse a estas técnicas. Para reforzar el uso del almacenamiento temporal proxy (caching proxy), puede simplemente considerarse instaurar una política de acceso a la red y confiar en sus usuarios. En el diseño que sigue, el administrador debe confiar en que los usuarios no van a eludir el servidor proxy.

En este caso el administrador generalmente utiliza una de las siguientes técnicas:

• No divulgar la dirección de la pasarela por omisión (default gateway) a través de DCHP. Esto puede funcionar por un tiempo, pero algunos usuarios que quieren eludir el proxy pueden encontrar o buscar la dirección de la pasarela por omisión. Una vez que esto pasa, se tiende a difundir cómo se elude el proxy.

• Utilizar políticas de grupo o de dominio. Esto es muy útil para configurar el servidor proxy adecuado para Internet Explorer en todas las computadoras del dominio, pero no es muy útil para evitar que el proxy sea eludido, porque se basa en el registro de un usuario en el dominio NT. Un usuario con una computadora con Windows 95/98/ME puede cancelar su registro y luego eludir el proxy, y alguien que conoce la contraseña de un usuario local en su computadora con Windows NT/2000/XP puede registrarse localmente y hacer lo mismo.

• Rogar y luchar con los usuarios. Ésta nunca es una situación óptima para un administrador de red. La única forma de asegurarse que los proxy no van a ser eludidos es mediante la utilización del diseño de red adecuado, por medio de una de las tres técnicas descritas a continuación.

Una de las maneras más confiable para asegurarse que las PC no van a eludir el proxy puede ser implementada utilizando un cortafuego.

El cortafuego puede configurarse para que solamente pueda pasar el servidor proxy, por ejemplo, para hacer solicitudes de HTTP a Internet. Todas las demás PC están bloqueadas, como se muestra en el siguiente diagrama.

Confiar en un cortafuego, como en el diagrama anterior, puede o no ser suficiente, dependiendo de cómo esté configurado. Si sólo bloquea el acceso desde la LAN del campus al puerto 80 en los servidores web, va a haber formas, para los usuarios inteligentes, de encontrar caminos que lo rodeen.

Aún más, van a ser capaces de utilizar protocolos sedientos de ancho de banda como Kazaa.

Posiblemente, el método más confiable es el de instalar dos tarjetas de red en el servidor proxy y conectar la red del campus a Internet como se muestra en la siguiente figura. De esta forma, el diseño de red hace físicamente imposible alcanzar la Internet sin pasar a través del servidor proxy.

El servidor proxy en este diagrama no debe tener habilitado IP forwarding, a menos que los administradores conozcan exactamente qué es lo que quieren dejar pasar.

Una gran ventaja de este diseño es que puede utilizarse una técnica conocida como transparent proxying. Utilizar proxy transparente significa que las solicitudes web de los usuarios son reenviadas automáticamente al servidor proxy, sin ninguna necesidad de configurar manualmente los navegadores web para que lo utilicen. Esto fuerza efectivamente a que todo el tráfico web sea almacenado localmente, lo que elimina muchas posibilidades de error de los usuarios, y va a trabajar incluso con dispositivos que no soportan el uso de un proxy manual. Para más detalles sobre cómo configurar un proxy transparente con Squid, diríjase a:

• http://www.squid-cache.org/Doc/FAQ/FAQ-17.html
• http://en.tldp.org/HOWTO/mini/TransparentProxy-2.html

Una forma de prevenir la circunvalación del proxy utilizando equipamiento Cisco es con una política de enrutamiento. El enrutador Cisco dirige transparentemente las solicitudes web al servidor proxy. Esta técnica es utilizada en la Universidad Makerere. La ventaja de este método es que, si el servidor proxy está caído, las políticas de enrutamiento pueden ser removidas temporalmente permitiéndoles a los clientes conectarse directamente a Internet.

Con el permiso del dueño o del administrador del sitio web, el sitio completo puede ser copiado durante la noche al servidor local, siempre que el mismo no sea demasiado grande. Esto es algo que se debe tener en cuenta para sitios web importantes, que son de interés particular para la organización, o que son muy populares entre los usuarios de la web. Si bien esto puede ser útil, tiene algunas fallas potenciales. Por ejemplo, si el sitio que es duplicado contiene programas CGI u otros contenidos dinámicos que requieren de interacción con el usuario, va a haber problemas. Un ejemplo es el sitio web que requiere que la gente se registre en línea para una conferencia. Si alguien se registra en línea en un servidor duplicado (y el programa de duplicado funciona bien), los organizadores del sitio no van a tener la información de que la persona se registró.

Debido a que un sitio duplicado puede infringir los derechos de copyright, esta técnica debe ser utilizada solamente con el permiso del sitio en cuestión. Si el sitio corre rsync, puede ser duplicado utilizando rsync. Ésta es la forma más rápida y eficiente de mantener los contenidos del sitio sincronizados. Si el servidor web remoto no está corriendo rsync, se recomienda utilizar el software llamado wget. Éste es parte de la mayoría de las versiones de Unix/Linux. Una versión de Windows puede encontrase en http://xoomer.virgilio.it/hherold/, o en el paquete de herramientas gratuito de Cygwin Unix (http://www.cygwin.com/).

Se puede utilizar un script que corra cada noche en un servidor web local y haga lo siguiente:

• Cambiar el directorio raíz del servidor web: por ejemplo, /var/www/ en Unix, o C:\Inetpub\wwwroot en Windows.
• Duplicar el sitio web utilizando el siguiente comando:

wget --cache=off -m http://www.python.org

El sitio duplicado va a estar en el directorio www.python.org. El servidor web debe ser configurado para servir los contenidos de ese directorio como un host virtual basado en nombre. Ponga en marcha el servidor local DNS para falsificar una entrada para este sitio. Para que esto funcione, las PC clientes deben ser configuradas para usar el/los servidor(es) DNS local(es) como el DNS primario. (Esto es siempre aconsejable, porque el almacenamiento intermedio (caching) del servidor DNS acelera los tiempos de respuesta web).

En lugar de instalar un sitio web duplicado como se describió en la sección anterior, un mejor enfoque es el de poblar el proxy cache utilizando un proceso automatizado. Este método ha sido descrito por J. J. Eksteen y J. P. L. Cloete del CSIR en Pretoria, Sud África, en un artículo titulado Mejorar el Acceso a la Red de Redes en Mozambique a Través del Uso de Servidores Proxy Reflejados y Almacenados (Enhancing International World Wide Web Access in Mozambique Through the Use of Mirroring and Caching Proxies). En este artículo (disponible en línea en http://www.isoc.org/inet97/ans97/cloet.htm) los autores describen cómo trabaja el proceso:

"Un proceso automatizado recupera la página inicial del sitio y especifica el número de páginas extra (siguiendo recursivamente los enlaces HTML en las páginas recuperadas) a través del uso de un proxy. En lugar de copiar las páginas recuperadas en el disco local, el proceso de duplicación descarta las páginas recuperadas. Esto se hace para conservar los recursos del sistema así como para evitar posibles problemas de copyright. Mediante el uso del proxy como intermediario, se garantiza que las páginas recuperadas están en el cache del proxy como si un cliente hubiera accedido a esa página. Cuando un cliente accede a la página recuperada, le es brindada desde el cache y no desde el enlace internacional congestionado. Este proceso puede ser corrido en momentos de poco uso de la red, para maximizar la utilización del ancho de banda y no competir con otras actividades de acceso."

El siguiente comando (programado para correr en la noche, o una vez al día o a la semana) es todo lo que se necesita (debe repetirse para cada sitio que necesita ser pre-poblado).

wget --proxy-on --cache=off --delete after -m http://www.python.org

Explicación:

• -m: Duplica el sitio completo. wget comienza en www.python.org y sigue todos los hiperenlaces, es decir que descarga todas las subpáginas.

• –proxy-on: Se asegura que wget haga uso del servidor proxy. Esto puede no necesitarse en aplicaciones donde se utiliza un servidor proxy transparente.

• –cache=off: Se asegura de que el contenido fresco es recuperado desde Internet, y no desde el servidor proxy local.

• –delete after: Borra la copia duplicada. El contenido duplicado permanece en el cache del proxy si hay suficiente espacio en el disco, y los parámetros del servidor proxy son aplicados correctamente.

Además, wget tiene muchas otras opciones; por ejemplo, proveer contraseñas para los sitios web que las requieren. Cuando utilizamos esta herramienta, Squid debe ser configurado con suficiente espacio en el disco para que contenga todos los sitios pre-poblados y más (para un uso normal de Squid que involucre otras páginas además de las pre-pobladas). Afortunadamente, el espacio de disco es cada vez más barato y su tamaño mucho más grande que nunca. Sin embargo, esta técnica puede ser utilizada solo con unos pocos sitios seleccionados. Estos sitios no deben ser muy grandes para que los procesos terminen antes de que las horas del día de trabajo comiencen, y se debe estar vigilando el espacio de disco disponible.

Cuando una organización tiene más de un servidor proxy, los mismos pueden compartir información cache entre ellos. Por ejemplo, si una página web está en el cache del servidor A, pero no en el cache del servidor B, un usuario conectado a través del servidor B puede acceder a la página web en el servidor A a través del servidor B. El Protocolo de Inter-Cache (Inter-Cache Protocol (ICP)) y el (Cache Array Routing Protocol (CARP)) pueden compartir información del cache. De éstos, el protocolo CARP es considerado el mejor. Squid soporta ambos protocolos, y el Servidor MS ISA soporta CARP. Para más información diríjase a: http://squid-docs.sourceforge.net/latest/html/c2075.html. El compartir información cache reduce el uso de ancho de banda en organizaciones donde se utiliza más de un proxy.

En la red de un campus universitario, debería haber más de un servidor proxy, por razones de prestaciones y de redundancia. Con los discos actuales más baratos y más grandes, se pueden construir servidores proxy más poderosos, con 50 GB o más de espacio de disco asignado al cache. Las prestaciones del disco son importantes, por lo que los discos SCSI más rápidos se van a desempeñar mejor (aunque un cache basado en un IDE es mejor que nada). RAID (Redundant Array of Independent Disks) o el uso de espejos (mirror) no son recomendados.

Se aconseja dedicar un disco exclusivamente para el cache. Por ejemplo, un disco puede ser para el cache, y el segundo para el sistema operativo y la bitácora del cache. Squid está diseñado para utilizar toda la memoria RAM que puede conseguir porque es mucho más rápido cuando los datos son recuperados desde la memoria RAM que cuando vienen desde el disco duro. Para una red en un campus, la memoria RAM debe ser de 1GB o más: Además de la memoria requerida para el sistema operativo y otras aplicaciones, Squid requiere 10 MB de RAM por cada 1 GB de disco cache. Por lo tanto, si tenemos un espacio de disco de 50 GB asignados al cache, Squid va a requerir 500 MB de memoria extra.

La máquina también va a requerir 128 MB para Linux y 128 MB para Xwindows. Otros 256 MB deben agregarse para otras aplicaciones, y para que todo pueda funcionar fácilmente. Nada mejora más el rendimiento de una computadora como la instalación de una gran cantidad de memoria, porque esto reduce la necesidad de utilizar el disco duro. La memoria es miles de veces más rápida que el disco duro. Los sistemas operativos modernos frecuentemente mantienen los datos accedidos en la memoria siempre que haya suficiente RAM disponible. Pero utilizan el archivo de la página del disco duro como un área de memoria extra cuando no tienen suficiente memoria RAM.

Los servidores DNS con sólo la función de cache no son autoridades de ningún dominio, solo almacenan los resultados de solicitudes pedidas por los clientes, tal como un servidor proxy que almacena páginas web populares por cierto tiempo. Las direcciones DNS son almacenadas hasta que su tiempo de vida (TTL por su sigla en inglés) expira. Esto va a reducir la cantidad de tráfico DNS en su conexión a Internet, porque el cache DNS puede ser capaz de satisfacer muchas de las preguntas localmente. Por supuesto que las computadoras de los clientes deben ser configuradas para utilizar el nombre del servidor solo de cache como su servidor DNS. Cuando todos los clientes utilicen ese servidor DNS como su servidor principal, se poblará rápidamente el cache de direcciones IP a nombres, por lo tanto los nombres solicitados previamente pueden ser resueltos rápidamente. Los servidores DNS que son autoridades para un dominio también actúan como cache de la conversión nombres-direcciones de hosts de ese dominio.

Bind es el programa estándar de facto utilizado para servicios de nombre en Internet. Cuando Bind está instalado y corriendo, va a actuar como un servidor cache (no se necesita más configuración). Bind puede ser instalado desde un paquete como el Debian o un RPM. Instalarlo desde un paquete en general es el mejor método. En Debian, escriba

apt-get install bind9

Además de implementar cache, Bind también puede alojar zonas de autoridad, actuar como esclavo de zonas de autoridad, implementar split horizon (horizonte dividido), y todo lo demás que es posible con DNS.

Un servidor DNS de cache alternativo es dnsmasq. Está disponible para BSD y la mayoría de las distribuciones Linux, o desde http://freshmeat.net/projects/dnsmasq/. La gran ventaja de dnsmasq es la flexibilidad: actúa como un proxy DNS de cache y como una fuente autorizada para hosts y dominios, sin una configuración complicada de archivos de zona. Se pueden hacer actualizaciones a la zona de datos sin ni siquiera reiniciar el servicio. También actúa como servidor DHCP, e integra el servicio DNS con el de DHCP. Es liviano, estable y extremadamente flexible. Bind es, prácticamente, la mejor elección para redes muy grandes (mayores que un par de cientos de nodos), pero la simplicidad y flexibilidad de dnsmasq lo hacen atractivo para redes pequeñas y medianas.

Para instalar el servicio DNS en Windows NT4: seleccione Panel de Control ⇒ Red ⇒ Servicios ⇒ Agregar ⇒ Servidor DNS Microsoft. Inserte el CD de Windows NT4 CD cuando se le indique. Cómo configurar un servidor solo de memoria intermedia (cache) en NT se describe en el artículo Knowledge Base 167234. Una cita del artículo:

"Simplemente instale DNS y haga correr el Sistema Administrador de Nombres de Dominio (Domain Name System Manager). Dé un clic en DNS en el menú, seleccione Nuevo Servidor, y escriba la dirección IP de su computadora donde ha instalado DNS. Usted ahora tiene un servidor DNS solo de cache."

Para instalar el servicio DNS: Inicio ⇒ Configuración ⇒ Panel de Control ⇒ Agregar o Quitar Programas. En Agregar o Quitar Componentes de Windows, seleccione Componentes ⇒ Servicios de Red ⇒ Detalles ⇒ Sistema de Nombres de Dominios (DNS). Luego inicie el DNS MMC (Inicio ⇒ Programas ⇒ Herramientas Administrativas ⇒ DNS) Desde el menú de Acción seleccione "Conectarse a la Computadora…" En la ventana de Selección de Computadora Destino, habilite "La siguiente computadora:" e ingrese el nombre del servidor DNS que usted quiere almacenar. Si hay un . [punto] en el administrador DNS (aparece por omisión), significa que el servidor DNS piensa que es el servidor DNS raíz de Internet. Ciertamente no lo es. Para que todo funcione borre el . [punto].

El objetivo de un DNS dividido (también conocido como horizonte dividido) es el de presentar una visión diferente de su dominio para el mundo interno y el externo. Hay más de una forma de dividir DNS; pero por razones de seguridad se recomienda que tenga dos servidores de contenidos DNS separados; el interno y el externo (cada uno con bases de datos diferentes).

Dividir el DNS permite a los clientes de la red del campus resolver las direcciones IP para el dominio del campus a direcciones locales RFC1918, mientras que el resto de Internet resuelve los mismos nombres a direcciones IP diferentes. Esto se logra teniendo dos zonas en dos servidores DNS diferentes para el mismo dominio.

Una de las zonas es utilizada para los clientes internos de la red y la otra para los usuarios en Internet. Por ejemplo, en la red siguiente el usuario dentro del campus de Makerere verá http://www.makerere.ac.ug/ resuelto como 172.16.16.21, mientras que un usuario en otro dominio de Internet lo verá resuelto como 195.171.16.13.

El servidor DNS en el campus, como se ve en el diagrama anterior, tiene un archivo de zona para makerere.ac.ug y está configurado como la autoridad para ese dominio. Además, funciona como el servidor DNS cache para el campus de Makerere, y todas las computadoras en el campus están configuradas para utilizarlo como su servidor DNS.

Los registros DNS para el servidor DNS en el campus van a verse así:

makerere.ac.ug
www   CNAME  webserver.makerere.ac.ug
ftp   CNAME  ftpserver.makerere.ac.ug
mail  CNAME  exchange.makerere.ac.ug
mailserver   A      172.16.16.21
webserver    A      172.16.16.21
ftpserver    A      172.16.16.21

Pero hay otro servidor DNS en Internet que es en realidad la autoridad para el dominio makerere.ac.ug. Los registros DNS para esta zona externa van a verse así:

makerere.ac.ug
www    A  195.171.16.13
ftp    A  195.171.16.13
mail   A  16.132.33.21
MX mail.makerere.ac.ug

• Anterior: Planificar enlaces.
• Siguiente: Optimización del enlace a Internet.
• Volver al índice.