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.

Con el crecimiento de las redes caseras y, sobre todo, con la explosión del Wi-Fi, la cantidad de equipos interconectados en los hogares crece exponencialmente. Más temprano que tarde necesitaremos compartir recursos entre equipos con los S.O. de Microsoft y aquellos potenciados por el Kernel del pingüino. Aquí te mostramos una de las formas de hacerlo utilizando SAMBA, un robusto y probado producto elaborado por la comunidad del software libre, viejo conocido de los administradores de redes corporativas.

En estos días,‭ ‬la interoperabilidad entre Linux y Windows es un tema de moda debido al acuerdo que,‭ ‬al respecto,‭ ‬anudaron Microsoft y Novell‭ (‬dueña de SUSE Linux‭) ‬y a las olas de quejas y la alarma que dicho acuerdo causó en la comunidad del Software Libre.‭ ‬Ocurre que esta última lo percibió como una jugada a dos puntas por parte de la empresa de Bill:‭ ‬por un lado,‭ ‬birlarse una parte de la torta que ahora se comen las pocas empresas que tienen un negocio importante montado en torno a tecnologías de Software Libre,‭ ‬como la propia Novell o Red Hat.‭ ‬Y por otro,‭ ‬intentar contaminar la plataforma con su propio código propietario,‭ ‬para,‭ ‬más tarde,‭ ‬amenazar con juicios por violación de propiedad intelectual a quienes usen este código‭ “‬contaminado‭”‬,‭ ‬excluyendo a los clientes de Microsoft,‭ ‬por supuesto.‭ ‬Dicha estrategia,‭ ‬conocida internamente en Redmond como‭ “‬E+E+E‭” (‬siglas de‭ “‬embrace,‭ ‬extend,‭ ‬extinguish‭”)‬,‭ ‬es característica de MS,‭ ‬que la ha utilizado múltiples veces para deshacerse de molestos competidores.‭ ‬Lo paradójico del asunto es que uno de los soft en los que se basa esta interoperabilidad entre ambos S.O.‭ ‬está disponible desde hace muchos años,‭ ‬más precisamente desde principios de‭ ‬1992,‭ ‬cuando Andrew Tridgell se armó de un packet sniffer e infinitas dosis de paciencia para desarrollar SAMBA utilizando la técnica de‭ “‬Ingeniería Inversa‭”‬,‭ ‬a partir de los protocolos de red diseñados originalmente por DEC y luego modificados por IBM y Microsoft.

NACE SAMBA:‭ ‬CÓMO Y POR QUÉ
El motivo del nacimiento de SAMBA es común al de tantos otros desarrollos de software:‭ ‬un programador se encuentra con una necesidad que ningún soft satisface plenamente,‭ ‬y decide sencillamente escribir él mismo un programa que cubra su necesidad.‭ ‬Andrew Tridgell,‭ ‬nativo de la tierra de los kiwis y los canguros,‭ ‬necesitaba acceder al disco de un servidor UNIX de su Universidad desde una PC con DOS.‭ ‬Utilizar NFS‭ (‬una solución de software para esa problemática ya existente en ese entonces‭) ‬en su caso no servía,‭ ‬ya que debía utilizar una aplicación que dependía de NetBIOS,‭ ‬una API propietaria de acceso a redes,‭ ‬desarrollada originalmente por IBM y tomada como base por Microsoft para sus productos de networking.‭ ‬Así que Andrew escribió primero un analizador de paquetes,‭ ‬que le permitió hacer un estudio exhaustivo de los paquetes de red y su contenido,‭ ‬con lo cual poco a poco el complejo juego de reglas que da vida a todo protocolo se fue revelando lentamente ante sus ojos.‭ ‬Algo bastante parecido,‭ ‬según las propias palabras de su creador,‭ ‬a intentar aprender a hablar francés simplemente sentándose en un café parisino durante horas,‭ ‬con todos los sentidos atentos a captar y analizar todo cuanto se dice y sucede a nuestro alrededor.‭ ‬Al respecto el propio Tridgell ha escrito un texto muy interesante,‭ ‬cuya lectura recomiendo a todos aquellos interesados en los procesos de ingeniería inversa,‭ ‬y que pueden encontrar aquí‭ (‬lamentablemente restringido para quienes puedan leer el inglés‭)‬.‭

QUÉ OFRECE SAMBA HOY
Como imaginarán,‭ ‬luego de prácticamente‭ ‬15‭ ‬años de desarrollo,‭ ‬y siendo un producto tan popular como lo es actualmente,‭ ‬además de su solidez y estabilidad,‭ ‬SAMBA nos ofrece múltiples posibilidades:

-‭ ‬Acceso a recursos de red‭ (‬servidores de archivos,‭ ‬impresoras,‭ ‬etc.‭)
-‭ ‬Autenticación y Control de Accesos
-‭ ‬Resolución de Nombres
-‭ ‬Publicación de Servicios
‭
Como vemos,‭ ‬es tan completo que hasta permite que un equipo con Linux…‭ ¡‬sea Controlador de Dominio de una red Windows‭! ‬Por supuesto también funciona como un simple miembro del Dominio,‭ ‬ya sea de una red estilo NT o de una basada en Active Directory.‭ ‬Sin embargo,‭ ‬para un uso hogareño en general,‭ ‬es conveniente prescindir del Dominio y utilizar una red del tipo‭ “‬Grupo de Trabajo‭”‬,‭ ‬mucho más sencilla y,‭ ‬por lo tanto,‭ ‬más adecuada para este fin‭; ‬por lo cual en la presente nota veremos cómo trabajar con SAMBA en este tipo de redes.

En este diagrama se muestra una red típica armada alrededor de SAMBA. Se destaca el uso de una utilidad de terceros basada en Web para manejar todo, evitando la tediosa tarea de editar a mano los archivos de configuración. Clickeando la imagen se la puede ver ampliada.

A METER MANO
En nuestro ejemplo vamos a ver un escenario típico para una red hogareña,‭ ‬en donde nos valdremos de SAMBA para facilitar bastante la existencia del siempre sufrido administrador de red‭ (¡‬en este caso es fundamental,‭ ‬ya que seremos nosotros mismos‭!)‬.‭ ‬Contamos con un viejo,‭ ‬pero querido,‭ ‬Pentium MMX‭ ‬166‭ ‬Mhz,‭ ‬con‭ ‬64‭ ‬MB de RAM,‭ ‬que tantas alegrías nos dió en su momento,‭ ‬y que todavía funciona igual de bien que el primer día.‭ ‬Esta veterana PC,‭ ‬equipada con dos placas de red y GNU/Linux instalado,‭ ‬se convierte en un poderoso router,‭ ‬que hace las veces tanto de Gateway,‭ ‬para darle Internet al resto de nuestra red,‭ ‬como de Firewall,‭ ‬para protegernos de posibles ataques desde el exterior.‭ ‬Luego,‭ ‬tenemos una o más estaciones de trabajo‭ (‬y por qué no algún Media Center,‭ ‬para quienes posean bastante plata en el bolsillo para gastar en tecnología‭) ‬que pueden correr tanto Windows como GNU/Linux.‭ ‬Nuestro objetivo:‭ ‬acceder libremente desde cualquiera de las máquinas de la red a los recursos compartidos de las otras,‭ ‬así como a la impresora,‭ ‬conectada indistintamente‭ (‬gracias a la ubicuidad del USB‭) ‬a alguna de las estaciones de trabajo.‭

En principio,‭ ‬privilegiaremos la sencillez sobre la seguridad en la configuración de nuestra red.‭ ‬Al no existir un controlador de dominio,‭ ‬estaremos limitados en cuanto a la funcionalidad de autenticación y autorización.‭ ‬Pero podemos estar tranquilos,‭ ‬ya que nuestro Gateway cuenta con dos placas de red,‭ ‬conformando,‭ ‬de este modo,‭ ‬dos redes no comunicadas entre sí:‭ ‬una,‭ ‬entre nuestro proveedor de Internet y el Gateway,‭ ‬y otra,‭ ‬entre el Gateway y nuestra red hogareña.‭ ‬Sólo se rutearán desde la primera hacia la segunda aquellos paquetes que permitamos en las reglas de nuestro Firewall,‭ ‬y si todo está correctamente configurado,‭ ‬podemos prescindir absolutamente de la seguridad en nuestra red hogareña,‭ ‬dado que,‭ ‬de todas formas,‭ ‬los datos de las estaciones de trabajo estarán a salvo de ataques del exterior.‭ ‬De lo contrario,‭ ‬la configuración de los permisos de acceso a los recursos compartidos,‭ ‬en modalidad‭ “‬grupo de trabajo‭” ‬se vuelve engorrosa,‭ ‬ya que al no estar presente un Domain Controller para autenticar y autorizar,‭ ‬se debe recurrir a triquiñuelas como crear usuarios con el mismo nombre y contraseña en todas las estaciones de trabajo.‭ ‬Por lo tanto,‭ ‬en nuestro ejemplo,‭ ‬permitiremos el acceso total a los recursos compartidos,‭ ‬dejando para notas posteriores configuraciones más complejas que incluyan distintos niveles de seguridad.

Lo primero es instalar SAMBA en todas las PC con GNU/Linux.‭ ‬Los usuarios de Debian‭ (‬o las distros basadas en ella‭) ‬saben que una de las cosas lindas que tiene es que esto se logra en segundos,‭ ‬con sólo escribir‭ ‬apt-get install samba en la consola.‭ ‬Como siempre,‭ ‬a las preguntas que nos realice el instalador responderemos eligiendo la opción por defecto.

Antes de modificar la configuración del SAMBA,‭ ‬debemos realizar algunas tareas previas.‭ ‬Al respecto es bueno recordar que al margen de los permisos‭ “‬de red‭” ‬que otorguemos a los recursos compartidos declarados en SAMBA,‭ ‬los filesystem usados en Linux tienen sus propios permisos,‭ ‬y si,‭ ‬por ejemplo,‭ ‬deseamos escribir en un recurso compartido por SAMBA,‭ ‬el usuario remoto que estemos utilizando debe tener permisos de escritura sobre el directorio respectivo en el filesystem.‭ ‬Para ello crearemos un grupo y un usuario genéricos en el Linux,‭ ‬que serán usados por SAMBA a nuestro pedido.‭ ‬Siguiendo la tradición UNIXera,‭ ‬elegimos el grupo‭ “‬nogroup‭” ‬y el usuario‭ “‬nobody‭”‬,‭ ‬aunque,‭ ‬por supuesto,‭ ‬pueden usar los que quieran,‭ ‬siempre y cuando ajusten correspondientemente la configuración de SAMBA.

Primero,‭ ‬chequeamos si existe el grupo‭ “‬nogroup‭”‬:

Si el grupo ya estaba creado,‭ ‬grep lo mostrará,‭ ‬de lo contrario,‭ ‬no devolverá nada.‭ ‬En ese caso creamos el grupo:

Hacemos lo propio con el usuario,‭ ‬verificando si existe con‭ ‬id:

Si id responde que el usuario no existe,‭ ‬procedemos a su creación,‭ ‬pero omitiendo la creación de un directorio home para el usuario,‭ ‬ya que no será utilizado por ningún usuario‭ “‬real‭”‬:‭

Ahora sí,‭ ‬llegó el momento de abrir el editor de texto favorito de cada uno y modificar la configuración del SAMBA.‭ ‬Como buen Debianero,‭ ‬yo estoy acostumbrado al NANO:

Vamos a encontrarnos con un‭ *‬gran‭* ‬archivo de configuración,‭ ‬que supera las‭ ‬300‭ ‬líneas,‭ ‬pero a no asustarse,‭ ‬ya que muchas de estas líneas contienen ayudas e indicaciones acerca de las distintas opciones de configuración.‭ ‬No es mala idea,‭ ‬antes de cada modificación,‭ ‬hacer una copia de resguardo de este archivo.‭ ‬Un error en la sintaxis del mismo impedirá que se levante el servicio y SAMBA no funcionará.‭

Antes que nada,‭ ‬vamos derechito a la sección‭ “‬Global Settings‭” ‬y configuramos los siguientes valores:

Acá pueden poner el que deseen,‭ ‬con la salvedad de que deberá ser el mismo en todas las máquinas.‭ ‬Por lo general,‭ ‬por defecto se utiliza GRUPO_TRABAJO.‭ ‬Un poco más abajo está la configuración de‭ “‬Networking‭”‬.‭ ‬Aquí deberemos hacer una modificación MUY importante si la máquina que estamos configurando es el Gateway,‭ ‬ya que si omitimos este paso,‭ ‬expondremos nuestros recursos compartidos a toda la Internet‭ (!)‬.‭ ‬Como ya mencionamos,‭ ‬el gw tiene dos placas de red:‭ ‬una‭ (‬en nuestro caso eth0‭) ‬que la conecta con el ISP,‭ ‬y otra con el resto de la red hogareña‭ (‬eth1‭)‬.‭ ‬Así que,‭ ‬en este caso,‭ ‬nos aseguraremos de que quede comentada‭ (‬con‭ “;”) ‬la línea que activa la interfaz eth0‭ ‬en la configuración de SAMBA,‭ ‬y que la que corresponde a eth1‭ ‬quede correctamente configurada.‭ ‬En nuestro ejemplo quedó así:

Para cada placa,‭ ‬además del nombre de la interfaz‭ (‬ethX‭)‬,‭ ‬deben configurar correctamente el segmento de red y la máscara en forma acorde a la red correspondiente‭ (‬si la IP de la PC se asigna en forma dinámica,‭ ‬dejamos‭ ‬127.0.0.0/8‭)‬.‭ ‬Para las estaciones de trabajo,‭ ‬en las que,‭ ‬por lo común,‭ ‬contamos con una sola NIC‭ (‬eth0‭)‬,‭ ‬no hay margen de duda,‭ ‬ya que se configura la única interfaz existente.

Luego,‭ ‬nos dirigimos a la parte de‭ “‬Authentication‭”‬,‭ ‬donde indicaremos a SAMBA que la seguridad se manejará a nivel de recurso,‭ ‬y no de usuario:

Al final de la sección de autenticación agregaremos varias líneas.‭ ‬Con la primera de ellas indicaremos el usuario que SAMBA usará como‭ “‬guest‭” (‬es decir,‭ ‬el utilizado cuando se conecte un usuario remoto que no posee una cuenta local con la que ser autenticado‭)‬:

Recuerden configurar esta opción en forma acorde si han creado el usuario con otro nombre.‭ ‬Luego,‭ ‬agregamos las siguientes líneas a continuación:

Si desean evitar que se pueda escribir en los recursos compartidos por SAMBA,‭ ‬deberán poner en‭ “‬yes‭” ‬el valor de la propiedad‭ “‬read only‭”‬.‭ ‬Este valor,‭ ‬que es general para todos los recursos,‭ ‬sólo se tiene en cuenta,‭ ‬en cada caso,‭ ‬si no se ha declarado de manera explícita a nivel de recurso.

Pero,‭ ‬justamente,‭ ‬pasemos a la configuración de los recursos compartidos.‭ ‬En este caso,‭ ‬y como ejemplo,‭ ‬crearemos un único recurso habilitado para acceso total de lectura y escritura en el directorio‭ ‬/shared del filesystem.‭ ‬Vamos a la sección‭ “‬Share Definitions‭” ‬del archivo de configuración y,‭ ‬debajo de todos los recursos de ejemplo que vienen en el archivo‭ (‬algunos de los cuales son muy útiles,‭ ‬como,‭ ‬por ejemplo,‭ ‬el del CD-ROM y los de impresión‭)‬,‭ ‬declaramos nuestro recurso agregando las siguientes líneas:

Como ven,‭ ‬las propiedades del recurso son bastante autoexplicativas y,‭ ‬aunque parezca redundante declarar‭ “‬writeable‭ = ‬yes‭” ‬y‭ “‬read only‭ = ‬no‭” ‬al mismo tiempo,‭ ‬les aconsejo hacerlo de todas formas y se evitarán más de un dolor de cabeza.

Antes de poder probar si quedó todo bien,‭ ‬debemos reiniciar el SAMBA para que tome los cambios en el archivo de configuración.‭ ‬En Debian lo logramos con este comando:

Ahora,‭ ‬desde la estación de trabajo que corre Win XP,‭ ‬simplemente ingresamos en la barra de direcciones del explorador de Windows:

Y,‭ ‬luego de algunos segundos‭ (‬al no haber un controlador de dominio,‭ ‬se envía un request a TODOS los equipos de la red,‭ ‬lo cual demora un poco las cosas‭)‬,‭ ‬tendremos una ventana de explorador situada en el recurso creado.‭ ‬Verificamos que hemos hecho las cosas bien mediante la copia de cualquier archivo a nuestro recurso,‭ ‬y,‭ ‬si funciona correctamente,‭ ‬ya podemos dar las primeras hurras.‭ ‬Si vamos a usar en forma intensiva el recurso desde esta estación de trabajo,‭ ‬es buena idea mapearlo como una unidad,‭ ‬lo cual es posible yendo en el explorador al menú Herramientas\Conectar a Unidad de red,‭ ‬seleccionando la unidad a la que se quiere mapear el recurso,‭ ‬e ingresando la dirección del mismo como lo hicimos antes.‭ ‬Es mejor elegir una letra alta,‭ ‬alejada de las unidades de discos locales como C,‭ ‬D,‭ ‬etc.‭ ‬Una elección popular entre los administradores de redes es la unidad R.

SAMBA COMO CLIENTE
Para acceder desde una de las máquinas con Linux a recursos compartidos en otras máquinas,‭ ‬disponemos de varias alternativas.‭ ‬La más cómoda es utilizando el navegador Nautilus‭ (‬que viene con el Gnome‭)‬,‭ ‬en cuyo caso es casi igual que en Windows,‭ ‬ya que basta escribir en la barra de direcciones:

También se puede montar el recurso en un directorio,‭ ‬mediante el comando smbmount:

Y,‭ ‬luego,‭ ‬desmontamos con smbumount al finalizar la utilización del recurso.‭ ‬Si queremos realizar los mounts en forma automática al bootear,‭ ‬se puede hacer agregándolos a‭ ‬/etc/fstab:

Para navegar por los recursos de un equipo remoto desde la consola,‭ ‬tenemos el comando smbclient:

…‭ ‬Y A SEGUIR INVESTIGANDO
Como podemos apreciar,‭ ‬las posibilidades son tantas como la imaginación lo permita,‭ ‬y por cierto,‭ ‬que queda mucho por ver sobre el tema.‭ ‬Por ejemplo,‭ ‬cómo configurar SAMBA para utilizarlo como controlador de dominio,‭ ‬ideal para una pequeña o mediana empresa.‭ ‬En próximos números‭ ‬esperamos‭ ‬poder desarrollar este tema.‭ ‬De todas maneras,‭ ‬esperamos haberles brindado los fundamentos necesarios como para que‭ ‬puedan proseguir por sí mismos,‭ ‬ya que nunca debemos olvidar que‭ “‬la práctica hace al maestro‭”‬.‭ ‬Hasta la próxima,‭ ‬y‭ ¡‬sigan hackeando‭!

En esta foto,‭ ‬tomada hace ya cinco años,‭ ‬vemos al equipo de desarrollo de SAMBA en ese entonces.‭ ‬Ahora entendemos de dónde salieron las‭ ‬500.000‭ ‬líneas de código que tiene actualmente‭ ‬:‭))

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