Estación de Tránsito

En los medios tradicionales, un puñado de grandes empresas seleccionan, con un criterio parcial y un gusto más bien dudoso, los contenidos que son difundidos. En la Web, la cantidad de información y entretenimiento disponible parece inagotable, ya que armar un sitio está al alcance de cualquiera. Además, no existen las restricciones horarias ni económicas, como en la TV por cable. Pero las limitaciones también existían en la WWW: los usuarios sólo accedían al material elegido por los responsables de cada sitio. Actualmente, con la Web 2.0, son los usuarios quienes crean, comparten y comentan los contenidos.

QUÉ ES WEB 2.0

El término Web 2.0 fue acuñado, en 2003, por O’Reilly, una importante empresa editora de libros y websites dedicados a la enseñanza de las Tecnologías de la Información. Pese a su antigüedad, todavía se debate su significado exacto. Sucede que, en realidad, el “2.0″ no tiene nada que ver con la versión de HTTP, el protocolo sobre el cual se desarrolla la web. Más precisamente es un término conceptual para diferenciar la forma en la que funcionaba la web inicialmente de su estado actual. Por supuesto que hay sitios que sólo hacen uso de las tecnologías existentes desde el lanzamiento de la WWW a principios de los 90, pero la mayoría de los sitios modernos han evolucionado notoriamente. En primer lugar, debemos mencionar la aparición de la llamada “web invisible”. A diferencia de los sitios originales, cuyo contenido era enteramente estático y organizado rígidamente, gran parte de los sitios actuales almacenan casi todo su contenido en una base de datos que trabaja en conjunto con el servidor web, el cual genera dinámicamente las páginas en el momento en que el usuario las solicita. Esto tiene múltiples ventajas, pero una gran contra: la mayoría del contenido del sitio es accesible sólo mediante determinadas acciones de los usuarios, pero permanecen “invisibles” ante los ojos de los robots como el de Google, encargados de indexar el contenido de la Web, al que, luego, se podrá ingresar desde las búsquedas.

Estos sitios “dinámicos” se hicieron factibles, en mayor medida, gracias a tecnologías de Software Libre, como, por ejemplo, la plataforma conocida como “LAMP” (Linux, Apache, PHP, MySQL). Basándose en ellas, cientos de desarrolladores se volcaron a escribir software que permitiera generar y administrar contenidos de manera remota y dinámica. Comenzaron a aparecer los primeros “Foros”, sitios web que posibilitaban a los usuarios compartir y discutir distintas temáticas de su interés o, sencillamente, socializar. Rápidamente, fueron abrazados por la enorme comunidad formada en torno a las redes P2P, que encontraron, en los foros, el medio ideal para difundir y comentar sus actividades. También aparecieron los administradores de contenidos Open Source. Hasta entonces existían paquetes de software de costo altísimo, sólo accesibles para grandes medios. Con el surgimiento de aplicaciones como Wordpress, a cualquier usuario le fue dado convertirse en su propio editor y tener su “diario en la web”, en inglés web log, o la abreviatura por la que hoy todo el mundo conoce a este tipo de sitios web: Blog.

PRIMERAS REDES SOCIALES

El primer sitio web en implementar una red social online posiblemente fue Classmates.com, en el año 1995. Creado con la idea de permitir a sus usuarios retomar y mantener contacto con amigos y compañeros de estudios, su éxito fue contundente. Basta mencionar que, hoy en día, cuentan con más de 40 millones de usuarios. Otros sitios se subieron al tren velozmente, como SixDegrees.com en 1997, Ciao.com en 1999 y Friendster en 2002. Al mismo tiempo, los primeros usuarios-editores de blogs comenzaron a darle cada vez mayor importancia a la interacción con sus lectores a través de los sistemas de comentarios, que facilitaba a los usuarios debatir sobre los contenidos posteados por el editor. Un blogger más que famoso en la actualidad, Rob “CmdrTaco” Malda, desde su blog de tecnología Slashdot.org (fundado en 1997) amplió la participación de sus lectores al habilitarlos para enviarles distintos contenidos o enlaces a los editores del site, quienes, luego, seleccionaban y categorizaban los aportes más interesantes para su publicación. El éxito de Slashdot fue y es tal, que sus lectores provocan, habitualmente, el “Slashdot effect” en los servidores web que alojan los contenidos linkeados en Slashdot. Este efecto consiste, básicamente, en que tanta cantidad de usuarios intentan acceder al contenido simultáneamente que colapsan a los servidores web, los que a menudo dejan de responder hasta que baja la demanda.

Para mantener Slashdot se desarrolló un soft de código abierto llamado Slash. Desarrollado sobre LAMP (pero reemplazando PHP por Perl), posibilitó el surgimiento de muchos sitios similares, entre los cuales se destaca especialmente Barrapunto.com, considerado por muchos “el slashdot de habla hispana” por su enfoque en los temas técnicos y científicos, al igual que por su fiel legión de fanáticos. Pero volviendo a Slashdot, cuando su base de usuarios se hizo numerosa, también creció exponencialmente la cantidad de comentarios que dejaban en cada artículo, hasta transformarse en un caos ingobernable. Entonces, se ampliaron aún más las facultades de sus usuarios, permitiéndoles moderar los comentarios de los demás, ocultando aquellos que disgustan a la comunidad “Slashdotter” y promoviendo, en cambio, los valiosos. Fue, en base a este complejo sistema de moderación, que Slashdot y sus “clones” comenzaron a conformar auténticas redes sociales entre sus visitantes.

LA WIKI WEB: EL USUARIO AUTOR

Cuando Tim Berners-Lee creó la WWW, incluyó en el protocolo HTTP un tag para permitir a los usuarios modificar páginas. Por distintas razones (potenciales brechas de seguridad, falta de conocimiento de los usuarios, temor a la pérdida de privacidad), dicha posibilidad no fue utilizada por los webmasters y su existencia permaneció en la oscuridad. Pero, en 1994, el desarrollador Howard Cunningham dió a luz la WikiWikiWeb, el primer sitio Wiki. Hoy en día, todos sabemos que esta palabra hace mención a un sitio web que autoriza a los usuarios para crear y modificar todo o parte de su contenido. Pero, cuando Cunningham bautizó el sitio con el nombre WikiWikiWeb, la palabra de origen hawaiano “wiki” significaba solamente “rápido”. Howard la eligió al recordar a un empleado del aeropuerto de Honolulu, quien le recomendó tomar el bus “Wiki Wiki”.

Las primeras wikis pasaron desapercibidas, perdidas como agujas en el inmenso pajar de la web y sus millones de sitios. Como sucede con la mayoría de las innovaciones en el mundo de la tecnología, al principio únicamente los especialistas en informática conocían su existencia. Pero, en 2001, comienza una verdadera explosión en la difusión de este tipo de sitios web a partir del nacimiento de Wikipedia. En principio, surge como hermana menor de otra enciclopedia libre, Nupedia, redactada exclusivamente por expertos, ante la insistencia de sus usuarios por participar de alguna manera. Larry Sanger, cofundador de Nupedia, se enteró de la existencia de los sitios wiki gracias a un amigo programador. Propuso implementar un wiki como proyecto complementario de Nupedia, y así nace Wikipedia (el resto conforma una breve pero rica historia ya digna de un artículo propio). Además de sus méritos comunitarios y educativos, una de las principales virtudes es haber instalado definitivamente entre nosotros a las Wikis, que, en los últimos tiempos, se han multiplicado como hongos, sobre todo en torno a las distintas comunidades, como las del software libre o las de los gamers, que las han elegido como reemplazo superador de FAQs, HOWTOs y otros métodos de documentar todos los aspectos de un software determinado.

LOS SITIOS 2.0 SE MULTIPLICAN

Ya bien entrados los 2000, empiezan a aparecer muchos sitios que, actualmente, han ganado inmensa popularidad, al punto de ser reconocidos como los exponentes más importantes de esta nueva generación de la web. En 2003, se inicia del.icio.us, el excelente sitio de bookmarking social. En 2004, debuta Flickr (cuyo desarrollo había comenzado dos años antes), la web en donde los aficionados a la fotografía de todo el mundo comparten sus obras. El suceso de ambos es de tal magnitud que Yahoo! no se quiere perder su parte y los compra. También en 2004, surge Digg.com, un sitio de noticias de tecnología inspirado en Slashdot, pero que lleva el concepto al extremo, ya que Digg carece de editores, por lo que son los propios usuarios los que seleccionan y categorizan las noticias enlazadas en el sitio mediante un sistema de votaciones. El concepto de “sitio enteramente manejado por una comunidad” de Digg se transformó en un modelo que, rápidamente, fue imitado por muchos y, aunque el soft que hace funcionar a Digg es de código cerrado, pronto se desarrollaron clones de código libre que permitieron la proliferación de sitios “sin editor”. Ese mismo año, se abre al público MySpace.com, probablemente la web más popular de redes sociales de estos días, principalmente en Estados Unidos, en donde hasta las celebridades tienen su espacio. Ya en 2005, llega YouTube.com, el site de videos que, en apenas dos años, ha ganado enorme popularidad y del que se ha formado una gran comunidad a su alrededor, al punto de ser comprado por Google (que ya poseía un servicio muy similar, Google Video) en una suma increíble: 1650 millones de dólares. En esos tiempos, nace Reddit.com, otro sitio de noticias sociales, con mayor énfasis en lo cultural y lo político. También se lanza Technorati, un portal y buscador de blogs que hoy es un puntal de la comunidad de bloggers. Ya en 2006 se populariza StumbleUpon, una web con un concepto atractivo: ofrecerles a los navegantes la posibilidad, a través de plugins en los browsers, de calificar los distintos sitios por los que van navegando, lo cual permite compartir los sitios interesantes con una comunidad de usuarios con gustos afines.

AVANCES TÉCNICOS DE LA ERA 2.0

Todas estas modificaciones en los aspectos “sociales” de la web necesitaban de una evolución en las características técnicas de las páginas. Además de tornarse masivo el uso de sitios dinámicos, en lo que hace a la presentación visual de las páginas hubo mejoras que no sólo facilitaron tanto la tarea de los diseñadores como la de los desarrolladores, sino que, también, se avanzó en la cosmética de las páginas. Dejaron de utilizarse los frames (en la actualidad son casi mala palabra) y las tablas para armar el layout de las páginas, lo cual es buena idea, teniendo en cuenta que las tablas nunca fueron pensadas para eso en primer lugar. Los sitios 2.0 trabajan con Hojas de Estilo (CSS, Cascading StyleSheets), que, en primer lugar, separan el contenido de la presentación y, por otro lado, aportan una gran cantidad de herramientas visuales a los diseñadores para mejorar el aspecto estético de las páginas. Además, la adopción en masa del lenguaje JavaScript por parte de estos sitios facilitó una mejora contundente en la usabilidad, funcionalidad y velocidad de respuesta, a punto tal que algunos sitios modernos son capaces de emular e incluso reemplazar exitosamente a las aplicaciones de escritorio. Google es, nuevamente, adalid de estas tecnologías, y algunos de sus productos hacen uso extensivo de ellas para permitir que, desde una página web, se pueda organizar nuestro calendario semanal arrastrando y soltando las citas con el mouse (Google Calendar), e inclusive procesar textos y manejar planillas de cálculo (Google Docs & Spreadsheets). También aparecieron sitios con aplicaciones para edición de imágenes y retoque de fotografías (Pixer.us, Snipshot.com), para ver documentos PPT, PDF, etc. (Docufarm.com), y hasta supuestos “Sistemas Operativos Web”, que no son otra cosa que entornos de escritorio experimentales que corren en un browser, como YouOS.com, que si bien están todavía lejos de la potencia y funcionalidad que puede brindar una aplicación de escritorio, tienen la indudable ventaja de ofrecer el acceso a estos aplicativos desde cualquier máquina conectada a Internet, por más vieja o lenta que sea: alcanza con que sea capaz de ejecutar un navegador.

EL FUTURO AÚN NO LLEGÓ

Si consideramos que muchos de estos cambios, que trajeron adelantos que hoy consideramos como elementos básicos de un site web, tardaron muchos años en producirse, no cabe duda de que la Web se encuentra todavía en su tierna infancia y le aguarda una juventud a pleno crecimiento, ya que la cantidad de usuarios y desarrolladores, con el transcurso de los años, aumenta a pasos de gigante. Si las conexiones hogareñas de banda ancha ofrecieran abundante ancho de banda a precios razonables, estos avances se acelerarían todavía más, como también sucedería si las grandes empresas desarrolladoras de software respetaran los estándares existentes y no trabaran muchos desarrollos nuevos haciendo uso de amenazas legales por violación de propiedad intelectual, valiéndose de patentes mal otorgadas. Pero el mundo de Internet ha demostrado ampliamente, a lo largo de su existencia, que su voluntad mayoritaria y manifiesta es que la red sea libre, universalmente accesible y en constante crecimiento y evolución. Bienvenida será, entonces, la Web 3.0; que llegue pronto depende, en gran parte, de todos nosotros.

Con Google Docs & Spreadsheets, en donde se escribió esta nota, llevamos la oficina a todos lados. Nos ofrece un procesador de textos y una planilla de cálculos de funcionalidad más que respetable, que corre en cualquier browser y, por lo tanto, no necesita instalación. Trasladar las aplicaciones que usamos todos los días en el escritorio a la web es parte importante del mundo 2.0. (Click para agrandar)

Flickr se ha vuelto indispensable tanto entre quienes comparten sus álbumes de fotos familiares, como entre los profesionales de la fotografía que desean mostrar su trabajo, por su excelente interfaz, sencilla e intuitiva. (Click para agrandar)

Snipshot.com, un buen ejemplo de site Web 2.0, permite hacer rápidamente retoques sencillos a imágenes que podemos subir desde nuestro equipo o desde otro site. (Click para agrandar)

YouTube, además de ser conocido mundialmente por la infinita cantidad de videos con la que cuenta, es un puntal de la Web 2.0 por las técnicas de programación innovadoras con el que está desarrollado el sitio, que permitieron que nos acostumbremos a ver videos sin almacenarlos en nuestro disco, algo impensable hace muy poco. (Click para agrandar)

Aclaración: Este post fue publicado originalmente en la revista POWERUSR #47. 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.

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.