Puesta en marcha de los servicios:
Una vez instalado Squid, el siguiente paso es hacer algunas modificaciones mínimas necesarias en el archivo de configuración, el mismo que se encuentra en la carpeta etc/ dentro del directorio en el que hayamos instalado Squid. Por ejemplo, /usr/local/squid/etc/. El archivo se llama squid.conf, y los parámetros que obligatoriamente hay que establecer son:
http_port: Indica el puerto en el que se van a escuchar peticiones http por parte de los clientes. Comunmente se utiliza el puerto 8080.
cache_mem: Indica la cantidad de memoria que se utilizará para agilizar el caché. Es muy importante tomar en cuenta que squid usará considerablemente más memoria de la que nosotros especifiquemos aquí, por lo que no hay que establecer un valor muyh alto. Yo utilizo 8 MB (por defecto), y trabaja sin ningún problema.
cache_dir: Directorio y espacio máximo de disco para cache de squid. Por defecto tomamos los valores:
cache dir ufs /usr/local/squid/var/cache 100 16 256
El primer valor (100) indica el espacio de disco en MB máximo para usarse como caché.
host_file: Permite indicar el archivo de hosts de nuestro sistema, típicamente, /etc/hosts.
acl y http_access: la sección acl nos permite definir listas de acceso, es decir, de qué direcciones IP se recibirán peticiones http, o cuáles puertos se bloquearán. Hay valores por dfecto, pero nosotros debemos definir nuestra propia red. Por ejemplo, yo tengo añadida la siguiente línea en segundo lugar entre los valores por defecto:
acl lan src 192.168.0.0/255.255.255.0
Con lo cual estoy añadiendo una listo de acceso que inicia en la IP 192.168.0.0 y con netmask 255.255.255.0 (o sea, finalizaría en la IP 192.168.0.255). En el siguiente apartado, veremos otros tipos de ACLs que proporcionan mayor y más preciso control sobre quienes y a qué direcciones podrán acceder a través de nuestro proxy Squid.
Retomando el ejemplo anterior, debo habilitar esta lista, indicando que de todas estas IPs se recibirán peticiones. Esto se hace en la sección http_access. Yo lo tengo de la siguiente manera:
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS http_access allow lan
Nótese que lo he insertado en la parte recomendada en el propio archivo de configuración, y además, que se utiliza el mismo nombre con el que se haya creado la acl, en este caso, lan.
visible_hostname: Podemos establecerlo al nombre de host que normalmente utilicemos en nuestro propio equipo, por ejemplo, servidor.
refresh_pattern: Nos permite especificar qué tipos de objetos se van a almacenar en el caché, y además, con qué frecuencia se van a refrescar, es decir, se van a buscar nuevas versiones de los objetos. Resulta muy útil, desde el punto de vista de que por defecto, squid únicamente almacena objetos ftp, y ghoper, pero nosotros podemos indicar que además se almacenen objetos de otros tipos, como código html, imágenes jpg, gif, archivos swf de flash, etc.
Yo trabajo con la siguiente configuración:
refresh_pattern \.mid 10080 90% 10080 refresh_pattern \.wav 10080 90% 10080 refresh_pattern \.gif 2880 90% 10080 refresh_pattern \.jpg 2880 90% 10080 refresh_pattern \.swf 2880 90% 10080 refresh_pattern ^http: 2880 40% 4320 refresh_pattern ^ftp: 240 50% 1440 refresh_pattern ^gopher: 240 40% 1440 refresh_pattern . 240 20% 4320
Lo cual proporciona un rendimiento bastante rápido y aceptable. Note que el primer argumento es una expresion regular, así que si sabes manejarlas , podrás hacer referencia a URLs de objetos bastante específicas. Los valores que se encuentran encolumnados al final de cada línea, se se encuentran por demás explicados en el mismo archivo de configuración, y en ciertas páginas de Internet referentes a Squid.
Cabe indicar que existen muchas opciones más que podemos configurar, pero las indicadas son las mínimas para un correcto funcionamiento del programa. El propio archivo de configuración contiene explicaciones y ejemplos en todas sus secciones.
Si analizamos cuidadosamente los comentarios incluidos en el archivo de configuracion de Squid (squid.conf), veremos que se reconocen diferentes tipos de ACLs, los mismos que nos permiten definir listas basándonos en ciertos parámetros que pueden resultar de gran utilidad en determinado momento. A continuación, hablaremos brevemente sobre los más importantes:
ACL de tiempo (time). Este tipo de lista nos permite definir cuándo se podrá acceder a Internet a trevés de nuestro proxy. Podemos definir los días de acceso, y además, las horas en las que es posible acceder. El formato para definir una ACL de tiempo es:
acl <nombre> time [abreviación-día] [h1:m1-h2:m2]
El primer parámetro (abreviación-dia) nos permite indicar los días en los que se permitirá acceso a los clientes, de acuerdo con el siguiente esquema:
S -> Domingo (Sunday) M -> Lunes (Monday) T -> Martes (Tuesday) W -> Miércoles (Wednesday) H -> Jueves (Thursday) F -> Viernes (Friday) A -> Sábado (Saturday)
Además, como es lógico, existe la restricción de que h1:m1 (hora/minuto inicial) debe ser menor que h2:md2 (hora/minuto final).
Aquí tenemos un ejemplo simple:
acl dias time MTWHF 08:00-18:00
Esto nos permitiría crear una lista para posteriormente permitir o denegar el acceso a través de Squid, de Lunes a Viernes entre las 8 de la mañana y las 6 de la tarde.
Por otro lado, tenemos las ACLs relacionadas con expresiones regulares. Esto nos permite definir listas basadas en ciertas palabras, frases, o secuencias de caracteres presentes en alguna parte de la solicitud http formulada por el cliente.
Los tipos de ACLs referentes a expresiones regulares son:
srcdom_regex
dstdom_regex
url_regex
urpath_regex
ident_regex
proxy_auth_regex
Dado que este es un MINI-Howto, que pretende dar una guía rápida a los usuarios nuevos e inexpertos de Squid, no profundizaré en ninguno de ellos. Sin embargo, hablaré de uno que a mi juicio es muy útil, y que en lo personal, me ha servido mucho: url_regex. Este tipo de ACL nos permite crear una lista que intercepta peticiones de los clientes en cuya URL se hallen ciertas palabras o frases. Resulta especialmente útil cuando por ejemplo debemos bloquear el acceso a sitios pornográficos (especialmente necesario cuando lo que estamos manejando es un local público) .
El formato básico para un url_regex ACL es:
acl <nombre> url_regex [-i] patrón
Donde patrón indica la palabra o palabras que deberán constar en la URL solicitada por el cliente. Podemos incluir la opción -i, que indica que no se diferenciará mayúsculas y minúsculas.
Por ejemplo, tenemos:
acl prohibidos url_regex -i gai sex lesb porn xxx nude
En este caso, es especialmente importante tener mucho cuidad de no bloquear accidentalmente ciertas palabras o frases de uso común. Por ejemplo, la expresión sex incluiría toda petición en cuya URL se hallen secuencias como sex, sexo y sexualidad, lo cual podría provocar un efecto inverso al deseado en ciertos casos.
Entonces, la solución (que yo utilizo) es uncluir otra ACL del mismo tipo (url_regex), donde consten ciertos términos que sí vamos a aceptar, a pesar de incluir las expresiones que normalmente estamos bloqueando. Una vez creadas ambas listas, primero especificamos que vamos a aceptar los términos correspondientes a una lista, y luego, denegamos aquellos correspondientes a la otra.
Por ejemplo, podríamos tener algo así:
acl permitidos url_regex -i sexualidad sextante asexual acl prohibidos url_regex -i sex
Y luego, en la parte correspondiente a http_access, tendríamos que incluir también lo siguiente:
http_access allow permitidos http_access deny prohibidos
El siguiente paso es construir el swap directory, que no es más que un árbol de directorios donde se guardarán los objetos y páginas de caché. Pero para esto, hay un detalle muy importante a tomar en cuenta: debemos cambiar el propietario del directorio var/ dentro del directorio squid/. En nuestro ejemplo, sería el directorio /usr/local/squid/var/. Si estamos siguiendo todas las recomendaciones de la documentación de squid, habremos creado previamente en nuestro sistema el usuario-grupo squid-squid. Si así lo hicimos, debemos asignarle al directorio var/ el propietario squid. Sería algo así:
chown -R squid.squid /usr/local/squid/var
En caso de que en nuestro sistema no exista el usuario y grupo squid, podemos utilizar otros, como por ejemplo, nobody-grupo, donde grupo puede ser cualquier grupo creado por nosotros mismos. El usuario nobody supuestamente ya existe en el sistema (al menos en mi caso, fue así).
Procedemos a crear el swap directory, de la siguiente manera:
# /usr/local/squid/sbin/squiz -z
Y listo
Hecho esto, estamos listos para utilizar squid. Par ainiciar el engine del programa, sólo debemos hacer:
# /usr/local/squid/sbin/squid
De esta forma, se crearán 2 procesos que corren en el background de nuestro sistema, o como se suele decir, corre como servicio. Una forma rápida de comprobar que squid está funcionando es mediante el comando:
# ps -A | grep squid
Y si todo va bien, deberíamos visualizar:
875 ? 00:00:00 squid 1040 ? 00:03:04 squid
Tomando en cuenta que los PID (ID de proceso, por ejemplo 875 y 1040) deberían ser diferentes. Y LISTO!!!
Como ya habíamos dicho, delegated puede actuar tanto como servidor proxy http , como servidor socks 4-5.
Para ejecutar el servidor socks, nada más sencillo:
# ./delegate8.3.3/src/delegated -P1080 SERVER=socks
Esto suponiendo que estamos en el directorio delegate8.3.3, por supuesto. Aparecerá un texto de varias líneas, lo que nos indica que está corriendo el programa, y a continuación presionamos cualquier tecla, y recuperamos el prompt #. Listo, para comprobar que el programa realmente está escuchando peticiones, pdremos de igual manera ejecutar:
# ps -A | grep delegate
Al igual que en el caso de squid, veremos algo similar a esto:
902 ? 00:00:00 delegated 1992 ? 00:00:00 delegated
Cabe anotar que cuando ejecutamos delegated, normalmente se iniciará un solo proceso correspondiente, como en el ejemplo, el 902. Sin embargo, una vez que inician las peticiones por parte de los clientes, se van generando más procesos de delegated, seguramente hijos del proceso original.
Para ejecutar el servidor proxy http, sólo hay que modificar levemente el comando para socks, quedando de la siguiente manera:
# ./delegate8.3.3/src/delegated -P8080 SERVER=http
Con lo que abriríamos un proceso que escuchará peticiones http de nuestros clientes en el puerto 8080. Tal vez ustedes se preguntarán por qué razón utilizo Squid y Delegate, pudiendo utilizar sólo Delegate, ya que también funciona como proxy http. La repuesta es que Squid me parece notablemente mejor que Delegate como servidor proxy. Cuando se utiliza el servicio http de Delegate, la navegación para los terminales se hace como más "lenta". Me parece que Delegate no se ayuda de un caché, aunque no estoy seguro de que se trate de eso. Pero en todo caso, con Squid se nota mayor velocidad de respuesta. Esa es la razón.
En realidad Delegate puede actuar, además de como servidor proxy http, y servidor socks, también como proxy ftp, nntp, smtp y otros. Para mayor información, se puede buscar en los manuales y documentación en la web de Delegate. Más adelante, también se incluyen las páginas man tanto de Squid como de Delegate.
Bien, ahora que tenemos instalados los servicios proxy http y socks que necesitábamos en nuestra red, y que sabemos cómo ejecutarlos, lo más lógico sería que estos programas arrancaran automáticamente cuando iniciamos nuestro sistema, en lugar de estar memorizando y digitando los comandos manualmente en cada ocasión, cierto???
Hacer esto, también es algo sencillo. Lo aprendí, una vez más, gracias a Ricardo Cervera, y la forma de hacerlo es:
Comencemos con Squid. Primero iniciamos sesión como root, y creamos un archivo de texto con el siguiente contenido:
#!/bin/bash /usr/local/squid/sbin/squid
Y lo guardamos en la carpeta /etc/init.d/ con un nombre significativo, como por ejemplo mi_squid. Luego, le damos al archivo el atributo de ejecutable, y creamos un enlace a este desde otra carpeta, como sigue:
# chmod +x /etc/init.d/mi_squid # ln -s /etc/init.d/mi_squid /etc/rc5.d/S98squid
Y ya está!!! La próxima vez que iniciemos el equipo, estará automáticamente ejecutándose Squid, aún cuando no iniciemos ninguna sesión.
Para Delegate, hacemos exactamente lo mismo, solo que el archivo debería llamarse algo así como mi_delegate, el comando en el archivo de texto sería el adecuado para iniciar delegate ( y no squid ), y el nombre del enlace que crearemos podría ser, por ejemplo, S99delegate.
Indicar que en el nombre de los enlaces, S indica que iniciará un servicio, y 98 o 99, el orden en que iniciará el servicio (respecto a los demás que inician automáticamente). En este caso, con 98 y 99 , Squid y Delegate inician en mi sistema al final, antes de ingresar al modo gráfico. Por otro lado, los enlaces los hemos incluido en la carpeta rc5.d, con lo cual, los servicios iniciarán siempre y cuando arranquemos en runlevel 5 (modo gráfico en mi caso), con lo cual hay que tener mucho cuidado, ya que dependiendo de algunos factores, como la distribución que estemos utilizando, o el modo en el que hayamos decidido instalar Linux, iniciaremos o no en runlevel 5. Podemos ver el runlevel que nuestro sistema arranca por defecto con:
# cat /etc/inittab | grep initdefault | cut -d\: -f2
El último número que veamos en la salida del comando anterior será el runlevel que debemos utilizar si es distinto de 5 para crear los enlaces anteriores (sustituir el 5 por ese número).
Listo. Así es como yo lo tengo hasta ahora, y todo marcha de maravilla.