Por Víctor Manuel Martínez Martínez (vicm3)
Presentación del problema:
1) Como hacer disponibles a usuarios externos a nuestra LAN, archivos muy grandes,
en este caso películas de Anime, para casos prácticos mas específicos,
imágenes ISO de Linux, OpenOffice y cosas similares, varios puntos a
considerar:
a. El ancho de banda de la UPN es de 2Mbits, por lo tanto es finito.
b. Red Hat (y varias distribuciones mas) trae por defecto Wu-ftpd (conocido
por adolecer de un diseño enfocado a seguridad y al menos en lo personal
por tener demasiados y no muy bien documentados archivos de configuración)
c. Inexistente conocimiento de SMNP
d. Necesidad de una solución rápida (aunque tal vez no elegante)
Antecedentes:
1) Lo primero fue cambiar el wu-ftpd por un demonio de ftp mas robusto, la
elección por facilidad de configuración Proftpd (www.proftpd.org)
y por su vitalidad en cuanto a desarrollo y orientación a seguridad.
2) El trafico en la universidad de 9pm a 8am es (era) prácticamente nulo
o realmente poco, por lo tanto se planteo la opción de en ese horario
colocar el ftp.
a. Primer problema... tal cual se había predicho el trafico por la
noche era muy bajo, pero al poner el ftp en actividad, el enlace se saturo y
se cayo dejándonos un viernes fuera de línea. Lo cual a de entrada
nos dejaba con las siguientes opciones:
i. Limitar la cantidad de usuarios (ineficientes, puesto que aun dejando un
solo usuario, si este tiene un ancho de banda mayor al nuestro, nos satura...)
ii. Limitar el ancho de banda usado por el ftp, dando una búsqueda en
google, lo primero que se encontró, fue el iproute2 del Kernel 2.4.x,
y en el mejor de los casos el CBQ (Class Based Queueing) junto con un script
para usarlo CBQ.init, sin embargo leyendo la información en el How-to,
se metía en conceptos que quien escribe no terminaba de comprender, ni
tenia el tiempo en ese momento para aprender, además de que la filosofía
de control de trafico basado en colas (queueing) tenia una teorización
larga y lo que se necesitaba era una solución rápida....
Solución:
1) Limitar el numero de usuarios en el ftp (configuración). Para limitar
el ancho de banda se encontró un modulo que se puede insertar al kernel
en caliente, por lo tanto sin demasiada necesidad de modificación, ni
de configuración, este modulo se llama rshapper (actualmente limitado
su desarrollo). A continuación lo que dice freshmeat al respecto:
rshaper
by Alessandro Rubini - Monday, November 1st 1999 13:50 PST
About:
rshaper is a Linux kernel module that limits the incoming bandwidth for packets
aimed at different hosts ("incoming" meaning traffic that enters the
shaping host; if that host is a gateway between target hosts and the rest of
the Internet, all the traffic of the target hosts will be shapeable). It's useful
for ISPs who offer housing and want to differentiate their offers and for limiting
download bandwidth from students' boxes or similar setups. It works with versions
2.0, 2.2, and 2.4 of the kernel; with 2.4 it can also shape outgoing traffic.
2) Esto ultimo fue lo que mas llamo la atención, puesto que al poder
dar forma al trafico saliente, pues se podría limitar la cantidad de
ancho de banda de uso del ftp
a. Requisitos necesarios: 1) Fuentes del kernel (o de menos los headers) 2)
acceso súper usuario (lsmod, insmod) 3) compilador ANSI de C (gcc)
b. Una vez compilado dependiendo de la forma en que se inserta el modulo insmod
rshaper.o mode=x donde x es igual al modo en el que se va a usar, 0 saliente
(outgoing), 1 entrante (incoming, esta es la opción asumida si no se
especifica una), 2 ambos (no aconsejable si la maquina que va a hacer de router,
interesante si va a limitar el trafico de y hacia maquinas internas)
c. Mas aun lo mas útil de esta herramienta en comparación con
el CBQ es que permite definir rangos de ips para manejar su consumo de ancho
de banda, provee de un binario rshaperctl [ip o red]\[Submascara de red]
Velocidad -en bytes por segundo- (tiempo máximo de colocación
en la cola)
Es decir que un rshaperctl 200.63.141/24 10240 10
Colocaría a todo dialup de prodigy (dup-200-66-151-15.prodigy.net.mx),
es decir 200.266.151.0-255 a bajar con un máximo de 10KB por segundo
y en caso de pasarse colocarlos en cola mientras esta no exceda de 10segundos
(si se omite el parámetro se toma por defecto 5 segundos), si se usa
rshaperctl sin argumentos retorna la configuración actual, para quitar
las limitaciones a una ip simplemente se le da rshaperctl ip 0 (finalmente dejamos
10 usuarios consumiendo un total máximo de 500kbs, pero vía el
demonio de ftp ).
d. Por hacer: construir un script que revise quien esta haciendo ftp /var/log/xferlog
y lo añada a la lista de restricciones. Probarlo como un método
para implementar QOS (Quality Of Service), aunque para esto es mas útil
el CQB.
3) Como se menciono anteriormente, por desconocimiento de SNMP y mas aun por que el mrtg no entrega las estadísticas como se necesitaban (además de hacerlo continuamente y no en demanda, consumiendo bastante cpu) se busco una opción para monitorear que no requiriera de SNMP, la mas agradable tanto visualmente, como por las capacidades de presentación de información fue el ifmonitor (http://ifmonitor.preteritoimperfeito.com/) -php+mysql- que lo que hace es llevar un conteo de lo que pasa por eth0 (o la interfase que se le indique, vía /proc/net) un ejemplo lo tenemos en http://janus.ajusco.upn.mx/web y http://linux.ajusco.upn.mx, esta es una solucion rapida a llevar el uso de ancho de banda.
4) Por hacer: Monitorear el uso de ancho de banda de mas hosts, posible solucion
ntop, como nuestra red utiliza switches y no hubs... hace mas complicado el
obtener los datos. Otra posible solución se encuentra en el SNMP
Conclusión:
1) ¡Leer siempre el FAQ! El proftpd tenia la opción de limitar
el ancho de banda tanto para upload como para download, de haber leído
un poco la documentación del demonio de ftp no habria existido la necesidad
de meterse tanto en rollos del kernel manejo de trafico y monitoreo (en el proceso
hasta se utilizo el pure-ftpd por su poco uso de cpu, seguridad y por que en
las características enfatizaba la posibilidad de manejar el ancho de
banda utilizado tanto para upload como para donwload, también por que
no requiere de archivo de configuración, todo se coloca en la línea
de comando).
2) La serie del kernel 2.4 tiene muchas características interesantes para implementar calidad de servicio (QOS), que aun no hemos explorado y que pudieran ser parte de la solución a los cuellos de botella que se generan, ya sea a través del filtrado o con la limitación de consumo (de ancho de banda) de los programas P2P (peer to peer) durante el horario de labores.
Bibliografía:
Como Limitar ancho de Banda
http://mural.uv.es/~joferna/doc/Limitar-ancho-de-banda-COMO/html/index.html
TRAFFIC SHAPER BIDIRECCIONAL Mini-Howto
http://documentos.glo.org.mx/?HOWTO=tshapper
Linux Advanced Routing & Traffic Control HOWTO
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/index.html
Chapter 9. Queueing Disciplines for Bandwidth Management
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.html
The famous CBQ qdisc
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.classful.html#AEN735
CBQ.init
https://sourceforge.net/projects/cbqinit
Bandwidth Limiting HOWTO
http://www.tldp.org/HOWTO/Bandwidth-Limiting-HOWTO/index.html
Readme de rshaper
http://janus.ajusco.upn.mx/rshaper.txt
Rshaper en Freshmeat
http://freshmeat.net/projects/rshaper/?topic_id=87