¿Cómo puedo limitar el ancho de banda por usuario?


32

Para resumir: tengo un servidor dedicado con algunos amigos que ejecutan un cliente torrent con interfaz gráfica de usuario web. Cada usuario ejecuta un cliente con su nombre de usuario en el servidor, por lo que las descargas van en su directorio de usuario, y solo ellos tienen acceso a sus propios archivos, etc.

¿Cómo puedo monitorear y limitar el ancho de banda por mes por usuario?

Estaba pensando que tal vez debería haber una forma de usar iptables. Y al monitorear el ancho de banda utilizado por todos los procesos del usuario X. Y si han usado más de su ancho de banda mensual permitido de Y GB, reciben un mensaje que dice que las redes se bloquean para su cliente torrent o el cliente se mata por completo. También pensé en el calamar, pero dado que usaría múltiples clientes torrent, esto podría usar muchos recursos del servidor ...

Estoy usando Debian Lenny.

No estoy seguro de cómo hacer esto ...

¿Sería esto posible? Estoy agradecido incluso por soluciones parciales a esto ...


Podríamos saber qué sistema operativo está utilizando.
Sam Cogan

debian Agregado en una edición.
loco41211

por curiosidad, ¿estás usando TorrentFlux?
cop1152

Es una de las cosas que estoy intentando. En este momento estamos buscando cualquier cosa que pueda usar para una caja de semillas con limitación de espacio en disco (para la que tenemos una solución) y limitación de ancho de banda en la que estamos atascados ... y algunos de mis amigos usan alrededor de 1 TB al mes, mientras que otros solo unos pocos Mbs. Realmente me gustaría limitar esto por usuario por igual.
loco41211

Respuestas:


13

Puede usar el comando de modelado de tráfico 'tc'.

Dele a cada uno de sus amigos un puerto diferente para usar para BitTorrent. Marque los paquetes TCP con iptables para cada puerto.

iptables -t mangle -A FORWARD -p tcp --sport 6881 -j MARK --set-mark 100
iptables -t mangle -A FORWARD -p tcp --dport 6881 -j MARK --set-mark 100

Luego, use el comando tc para establecer el ancho de banda y la velocidad máximos para cada usuario.

Al final del mes, puede eliminar y agregar los comandos 'tc' para restablecer los recuentos.

Puede controlar el uso de cada usuario de la siguiente manera:

tc filter show dev ethX

Si está utilizando Debian install shorewall, hace que sea realmente fácil modelar el tráfico sin meterse con iptables. Simplemente edite tcdevices, tcclasses y tcrules en el directorio / etc / shorewall. Más información aquí: http://www.shorewall.net/traffic_shaping.htm

Como sugirió la otra persona, marcar los paquetes por nombre de usuario es probablemente mejor que por puerto, de esa manera los puertos se pueden cambiar sin actualizar iptables.


¿podría dar un ejemplo sobre cómo establecer un límite? ¿Digamos 100 GB entrantes y salientes juntos?
loco41211

torrent puede (y en realidad lo es) usar otros puertos, por lo que el ejemplo realmente no resuelve el problema
cstamas

que elimina esas dos opciones como una solución ...
loco41211

cstamas: puede configurar un puerto o múltiples puertos cuando usa un cliente bittorrent. mira esto: dessent.net/btfaq/#ports
chris.moos

13

Puede intentar usar la --quotaopción en iptables, que le permite establecer un límite de transferencia en bytes. Como está ejecutando múltiples clientes torrent, cada uno con un nombre de usuario diferente, puede combinarlo con la --uid-owneropción, como sugirió katriel.

De esta manera, podría aplicar un límite de transferencia por período de tiempo (día / semana / mes / etc.) sin tener que limitar la velocidad de descarga de sus usuarios.

Para que los contadores de paquetes sean persistentes, deberá guardarlos periódicamente (por ejemplo, a través de un trabajo cron), de modo que pueda restaurarlos en caso de que necesite reiniciar el servidor o eliminar las reglas del firewall.


Eso suena como que funcionaría. Entonces, con la ayuda de iptables, puedo marcar todo el tráfico que entra y sale para un usuario establecido. Y puedo limitarlo por un período de tiempo establecido. Sin embargo, todavía no puedo entender cómo será toda la configuración. Entonces, ¿cuál es el comando exacto que podría usar para marcar el tráfico entrante y saliente: "iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner someuser -j MARK --set-mark 100"? ¿O cómo lo haría? ¿Cuál sería, por ejemplo, el comando para marcar el nombre de usuario bob con id 56 con un límite mensual de 100 GB? ¿Supongo que un trabajo cron mensual restablecería el contador de tráfico?
loco41211

12

Solo para agregar a la pregunta anterior.

Puede usar iptables con coincidencia de usuario para colorear los paquetes de esta manera:

iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner someuser -j MARK --set-mark 100

Y luego use 'tc' para limitar por usuario.


¿Podría dar un ejemplo sobre cómo usar tc para establecer un límite de, digamos, 100GB para el nombre de usuario blablaX? ¿Y un ejemplo del código que debería usarse para restablecer el límite después de un mes? Gracias
loco41211

Esto limitará al usuario de forma permanente y no con una cuota programada
katriel

8

Según la cantidad de tráfico mensual que desea permitir a cada usuario por mes, puede establecer un límite de ancho de banda en consecuencia, utilizando algunas de las herramientas sugeridas por los otros usuarios.

Por ejemplo, supongamos que desea establecer un límite máximo de descarga de 250 GB / mes . Ahora, si divide eso por la cantidad de horas en un mes (~ 730), y luego por 3600, obtendría la velocidad máxima de descarga, que en este ejemplo sería de unos 100 KB / s .

Luego, si establece una velocidad máxima de DL de 100 KB / s, automáticamente aplicaría su límite de descarga de 250 GB / mes (suponiendo, por supuesto, que su moderador de tráfico funciona correctamente). Si sus usuarios no pueden descargar más rápido que 100 KB / s, entonces no podrán descargar más de 250 GB / mes.

Para limitar la velocidad de descarga que podría usar tco algunas de las otras herramientas que se han mencionado. Si no desea tratar directamente tc, puede usar cbq.init , que es bastante simple de configurar. Este script estaba presente en Debian Etch como el shaperpaquete, pero parece que se eliminó después de eso. De todos modos, es solo un script simple que puedes descargar de SourceForge.

Por supuesto, este enfoque podría no ser útil en su caso (por ejemplo, si quisiera que sus usuarios pudieran descargar a la velocidad máxima disponible pero aún así imponer su límite mensual, mi sugerencia no funcionaría).


La razón principal que usamos un seedbox en su lugar sólo torrentes en nuestro PC, ya que es mucho más rápido, así que por desgracia esto no resuelve el problema ... Gracias de todos modos
loco41211

7

Sé que esta es una publicación antigua, pero incluso hoy me topé con ella buscando respuestas y finalmente pude armar algo que funciona perfectamente para mí. Tengo un enlace descendente de 25Mbs y un enlace ascendente de 2.5Mbs y hay 4 personas y 5 servidores que comparten este enlace. con servidores, el ancho de banda del enlace ascendente es crítico, pero el enlace descendente es útil con 4 personas, por lo que nadie lo acapara todo.

Estoy ejecutando centos 6.3 como enrutador, pero estos comandos deberían funcionar en cualquier Linux. eth0 es mi enlace ascendente al proveedor eth1 es mi lan a través de un conmutador de 24 puertos y un punto de acceso wifi. Limito las descargas a 5 de los 25 Mbs (aproximadamente 500 KB / seg.). Limito las cargas a 200 Kb. (aproximadamente 25 KB / seg.)

tc qdisc add dev eth0 root handle 1:0 htb default 99
tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100Mbit ceil 100Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 200Kbit ceil 200Kbit prio 2
tc qdisc add dev eth0 parent 1:11 handle 10: sfq perturb 10

tc qdisc add dev eth1 root handle 2:0 htb default 99
tc class add dev eth1 parent 2:0 classid 2:1 htb rate 100Mbit ceil 100Mbit
tc class add dev eth1 parent 2:1 classid 2:11 htb rate 5Mbit ceil 5Mbit prio 2
tc qdisc add dev eth1 parent 2:11 handle 20: sfq perturb 10

luego, para limitar los usuarios, usa 2 líneas de iptables por usuario

para limitar las cargas:

iptables -t mangle -A POSTROUTING -o eth0 -p tcp -s 192.168.0.100 -j CLASSIFY --set-class 1:11

para limitar las descargas

iptables -t mangle -A POSTROUTING -o eth1 -p tcp -d 192.168.0.100 -j CLASSIFY --set-class 2:11

simplemente cambie su dirección IP y puertos eth para que coincidan con los que desea limitar


3

Para completar, hay un demonio de espacio de usuario llamado trickle. Se puede usar para limitar el ancho de banda de un solo proceso. El uso es muy simple: por ejemplo, para limitar el ancho de banda utilizado por aptitude, podría escribir: trickle -d 10 aptitude install wesnothSin embargo, dado que funciona usando LD_PRELOAD, un usuario con acceso a shell podría anularlo fácilmente.


Ninguno de los usuarios además de mí tiene acceso a shell. Además, con limitación de ancho de banda, quiero decir por mes, o un período de tiempo establecido. ¿Sería eso posible?
loco41211

1
No, el goteo limita la velocidad como por segundo.
liori el

2

Eche un vistazo al parche del kernel useripacct (esto en realidad tiene una historia bastante larga ). En los documentos de la versión anterior , parece que también proporciona cumplimiento de cuotas y monitoreo, y también es posible proporcionar sus propios scripts de política.

Dado que los creadores de useripacct tuvieron que recurrir a un parche del kernel para obtener el comportamiento que desea, parece poco probable que haya un método más simple disponible por defecto. Las únicas alternativas parecerían ser la limitación del ancho de banda (por algo como tc o goteo) como lo sugieren la mayoría de las otras respuestas aquí (pero no lo que realmente estás buscando), o crear una VM para cada usuario (usando virtualización de SO liviana por algo como OpenVZ ) y el tráfico de contabilidad por VM (que es bastante fácil de evaluar por algo como vnstat ). Sin embargo, eso parece excesivo (de repente tienes que administrar un montón de máquinas virtuales en lugar de un solo sistema).


es un poco exagerado ya que agotaría los recursos del servidor ... ¡pero gracias por la idea!
loco41211
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.