Estación de Tránsito

Instalación y configuración de un Proxy/Web Caché

En una red local que permita el acceso a Internet, la mayoría de los equipos se conecta a los mismos sitios en forma reiterada. El Sistema Operativo y algunas aplicaciones (como los antivirus) bajan actualizaciones cotidianamente. Es decir, se descargan múltiples veces los mismos archivos, y cuantos más equipos se tengan en la red, peor es la redundancia en las descargas. Ni hablar del tiempo desperdiciado en bajar de Internet archivos que ya fueron descargados por otro equipo de la red. Si, además, contamos con una conexión a Internet con escaso ancho de banda, o alta latencia, el problema se agrava todavía más. La solución es incorporar a la red un Web Proxy que centralice la navegación en un servidor y que, también, permita cachear los archivos, para evitar su redescarga, de modo similar al caché de un navegador web. En esta ocasión, explicaremos cómo trabajar con Squid, un Proxy/Web Caché de código abierto (Open Source) extremadamente configurable y poderoso.

DESCARGANDO SQUID
Si Linux es nuestra plataforma, para descargar e instalar Squid lo haremos a través del administrador de paquetes de nuestra distribución (en Debian o Ubuntu es posible realizarlo desde la línea de comandos con sudo apt-get install squid). En el desafortunado caso de que no cuenten con uno (¿qué esperan para actualizarse a una distribución moderna?) deberán recurrir al sitio oficial de Squid, del que se podrán bajar varias versiones de binarios, o los fuentes si prefieren compilarlo ustedes mismos. Si son usuarios de Windows, tendrán que descargar el port de Windows que mantiene la empresa italiana Acme Consulting. Hay distintas versiones, pero aconsejamos trabajar con la “Standard”, cuya última versión se baja de aquí. Una vez descargado, recomendamos extraerlo en la raíz de la unidad C para que quede instalado en C:\squid, que es la ruta usada por defecto en el archivo de configuración.

A EDITAR LA CONFIGURACIÓN
Nos dirigimos a nuestro editor de textos preferido y modificamos el archivo de configuración, que en el caso de Linux se encuentra en /etc/squid/squid.conf, y en el de Windows en C:\squid\etc\squid.conf.default (en este último, conviene hacer “guardar como” squid.conf y dejamos el squid.conf.default como backup; lo mismo hay que realizar con los archivos mime.conf.default y cachemgr.conf.default). Al trabajar con este archivo es preferible tener en cuenta algunas cosas. Todas las líneas comenzadas con el signo # son “comentarios” y, por ende, son ignoradas por Squid. Es buena idea que hagamos un uso extensivo de los comentarios al llevar a cabo modificaciones en la configuración, ya que, en variadas ocasiones, deberemos retocarla mucho tiempo después y, si no hemos formulado comentarios informativos adecuados, será menos sencillo encontrar las directivas correspondientes. También es necesario considerar que es relevante el orden en que declaramos las directivas en este archivo, sobre todo a la hora de trabajar con las ACL, o listas de control de acceso, que son las que permitirán o denegarán el acceso a los clientes a los sitios web que hayamos configurado. Por cierto, esto ya nos da una idea de que, además, es posible utilizar Squid para restringir la navegación sólo a un grupo de sitios determinados, en lugar de darle “salida libre” a los clientes para que naveguen adonde deseen. En la mayoría de las versiones de Squid, prácticamente todas las directivas vienen comentadas con “#”, tomando, de esta manera, cada una de ellas su valor por defecto. Si queremos modificarlo, debemos quitar el # o, mejor aún, copiar la línea debajo, eliminando el comentario, para tener a mano los default como referencia. Dicho sea de paso, cada una de las directivas en el archivo de configuración viene acompañada por un extenso comentario que explica cada uno de sus valores posibles y las distintas opciones correspondientes a esa directiva, por lo que el archivo de configuración es muy largo (¡4400 líneas!) y cuesta encontrar las líneas que indicamos controlar o modificar. Por lo tanto, es aconsejable que hagan uso de la función de búsqueda del editor para localizar la ubicación de cada directiva a medida que la vamos mencionando.

La primera línea a la que tenemos que prestar atención es a la que contiene la directiva http_port 3128. Esto indica que Squid recibe las peticiones de los clientes en el puerto 3128, pero lo podemos cambiar por el puerto que deseemos, o agregar varias directivas http_port para que escuche en múltiples puertos simultáneamente.

Luego, buscamos la directiva cache_mem. Esta orden indica la cantidad de memoria RAM que se usará para guardar archivos cacheados, cuyo valor, por lo común, es de 8 MB. Según la cantidad de memoria RAM de la que dispongamos, es preferible dejarlo entre 8 y 32 MB (vale la pena mencionar que, en todas las directivas en las que se especifica tamaño de archivos, es posible hacerlo en KB, MB o GB). Algunas líneas más abajo, encontraremos maximum_object_size_in_memory, que refiere al tamaño máximo de los archivos a ser cacheados en memoria (los que superen dicho tamaño no serán cacheados en memoria). Su valor por defecto es de 8 KB, aunque, en general, no conviene mantenerlo. También debemos tener en cuenta maximum_object_size, que trabaja de la misma forma, pero respecto de los archivos cacheado en disco. En este caso, si nuestra prioridad es ahorrar ancho de banda, es deseable poner valores altos (32 o 64 MB), y si, por lo contrario, queremos acelerar la velocidad de descarga de las páginas, dejamos un valor bajo como el que viene por defecto (4 MB).

A continuación, buscamos la directiva cache_dir. Esta es una de las líneas más importantes del archivo, ya que aquí se define el sistema de archivos con el que trabajará el caché de disco, y la estructura y el tamaño del mismo. Utilizando el sistema de archivos nativo de Squid, llamado ufs, el formato de la directiva es cache_dir ufs NombreDirectorio TamañoMáximo L1 L2, en donde NombreDirectorio es el directorio en el que reside el caché, TamañoMáximo el tamaño límite del caché (en este caso, expresado exclusivamente en MB) y L1 y L2 la cantidad máxima de subdirectorios de primer y segundo nivel, respectivamente, a crear bajo NombreDirectorio. Por defecto los valores son cache_dir ufs c:/squid/var/cache 100 16 256; por consiguiente, el tamaño límite del caché de disco es de 100 MB. Es imprescindible modificar este valor y poner el más alto que nos sea posible, considerando el espacio en disco que deseemos destinar al uso del caché. Un mínimo de 1000 MB es aconsejable, pudiendo llegar a especificar 5000 o 10000 MB si nos sobra el espacio en disco, o de allí para arriba si estamos preparando un equipo dedicado a la función de Proxy/Caché.

En la versión de Windows, necesitaremos configurar la directiva visible_hostname, que sirve para personalizar el nombre de host que aparece en los mensajes de error, con el nombre que deseemos, pero esta directiva debe tener un valor, de lo contrario Squid se negará a ejecutarse.

CONTROL DE ACCESO
Squid ofrece una enorme flexibilidad a la hora de administrar el acceso a Internet. Sus listas de control de acceso (ACL) posibilitan especificar redes, subredes y equipos a los que permitiremos o negaremos el acceso. En realidad, esta operación tiene lugar en dos pasos: en primer lugar, se define un segmento de la red al que se le quiere dar acceso, y se le otorga un nombre o “alias”. Luego, se permite o se impide el acceso a los distintos alias. Veamos un ejemplo: localicen en el archivo de configuración la línea acl localhost src 127.0.0.1/255.255.255.255. En dicha línea, se está declarando una lista de alias “localhost” que corresponde a la IP 127.0.0.1 (es decir, la del loopback, el equipo local en donde corre Squid). Por defecto, muchas versiones de Squid impiden todo acceso al proxy hasta que el administrador no configure deliberadamente las ACL. Así que comencemos por permitir el acceso desde el equipo que hostea Squid. Si no existe en algún lugar de la sección “ACCESS CONTROLS” una línea que diga http_access allow localhost debemos agregarla, pues, de lo contrario, ni siquiera tendremos acceso desde el anfitrión. Luego, agreguemos nuestra red local para habilitar el acceso al resto de las estaciones de trabajo. Para ello, creamos una línea que exprese acl miredlocal src 192.168.10.0/24 justo debajo de la línea que da acceso al localhost. Noten que todavía no le dimos acceso a la red; simplemente, estamos declarando que contamos con una red de nombre “miredlocal”, cuyo segmento de red es 192.168.10.x y su máscara de red es 24 (255.255.255.0). Para posibilitar efectivamente el acceso, agregamos debajo: http_access allow miredlocal. Es factible permitir el acceso sólo a determinados equipos de la red, o, por el contrario, negar el acceso únicamente a algunas máquinas; también se puede especificar el acceso en base a distintos días y horarios. Estos filtros más avanzados se configuran uno a uno, a través de rangos o de expresiones regulares. Está todo muy bien explicado en el mismo archivo de configuración, aunque, lamentablemente, el texto se encuentra en inglés, por lo que, tal vez, necesiten recurrir un par de veces a un buen diccionario (recomiendo especialmente WordReference) para comprender totalmente las diferentes opciones de administración que posibilitan las ACL.
Concluyamos la configuración del control de acceso notando que, al final de esta sección, hay una línea que dice http_access deny all. Es muy importante tenerla en cuenta, ya que significa que sólo serán capaces de acceder al proxy aquellos equipos o subredes que hayamos habilitado explícitamente.

PASOS FINALES
Con estas modificaciones en el archivo de configuración poseemos lo suficiente como para tener un Proxy/Web Caché totalmente funcional. Ni hace falta mencionar que las opciones y posibilidades de Squid son realmente muchas, y quedará en cada uno de ustedes seguir indagando tanto en el explicativo presente en el mismo archivo de configuración, como en la documentación que se halla en el sitio web oficial, para lograr que Squid trabaje de acuerdo a sus necesidades. Pero, primero que nada, lo mejor es probar que todo lo hecho hasta el momento funciona correctamente. Por lo general, los usuarios de Linux sólo deben reiniciar el servicio para que Squid se desempeñe (en Debian o Ubuntu, lo hacemos desde el shell con sudo /etc/init.d/squid restart). En cambio, en Windows, primero debemos crear el sistema de archivos del caché desde la línea de comandos, con la orden c:\squid\sbin\squid.exe -z que, además, verificará la correcta sintaxis en el archivo de configuración y nos avisará si existe algún error. Pero, si todo va bien, sólo resta instalar Squid como servicio de Windows, ejecutando c:\squid\sbin\squid.exe -i. Esto instalará Squid como servicio automático, pero para levantar el servicio, tendremos que hacerlo con net start squid (o si lo prefieren, por supuesto, desde el panel de control/herramientas administrativas). El servicio se instala como Automático, es decir que arrancará cuando se inicie Windows, pero puede ser configurado como Manual si es necesario.

PROBANDO EL PROXY
Es el momento de configurar la conexión al proxy en el navegador web. En Firefox para Linux, vamos a Editar/Preferencias. En la versión de Windows, nos dirigimos a Herramientas/Opciones (¿alguien me puede explicar a qué se debe esta diferencia en ambas versiones de Firefox?). Luego, hacemos clic en “Avanzadas”, en la solapa “Red” pulsamos el botón “Opciones” y elegimos “Configuración manual de proxy”. A continuación, en “Proxy HTTP” ingresamos la IP del equipo anfitrión de Squid (127.0.0.1 si estamos realizando la prueba desde el mismo anfitrión) y el puerto 3128 (o el que hayamos puesto en el archivo de configuración). Como siguiente paso, tildamos “usar el mismo proxy para todos los protocolos” y salimos aceptando. Para concluir, apuntemos el navegador hacia cualquier sitio web (apuesto a que el 90% de ustedes teclearán “www.google.com” y, si funciona, Squid ya está acelerando nuestra navegación y ahorrándonos valioso ancho de banda. Si trabaja bien desde el mismo anfitrión, pero no desde otros equipos de nuestra red local, pese a que configuramos correctamente los accesos en Squid, muy probablemente se deba al Firewall del anfitrión bloqueando las conexiones. En Windows, tendrán que dirigirse a panel de control/Firewall de Windows y crear una excepción que habilite el puerto de Squid.

Y EL RESTO DEPENDE DE USTEDES
Pocas veces es tan cierto como en este caso que apenas hemos raspado la superficie de lo que este sorprendente software es capaz de hacer. Además de ser un completo proxy-cache, puede usarse para habilitar o impedir el acceso a determinados websites, para restringir el tipo de archivos que se descargan y para configurar como bloqueador de popups. También está pensado para trabajar en tándem con el Servidor Web Apache con el objetivo de acelerar la entrega de páginas en un sitio web y para realizar control y auditoría sobre el uso de la navegación que hacen los usuarios de nuestra red. Y, seguramente, existen muchas posibilidades que no hemos mencionado. Queda por cuenta de ustedes, como siempre, seguir investigando. ¡Hasta la próxima!

Si no le damos permisos de acceso a “localhost”, el proxy no podrá ser accedido desde la máquina donde se ejecuta. (Click para agrandar)

Aquí editamos el archivo de configuración para agregar una lista de control de acceso (acl) para permitir operar con Squid desde nuestra red local. (Click para agrandar)

En la web oficial de Squid tenemos varias herramientas para realizar un análisis de los logs, lo que permite tener una idea más acabada de lo que sucede con el tráfico web de la LAN. (Click para agrandar)

Aclaración: Este post fue publicado originalmente en la revista POWERUSR #46. TODOS LOS DERECHOS RESERVADOS. PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL SIN EL CONSENTIMIENTO EXPRESO DEL AUTOR. SE PERMITE EL ENLACE O LINKEO A ESTE POST SIN NINGÚN TIPO DE RESTRICCIONES.

En la entrega anterior, llegamos hasta fines de la década de 1940, cuando apareció el transistor. Esta vez, nos enfocaremos en la creación de los circuitos integrados (microchips), que posibilitaron la miniaturización definitiva de diversos dispositivos. Desde las radios hasta los equipos informáticos, la industria se benefició con este invento que aumentó la vida útil, simplificó los diseños y redujo el consumo de energía de todos los equipos electrónicos. Si bien este concepto tiene su origen en tres patentes de 1928 del físico alemán Julius Edgard Lilienfeld, no fue sino hasta 1990 que se encontraron pruebas de que Lilienfeld habría creado un transistor que funcionaba. Años después, en 1947, los estudios de Lilienfeld fueron retomados por científicos de Bell Labs, el área de Investigación y Desarrollo de Bell, la gigantesca empresa de telefonía norteamericana. William Shockley, John Bardeen y Walter Brattain buscaban fabricar diodos de calidad superior para su aplicación en radares. En diciembre de ese año, lograron crear el primer transistor de contacto completamente funcional, pero omitieron mencionar los estudios previos de Lilienfeld en toda la documentación que elaboraron. Debido a esta omisión, hoy en día son considerados como los inventores del transistor. Pero lo que actualmente conocemos como “transistor” hizo su aparición tres años más tarde, en 1950, cuando Shockley creó el primer transistor bipolar, un componente similar al anterior, aunque con una estructura interna distinta.

DÍAS DE RADIO
En sus inicios, el transistor no encontró una acogida favorable. En un principio, eran inestables, poco duraderos y de baja potencia. Pese al considerable avance que representaban sobre las válvulas, eran vistos por la comunidad de físicos y expertos en electrónica como una curiosidad o, a lo sumo, como una tecnología cuya aplicación todavía estaba inmadura. Sin embargo, los procesos de fabricación mejoraron velozmente, tornando al transistor en un componente barato y fiable. Pero el invento aún así no se difundía. Bell tuvo una idea muy inteligente: servirse de la radio, muy popular en aquellos tiempos. Licenció la fabricación de transistores a distintas empresas, entre ellas Regency, Texas Instruments y Sony, con la condición de que vendieran radios portátiles, cuyo tamaño reducido se hacía posible gracias a los transistores. El cofundador de Sony, Masaru Ibuka, estaba de visita en los Bell Labs cuando se pusieron en venta las licencias de fabricación. Ibuka vió el potencial de la nueva tecnología y, rápidamente, convenció al gobierno japonés de prestarle cincuenta mil dólares para adquirir una licencia. Y vaya si tuvo visión: Texas y Regency produjeron radios transistorizadas, pero únicamente primitivos prototipos, que nunca llegaron a comercializarse. En cambio, Sony, en 1955, inundó el mercado con las primeras pocket radios, las radios de bolsillo a transistores. El primer modelo de pocket radio era demasiado grande como para caber en los bolsillos de los trajes de la época. Entonces, Sony mandó a hacer para sus vendedores sacos con bolsillos de mayor tamaño, de tal modo que les fuera posible demostrar que una radio (hasta ese momento, un aparato inmenso en torno al cual se reunía toda la familia) podía caber en un bolsillo. El gran éxito de las pocket radio contribuyó decisivamente para instalar al transistor como reemplazante de las válvulas.

EL CIRCUITO INTEGRADO: EL BOOM DE LA MINIATURIZACIÓN
A menudo descubrimientos clave han ocurrido de manera casi simultánea en distintos lugares del mundo, y lo mismo sucedió con la creación del circuito integrado. En 1952, el científico británico Geoffrey Dummer, especialista en radares, publicó un escrito en donde describía el concepto de circuito integrado. Sin embargo, nunca alcanzó a desarrollar un prototipo. En 1959, con apenas meses de diferencia, dos investigadores norteamericanos lograron construir prototipos funcionales de circuitos integrados y obtuvieron patentes por sus emprendimientos. Uno de ellos, Jack St. Clair Kilby, comenzó a trabajar en Texas Instruments en 1958, y, por ser un nuevo empleado, no contó con vacaciones. A Kilby se le pidió investigar un problema conocido como “Tyranny of numbers”, al que se dedicó, en soledad, durante todo el verano. Consistía, básicamente, en que la elevada cantidad de componentes que tenían las computadoras de la época (recordemos las 17.500 válvulas de ENIAC) habían aumentado exponencialmente la cantidad de conexiones que se requería entre los mismos a un nivel ingobernable. Cada una de estas conexiones, por lo general, eran puntos de soldadura manuales y, por lo tanto, potenciales fallas muy difíciles de diagnosticar. La solución que Kilby pensó constaba en fabricar todos los componentes necesarios para un circuito sencillo en masa, en una única pieza de material semiconductor. Para su prototipo utilizó Germanio montado sobre placas de vidrio. Al prototipo conectó un osciloscopio en el que se podía observar una onda senoidal, producto del correcto funcionamiento del circuito. Su idea gozó de aceptación entre los ejecutivos de TI, pero estos, habiendo aprendido la lección de Bell y su uso de la radio para popularizar los transistores, le pidieron a Kilby que desarrollara las primeras calculadoras miniaturizadas. La receta tuvo éxito nuevamente y tanto las minicalculadoras electrónicas de Texas Instruments como los circuitos integrados se vendieron como pan caliente. Kilby, quien también concibió las primeras impresoras térmicas que se comercializaron, obtuvo, en el año 2000, el premio Nobel de física por su vital invención.

El otro investigador que, en 1959, logró fabricar un circuito integrado funcional fue Robert Noyce. Denominado como “el alcalde de Silicon Valley”, Noyce fue cofundador de dos empresas muy importantes: Fairchild Semiconductor y nada menos que de Intel. Noyce presentó, apenas seis meses después que Kilby, un prototipo de circuito integrado más complejo, conocido, en ese entonces, como “circuito unitario”. Su concepto era más similar al diseño de los integrados actuales que el prototipo de Kilby. Robert, además, (a diferencia de otros pioneros, que se atribuyeron ideas ajenas) dió crédito a su colega Kurt Lehovec, profesor de la USCLA, como autor de investigaciones fundamentales sobre el tema, de las que se sirvió para su trabajo. Lehovec todavía vive, está retirado hace años y se dedica a escribir poesía. Pero volviendo a Noyce, en 1968, junto a Gordon Moore (autor de la famosa ley que enuncia que la cantidad de transistores dentro de un integrado se duplica cada 24 meses) fundó Intel Corporation, la mayor empresa de fabricación de semiconductores del mundo.

PRIMEROS EQUIPOS CON ICs
Los circuitos integrados tardaron escasos años en ser adoptados por los grandes fabricantes de computadoras. Una de las primeras computadoras en utilizarlos fue la computadora de navegación del Apolo, el programa espacial que llevó al hombre a la Luna; también se los usó, inicialmente, en sistemas de navegación de misiles balísticos. En 1964, Digital Equipment Corporation (DEC) lanzó al mercado la primera minicomputadora, la PDP-8. Por cierto, el término “minicomputadora” se debía, naturalmente, a que el circuito integrado había permitido fabricar equipos mucho más poderosos, pero, sobre todo, más reducidos en tamaño y más eficientes en relación al consumo de energía con respecto a sus antecesores de la década del 50 (de la legendaria ENIAC se decía que, cuando se ponía en marcha, todas las luces de Filadelfia disminuían apreciablemente su brillo). La PDP-8 costaba unos módicos 16.000 dólares. Su memoria era de 4096 words de 12 bits, expandible a 32.768 words (equivalentes a 48 KB). Su memoria de núcleo magnético tenía tiempos de acceso de 1,5 microsegundos. La PDP-8 se vendió durante muchos años, en los cuales se la fue mejorando considerablemente, totalizando su venta las 300.000 unidades. En sus inicios, se programaba directamente en lenguaje máquina. Luego, se utilizó un ensamblador, y, años después, se fueron lanzando compiladores para distintos lenguajes, como FORTRAN y BASIC. El Sistema Operativo que usaba era OS/8, que podía bootear el equipo en medio segundo desde el disco rígido.

IBM, en cambio, tardó en adoptar esta tecnología para sus equipos. Para empezar, a diferencia de casi todas las tecnologías incluidas en sus computadoras, la misma no había sido inventada por ellos. Por otro lado, a los ingenieros de IBM no les gustaba la idea de servirse de ICs como memoria, ya que estaban acostumbrados a la memoria de núcleo magnético, que retenía su contenido al apagar el equipo. Sin embargo, eventualmente, la System/370, lanzada al mercado en 1970, utilizó también memorias basadas en circuitos integrados.

LA LLEGADA DE LA CUARTA GENERACIÓN
Como hemos podido observar, ya en los años 60 estaban sentadas las bases sobre las que descansan los diseños de las computadoras modernas. En la próxima entrega, veremos cómo, apenas unos años después, en la década del 70, la invención del microprocesador contribuyó a la llegada de la cuarta generación, antecesoras casi directas, en cuanto a conceptos de diseño, de los equipos actuales. Además, comenzaban a aparecer las primeras computadoras hogareñas, con las que muchos de nosotros nos iniciamos, verdaderas responsables, en definitiva, de la universalización de las computadoras.

Aquí vemos una foto de el primer integrado fabricado por Kilby. Era un crudo circuito fabricado en una pieza de germanio montada sobre placas de cristal, suficiente para demostrar su correcto funcionamiento. -Click en la imagen para agrandar-

Aclaración: Este post fue publicado originalmente en la revista POWERUSR #46. TODOS LOS DERECHOS RESERVADOS. PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL SIN EL CONSENTIMIENTO EXPRESO DEL AUTOR. SE PERMITE EL ENLACE O LINKEO A ESTE POST SIN NINGÚN TIPO DE RESTRICCIONES.