Como configurar un proxy en Debian

En el día de hoy os vengo a hablar sobre un aspecto bastante usado por los usuarios en la actualidad: Los proxies. Un proxy no es ni más ni menos que un intermediario que gestiona las peticiones de un equipo. Por ejemplo, cuando un usuario se conecta a sitio web a través de un proxy, el sitio web pensará que el que se ha conectado al sitio es el proxy y no el usuario, lo cual para según qué cosas puede ser útil (políticas de cortafuegos, seguridad del usuario, distribución del tráfico según el origen de la conexión, etc...). Estos recursos son algo polémicos debido a los posibles usos delictivos que se le pueden dar, pero no cabe duda que a veces son necesarios para realizar algunas tareas o para entrar a algunos sitios web, con lo que llegaríamos a la conclusión de que un proxy se trata de un arma de doble filo que puede usarse para bien o para mal dependiendo de las intenciones del usuario. En el post de hoy hablaré sobre cómo implantar un sencillo proxy en un sistema Debian, aunque bien podría ser extendido a distribuciones basadas en éste.

Existen varias herramientas para lograr nuestro objetivo, pero la más popular de todas ( y la que usaremos en este post) se trata de squid, la cual se encuentra en su tercera versión en estos momentos. Dicha herramienta destaca por su simpleza a la hora de configurarla y su poquísimo consumo de recursos por parte del sistema. Además posee de una caché diseñada para optimizar la navegación web y visualizar las páginas más rápido. Al igual que la mayoría de las herramientas más populares dentro del entorno Linux, carece de interfaz gráfica, aunque esto no debería ser un impedimento pues tal y como he dicho su configuración es sumamente sencilla.

El software no está instalado por defecto en el sistema, pero viene incluido con los repositorios oficiales con lo que simplemente habría que instalarlo desde éstos con el comando apt-get tal que así:

1. apt-get install squid3

El proceso de instalación apenas toma unos segundos, permitiéndonos así poder pasar a la configuración de nuestro proxy. La configuración de squid está ubicada en un único fichero ubicado en /etc/squid3, cuyo nombre es squid.conf. El fichero en sí abarca todos y cada uno de los parámetros configurables del software, teniendo ante nosotros un fichero de gran envergadura (casi 6000 líneas) que en un principio puede parecer intimidante, pero que tras familiarizarnos un poco con él nos parecerá sencillo de entender. Es importante resaltar que squid ya está configurado por defecto para trabajar con localhost, con lo que la gran mayoría de los parámetros existentes no será necesario modificarlos.

El primer parámetro importante que nos toparemos será la lista de control de accesos o ACL, de la cual hemos hablado en este blog anteriormente en referencia a los permisos de los ficheros en Linux; Este concepto ha sido extendido ahora a esta herramienta, en la cual poseen una lista de control de accesos que controla qué ips de origen pueden acceder al proxy y qué ips no. Por defecto el software está diseñado para que únicamente la ip 127.0.0.1 (localhost) pueda usar el proxy, cosa que no deseamos, pues impide que el resto de equipos puedan usar esta utilidad. Para ello habría que empezar modificando la sección ACL para asociar un conjunto de direcciones ip a un nombre en concreto; Dicha sección empieza en la línea 687 del fichero y la modificación a realizar será el añadido de una línea al final de la sección. La línea que añadiremos tendrá la siguiente estructura:

acl ${nombre_grupo} src ${rango_ip}/${mascara}

La línea en cuestión representa que se impone una lista de control de accesos con un nombre determinado, como por ejemplo test.lan, para todas las ips que tengan un rango determinado. En mi caso por ejemplo para todas las ips que se encuentre entre 192.168.1.0 y 192.168.1.255. Basándonos en esta estructura e información, la sección referente a las ACL quedaría de la siguiente forma:

1. #Default:
2. # acl all src all
3. #
4. #
5. # Recommended minimum configuration:
6. #
7. acl manager proto cache_object
8. acl localhost src 127.0.0.1/32 ::1
9. acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1
11. # Example rule allowing access from your local networks.
12. # Adapt to list your (internal) IP networks from where browsing
13. # should be allowed
14. #acl localnet src 10.0.0.0/8    # RFC1918 possible internal network
15. #acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
16. #acl localnet src 192.168.0.0/16        # RFC1918 possible internal network
17. #acl localnet src fc00::/7       # RFC 4193 local private network range
18. #acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines
19. acl test.lan src 192.168.1.0/24

Como habréis podido observar, la modificación que se ha hecho en el fichero corresponde únicamente a la última línea, dejando intactos el resto de valores. Aún así esto no es suficiente; con lo que hemos hecho únicamente hemos asociado un nombre de grupo a un conjunto de ips, ahora habría que concederle permiso a dicho grupo para que puedan acceder al proxy. Para ello habría que desplazarse a la sección de permisos, conocida en esta herramienta como http_access. Dentro de dicha sección se definen qué grupos poseen permisos, y qué grupos no. De momento únicamente estaría localhost, con lo que habría que añadir nuestro grupo al conjunto de grupos con permiso para usar el proxy. La sección en cuestión comienza en la línea 835 (siempre y cuando no se hayan introducido más líneas) y simplemente habría que añadir una línea con la siguiente estructura:

http_access allow ${nombre_grupo}

La línea simplemente define si un grupo posee acceso o no y por defecto todos los grupos no tienen acceso al proxy a menos que se defina lo contrario. En nuestro caso el grupo que queremos añadir es test.lan, con lo que la sección tendría el siguiente aspecto:

1. #
2. # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
3. #
5. # Example rule allowing access from your local networks.
6. # Adapt localnet in the ACL section to list your (internal) IP networks
7. # from where browsing should be allowed
8. #http_access allow localnet
9. http_access allow localhost
10. http_access allow test.lan
12. # And finally deny all other access to this proxy
13. http_access deny all

En este caso la línea añadida no se ha insertado al final de la sección, sino que antes del parámetro http_access deny all, con el fin de distinguir los grupos que tienen acceso de los que no. Ahora mismo únicamente los grupos localhost y test.lan tendrían acceso al proxy. 

Esto de por sí sería suficiente para que squid funcionase, pero hay unos  parámetros muy interesantes que es conveniente tener en cuenta. Estos son el puerto de escucha, el tamaño de la caché y el tamaño de los objetos que se crean en la caché.

El primer parámetro simplemente consiste en el puerto en el que queremos que squid escuche. Cada vez que uno se conecta un proxy, debe especificar la dirección y el puerto de escucha. Por defecto squid escucha en el puerto 3128, lo cual en un principio no debería darnos ningún problema, pero si por el motivo que fuese lo deseásemos cambiar, tendríamos que dirigirnos al parámetro http_port, el cual se encuentra en la línea 1615 (la línea puede variar dependiendo de las modificaciones hechas anteriormente) y modificar su valor. Por ejemplo, en mi caso voy a modificar el parámetro para que escuche en el puerto 10000, tal que así:

1. # Squid normally listens to port 3128
2. http_port 3128

En segundo lugar estaría el tamaño de la caché, que sirve para optimizar la navegación del usuario final. Cuanto mayor el tamaño de la caché, mayor la cantidad de sitios que se podrán almacenar en squid, lo que conllevará a una mejor experiencia para el usuario final. La diferencia no es demasiado significativa, pero puestos a tener un proxy óptimo, es preferible poseer un espacio en caché considerable. Squid está diseñado para almacenar objetos de caché en la solamente en la memoria RAM, lo cual hace que cuando el equipo se reinicia, todo lo guardado en la memoria es eliminado... Para evitar dicho problema y para al mismo tiempo mejorar la experiencia del usuario, configuraremos un parámetro llamado cache_dir, el cual especifica un fichero que almacenará la caché y el tamaño máximo de éste. Por defecto tenemos el parámetro comentado (es decir, inhabilitado) pero ya está preparado para crear un fichero squid3, que se almacenaría en el fichero /var/spool/; dicho fichero tendría un tamaño de 100 Megabytes, un tamaño respetable, pero que puede quedarse algo escaso; además, si tenemos en cuenta las capacidades de disco duro que poseemos hoy en día, podemos crear un fichero mucho más grande sin miedo a quedarnos sin espacio. Por ejemplo, puede ser una buena idea hacerte una caché de 2048 Megabytes. Con lo que iremos a la línea 3236 (repito que la línea puede ser distinta dependiendo de lo introducido anteriormente) y modificaremos la línea para dejarla tal que así:

1. #Default:
2. # No disk cache. Store cache ojects only in memory.
3. #
4. # Uncomment and adjust the following to add a disk cache directory.
5. cache_dir ufs /var/spool/squid3 2048 16 256

Por último, pero no menos importante, está el tamaño de los objetos que se almacenan en la caché. Toda página que se visite creará un objeto en la caché de un tamaño determinado... Dichos objetos suelen ser de un tamaño bastante pequeño, pero pueden haber excepciones que ocupen mucho espacio. Squid está configurado por defecto para almacenar objetos de hasta 4 megabytes, lo cual es suficiente para la mayoría de los sitios, pero puede haber algunas páginas, como youtube por ejemplo, que pueden llegar a crear objetos de mayor tamaño. Es por ello que es recomendable aumentar un poco el tamaño máximo de los objetos modificando el valor maximum_objet_size. Dicho valor se halla en la línea 3063 (más o menos) un valor adecuado para dicho parámetro sería 10 MB tal y como se muestra en el siguiente ejemplo:

1. #Default:
2.  maximum_object_size 10 MB

Teniendo todos los parámetros configurados, solamente habría que reiniciar el servicio mediante el comando:

1. /etc/init.d/squid3 restart

Probando el proxy

Todo está configurado, pero todavía queda lo más importante, la prueba del correcto funcionamiento del proxy. Para ello se necesita conocer dos parámetros: la ip del servidor y el puerto de escucha de éste. Teniendo estos dos parámetros presentes, usaremos un navegador para realizar la prueba. En este caso en particular me he decantado por el navegador Firefox, pero el concepto sería el mismo en cualquier otro navegador. 

Para navegar por internet a través de un proxy desde Firefox, habría que dirigirse a Opciones -->Avanzado -->Red y dentro de dicha sección habría que clickar dentro del botón Configuración.

Dentro de dicha sección, observaremos una ventana denominada Configuración de conexión, esta ventana posee diferentes conexión de proxy, pero la que nos interesa es la Configuración manual del proxy. Dentro de esta sección, tenemos un campo llamado Proxy HTTP; dicho campo debe ser rellenado con la dirección ip del servidor y el puerto de escucha de squid (en este caso 10000). Además, habrá que marcar la casilla Usar el mismo proxy para todo, con el fin de asegurarnos que todas las conexiones (ya sea HTTP, SSL o FTP) pasen por el proxy, tal que así:

En caso de que tener algún parámetro mal configurado (ya sea por las ACL mal configuradas o un puerto mal establecido) nos mostrará el siguiente mensaje:

En caso de haber tenido todos los parámetros configurados correctamente, deberíamos navegar con normalidad por Internet, esta vez con la diferencia de que navegaremos a través de nuestro nuevo proxy.

Saludos.