[ Introducción ] [
Caso-Estudio
] [ Instalación ] [ Configuración
base ] [ Alias ] [ NAT
] [ Reglas ] [ DNS ] [ DHCP
] [ Caudal ] [ OpenVPN
] [ Portal ]
[ OpenVPN sin DHCP
] [ spamd ]
Objetivos
Balanceo de carga de las ADSL
Las comunicaciones peer-to-peer (P2P)
FTP-Proxy Helper
DMZ (zona desmilitarizada)
Estados y diagnósticos
Aislar física y lógicamente las redes dedicadas a servidores, profesorado, alumnos i sin hilos (wireless). Seguridad de dentro a dentro.
Regular las comunicaciones entre las distintas redes locales y de las redes locales a Internet. Seguridad de dentro a dentro y de dentro a afuera.
Aprovechar el caudal de las tres ADSL de que se dispone, a poder ser de forma automática. Balanceo de carga.
Aumentar la seguridad en los servicios que tenemos en Internet. Seguridad de afuera a dentro.
Poder tener una red sin hilos (wireless) abierta.
Utilizar una solución abierta, de código libre.
Utilizar un hardware de tamaño reducido, integrable en el armario de comunicaciones.
Utilizar un hardware no basado en disco duro, que no requiera protección con un SAI de apagado y puesta en marcha automáticos.
Poder configurar todos los dispositivos de la red (ordenadores, impresoras, puntos de acceso, ...) mediante DHCP estático, es decir, asignándoles una dirección IP en función de su dirección MAC.
Control del uso de aplicaciones P2P.
Estandarizar y automatizar la configuración de los navegadores en lo que se refiere al uso de servidores intermediarios (proxy) y la configuración de red de todas las máquinas.
Esquemáticamente, el montaje ha quedado tal como muestra la figura (observa que tienen que haber seis redes diferenciadas AAA, BBB, CCC, XXX, YYY i ZZZ):
Prácticamente todos los objetivos han sido sobradamente logrados, fuera de algunas limitaciones que se han encontrado. pfSense tiene muchas funcionalidades, pero hay que tener en cuenta que algunas son incompatibles entre ellas. Y, por tanto, hay que escoger cuál es la mejor opción. Se explican a continuación las decisiones adoptadas.
pfSense permite balanceo de carga con detección de fallo (fail-over), lo que resulta muy interesante si se tiene más de una ADSL. Esta prestación permite pues equilibrar las cargas de las ADSL y en caso de fallo de una de ellas redireccionar su tráfico hacia otra.
pfSense emplea para el balanceo el demonio (daemon) slbd. Como la mayoría de balanceadores, su intención es mejorar la navegación por Internet y no entiende las conexiones múltiples. Ello descarta su uso en accesos FTP. Por tanto, o se renuncia a balanceo o se renuncia a FTP. O bien se monta otro pfSense sólo para FTP. Se decidió renunciar al balanceo.
El balanceo se configura definiendo una pila (pool) donde se indica la IP pública de cada ADSL (IP a monitorizar) y la IP privada por la que se accede a la ADSL. Entonces pfSense comprueba periódicamente si la ADSL en cuestión está funcionando, haciéndole un ping. Se necesita, por tanto, que la IP pública de la ADSL conteste a estos ping internos. De lo contrario, pfSense no sabrá ver si la ADSL está activa.
Las comunicaciones peer-to-peer (P2P)
Otro de los quebraderos de cabeza de los administradores de red son las descargas indiscriminadas empleando programas como Emule o Ares: ocupación del ancho de banda, problemas de seguridad, ilegalidad, ...
Una solución drástica es hacer que las conexiones a Internet estén permitidas sólo hacia los puertos (servicios) más usuales (80, 443, 21, 53, 119, ...) En http://www.iana.org/assignments/port-numbers encontrarás la lista oficial de puertos.
La otra solución es emplear el regulador de caudal (traffic shaper) ALTQ que tiene pfSense y poner los accesos P2P en la cola de prioridades. Es una solución que requiere un cierto ajuste, pero es la más recomendable. Actualmente tiene la limitación que sólo se puede emplear ALTQ entre una de las LAN y una de las WAN del cortafuegos (es decir, ALTQ en pfSense no es multiWAN, pero se está trabajando para que lo sea ...)
En todo caso, tanto si se emplea una solución como otra, tiene que entrar en juego otra prestación de pfSense: FTP-Proxy Helper.
Se trata de una funcionalidad de Packet Filter (PF), que permite que la propia máquina (127.0.0.1) haga de intermediario (proxy) para las conexiones FTP. De esta manera queda obviado el problema de que un cliente FTP opere con el servidor no sólo por el puerto 21 si no también con un puerto dinámico, que está por encima del 1023 y que se confunde a la vez con un acceso P2P.
Desgraciadamente FTP-Proxy Helper tampoco es multiWAN, lo que se traduce en que siempre sale/entra por la puerta de enlace por defecto que tenga nuestro pfSense. Es por ello que en el esquema anterior se puede ver que sólo ha sido activado para la red Alumnes, al igual que ALTQ.
Si tienes más curiosidad a cerca de cómo funciona FTP-Proxy Helper visita http://www.openbsd.org/faq/pf/ftp.html#client
En el esquema de más arriba se puede ver que no hay una DMZ (zona desmilitarizada) propiamente dicha. Se ha renunciado a ella porqué implicaba un profundo cambio en la estructura de servidores, se necesitaba una séptima tarjeta de red en el cortafuegos y otro concentrador de red (switch) para la DMZ. A pesar de que no tener una DMZ no es una situación ideal, la adopción de pfSense con la estructura propuesta es, sin duda, un importante aumento de seguridad.
pfSense tiene toda una serie de herramientas que permiten ver con todo detalle qué está pasando o qué ha pasado. Estado de las conexiones, gráficos del uso de cada interfase (históricos y en tiempo real), herramientas de diagnóstico, ... El administrador de red tiene pues con pfSense las herramientas necesarias para poder tomar decisiones sobre el tráfico de su red.
Autor: Josep
Pujadas i Jubany
© 2007. Todos los derechos reservados