El servidor proxy requiere software adicional. Éste se puede conseguir en:
ftp://sunsite.unc.edu/pub/LiNUX/system/Network/misc/socks-Linux-src.tgz
Solamente hay un ejemplo de fichero de configuración en ese directorio, se
llama "socks-conf". Debemos descomprimir y desempaquetar los
ficheros en un directorio de nuestro ordenador, y seguir las instrucciones
de cómo compilarlo. Yo tuve un par de problemas compilándolo. Hay que
asegurarse de que los Makefiles son correctos. Algunos lo son y algunos
no.
Algo importante que hay que advertir es que hay que añadir el servidor
proxy al /etc/inetd.conf. Se debe añadir la linea:
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
para decir a inetd que arranque el servidor cuando se le pida.
El programa socks necesita dos ficheros de configuración distintos.
Uno en el que se le dice qué accesos están permitidos, y otro para dirigir
las peticiones al servidor proxy apropiado. El fichero de control de
acceso debe residir en el servidor. El fichero de rutado debe residir en
todas las máquinas Ún*x. Las máquinas DOS y, presumiblemente, las
Macintosh encaminarán por sí mismas.
Con socks4.2 Beta, el fichero de acceso se llama "sockd.conf".
Debería contener dos tipos de líneas: las de permiso, que contienen
"permit" y las de prohibición, que contienen "deny". Cada linea tendrá
tres palabras:
El identificador es o permit (permitir) o deny (denegar). Debería haber uno de cada.
La dirección IP se compone de cuatro octetos según la típica notación de puntos: p.ej. 192.168.2.0 .
El modificador de dirección es también un número de cuatro octetos. Funciona como una máscara de red. Hay que verlo como 32 bits (unos o ceros). Si el bit es uno, el bit correspondiente de la dirección que se comprueba debe coincidir con el bit correspondiente del campo de dirección IP.
Por ejemplo, si la línea es:
permit 192.168.2.23 255.255.255.255
entonces, admitirá sólo direcciones IP en las que coincidan todos los bits de 193.168.2.23, esto es, sólo ella misma. La línea:
permit 192.168.2.0 255.255.255.0
admitirá todas las direcciones desde la 192.168.2.0 hasta la 192.168.2.255, la subred de clase C completa. No se debería tener la línea:
permit 192.168.2.0 0.0.0.0
dado que permitiría cualquier dirección.
Así que, primero, permitimos todas las direcciones que queramos permitir, y después prohibimos el resto. Para permitir a cualquiera del rango 192.168.2.xxx, las líneas:
permit 192.168.2.0 255.255.255.0
deny 0.0.0.0 0.0.0.0
funcionarán perfectamente. Observa los primeros "0.0.0.0" en la
linea de prohibición. Con un modificador de 0.0.0.0, el campo de la
dirección IP no importa. Se suele poner todo ceros porque es fácil de
teclear.
Se puede poner más de una línea de cada clase.
También se puede autorizar o denegar el acceso a determinados usuarios. Se consigue gracias a la autentificación del protocolo ident. No todos los sistemas soportan ident (incluyendo al Trumpet Winsock) de modo que no profundizaré en ello. La documentación que viene con socks trata este tema adecuadamente.
El fichero de rutado de socks tiene el desafortunado nombre de "socks.conf". Y digo que es desafortunado porque se parece tanto al del fichero de control de acceso que es fácil confundirlos.
El fichero de rutado tiene la función de decir a los clientes de socks cuándo usar socks y cuándo no. Por ejemplo, en nuestra red la máquina 192.168.2.3 no necesita usar socks para comunicarse con la 192.168.2.1 (el cortafuegos), ya que tiene una conexión directa vía Ethernet. La 127.0.0.1, dirección de "vuelta atrás" (que representa a una máquina ante ella misma), está definida automáticamente. Está claro que no se necesita usar socks para hablar con uno mismo.
Hay tres tipos de entradas:
Deny (denegar) le dice a socks que peticiones debe rechazar. Esta entrada
tiene los mismos tres campos que en sockd.conf, identificador,
dirección, y modificador. Generalmente, dado que esto también es manejado
por el fichero de control de acceso sockd.conf, el modificador se
pone a 0.0.0.0 . Si uno quiere impedirse a si mismo conectar con un
determinado sitio, se puede hacer poniéndolo aquí.
La entrada direct dice para qué direcciones no se debe usar
socks. Éstas son todas las direcciones a las que se puede llegar sin usar
el servidor proxy. De nuevo hay tres campos: identificador, dirección, y
modificador. Nuestro ejemplo tendría:
direct 192.168.2.0 255.255.255.0
Con lo que iría directamente a cualquier máquina de la red protegida.
La entrada sockd dice cuál es la máquina en la que corre el servidor
de socks. La sintaxis es:
sockd @=<lista de servidores> <direccion IP> <modificador>
Observemos la entrada @=. Ésta permite poner las direcciones IP de
una lista de servidores proxy. En nuestro ejemplo sólo usamos un servidor
proxy, pero se puede tener muchos para admitir una carga mayor y conseguir
redundancia frente a fallos.
La dirección IP y el modificador funcionan como en los otros ejemplos. Especifican a qué direcciones se va a través de los servidores.
Instalar un Servicio de Nombres detrás de un cortafuegos es relativamente simple. No hay más que instalar el servidor de DNS en la máquina que hace de cortafuegos. Luego se hace que todas las máquinas tras el cortafuegos usen este servidor de DNS.
El Trumpet Winsock lleva incorporada la gestión de servidores proxy. En el menú "setup" se debe poner la dirección IP del servidor y las direcciones de todos los ordenadores a los que se llega directamente. Él se encargará a partir de entonces de todos los paquetes de salida.
El paquete socks sólo funciona con TCP, no con UDP. Esto le quita un poco de utilidad. Muchos programas interesantes, (como talk o archie) usan UDP. Existe un paquete diseñado para funcionar como un servidor proxy para paquetes de UDP que se llama UDPrelay. El autor es Tom Fitzgerald fitz@wang.com. Desgraciadamente, en el momento de escribir estas líneas, no es compatible con LiNUX.
Un servidor proxy es ante todo un dispositivo de seguridad. Usarlo para aumentar el número de máquinas con acceso a la Internet cuando se tienen pocas direcciones IP tiene muchos inconvenientes. Un servidor proxy permite un mayor acceso desde dentro de la red protegida al exterior, pero mantiene el interior completamente inaccesible desde el exterior. Esto significa que no habrá conexiones archie, ni talk, ni envío directo de correo a los ordenadores de dentro. Estos inconvenientes pueden parecer pequeños, pero consideremos los siguientes casos:
cortafuegos primero,
pero como todo el mundo tiene acceso al exterior gracias al servidor
proxy, no te han abierto cuenta en él.
El FTP crea otro problema con los servidores proxy. Cuando se hace un
ls, o un get, el servidor de FTP establece una conexión
con la máquina cliente y manda la información por ella. Un servidor proxy
no lo permitirá, así que el FTP no funciona especialmente bien.
Además, un servidor proxy es lento. Debido a la gran sobrecarga, casi cualquier otro medio de lograr acceso será más rápido.
Resumiendo, si tienes suficientes direcciones IP y no te preocupa la seguridad, no uses cortafuegos ni servidores proxy. Si no tienes suficientes direcciones IP, pero tampoco te preocupa la seguridad, seguramente deberías considerar los "emuladores de IP" como Term, Slirp, o TIA.
Term se puede conseguir en
ftp://sunsite.unc.edu, Slirp en
ftp://blitzen.canberra.edu.au/pub/slirp, y TIA en
ftp://marketplace.com.
Van más rápido, permiten mejores conexiones, y proveen un mayor nivel de acceso a la red interior desde la Internet. Los servidores proxy están bien para las redes que tienen muchos ordenadores que quieren conectar con la Internet al vuelo, y en las que se quiere poco trabajo de mantenimiento tras la instalación.