Qual é a melhor solução para o controle de tráfego em um sistema grande (cerca de 2000 usuários)?

Question

seguinte situação: Somos um grupo de estudantes administrando a conexão de internet para as residências locais, com um total de cerca de 2.000 usuários finais.

Temos um sistema de ponto de tráfego, cada ponto de custo de carregamento ou de transferência de MB, novos pontos são adicionados por hora. No momento, bloqueamos o acesso à internet de um usuário quando ele gastou todos os seus pontos (colocando-o em uma política de REJECT no iptables em nosso roteador de gateway da Debian).

Gostaríamos apenas de limitar a largura de banda de um usuário. Qual é a melhor maneira de fazer isso?

A resposta simples seria definir um limite de taxa na porta do switch do usuário (principalmente o Cisco Catalyst 3550s). No entanto, isso é indesejável, pois o tráfego dentro da nossa própria rede e da rede da universidade deve permanecer ilimitado. Existe uma maneira de limitar a largura de banda somente para pacotes com um determinado destino ou intervalo de IP de origem (para saída e entrada) no Cisco IOS? Eu não consegui encontrar nada.

A outra maneira seria controlar o tráfego em nosso roteador de gateway. Várias soluções vêm à minha mente:

• tc ou tcng - parece que ambos têm uma sintaxe bastante arcaica e nem oferecem bons recursos para fazer controle de tráfego por IP. Um QDisc dedicado para tantas pessoas provavelmente atrasaria muito o roteador. Além disso, a documentação de ambos está bastante desatualizada.

• shorewall - parece ter uma sintaxe bastante nítida para configurações, no entanto, não tenho certeza se ele pode lidar com essa quantidade de tráfego e usuários e se é adequado para limitar o tráfego por IP

• pfSense - parece um SO destinado a propósitos como o nosso. No entanto, isso exigiria que nós reinstalássemos de forma compacta nosso roteador de gateway. Não temos outros sistemas BSD e o pfSense precisaria ter recursos de contabilidade de tráfego muito bons (também estamos usando fprobe-ulog e ulog-acctd no momento).

Qual é a sua experiência? Qual solução atende às nossas necessidades e pode ser mais facilmente mantida? Você tem outras ideias?

Se precisar de informações adicionais sobre o nosso sistema, não hesite em perguntar.

Obrigado antecipadamente.

EDIT : Eu implementei o sistema com iptables e tc .

Todo usuário tem uma sub-rede / 28, um IP de VPN (ambos de 10.0.0.0/8) e um IP externo, todos são direcionados por uma cadeia de iptables. Esta cadeia tem apenas uma regra, um simples RETURN .

A cada cinco minutos, um script Python lê os contadores de bytes dessas regras. Ele redefine os contadores e atualiza a conta do ponto de tráfego do usuário em nosso banco de dados PostgreSQL.

Se o saldo de pontos de um usuário diminuir abaixo de um certo limite, duas classes tc são criadas para esse usuário (um para a entrada e outro para a interface de saída em nosso roteador de gateway), os IPs são inseridos em filtros tc pertencentes a essas classes . As classes são limitadas pela velocidade por um HTB.

Comparado ao sistema anterior com fprobe-ulog e ulog-acctd , isso é muito mais rápido, já que a contagem de bytes é feita pelo iptables.

A velocidade da rede melhorou consideravelmente para nossos usuários.

    

Answer 1

Não tenho certeza de como você está interessado em reconfigurar toda a sua configuração (isto é, substituir o Debian), ou quão viável seria colocar algo assim atrás do seu gateway, mas o FreeBSD tem um recurso no ipfw conhecido como dummynet . Como parece que você não está com vontade de ter um modelador de tráfego de hardware dedicado, isso pode ser uma opção para você. Atualmente, nós o usamos para bloquear a entrada e saída de tráfego SMTP por meio de um dos nossos gateways de proxy para evitar que um sistema de back-end do NFS antigo seja sobrecarregado e, posteriormente, não responda.

Com alguns scripts e configuração inteligente de seus conjuntos de regras, seria viável poder controlar milhares de endereços individuais de controle de tráfego.

    

Answer 2

Vou ter que perguntar o que estamos usando, mas nosso pessoal da ResTek tem um appliance na fronteira da Internet que faz as funções de qualidade de serviço. Ele tem uma prioridade padrão para fluxos não classificados e prioriza outro tráfego com base em regras. É o recurso de prioridade que realmente o vende, pois eles também operam um cluster de armazenamento em cache baseado em Squid que é listado como de maior prioridade no dispositivo de borda. As pessoas em sua rede, então, têm a opção de navegar na web com uma prioridade padrão (e um tanto chata), ou usar o proxy e obter uma resposta muito rápida. Eles também aceitam solicitações de prioridade de servidor de jogos, já que são sensíveis à latência, mas com baixa largura de banda, como é óbvio.

Existe uma quantidade razoável de trabalho lidando com as solicitações do servidor de jogos, mas elas estão indo devagar à medida que mais e mais jogos se afastam dos servidores privados. No geral, ouvi dizer que funciona muito bem para eles. Eles podem impedir que coisas como o bittorrent eliminem todos os outros tráfegos e ainda mantenham o tempo de carregamento das pessoas no YouTube rapidamente.

    

Answer 3

Com muitos usuários, a maioria das coisas simples baseadas em software começa a falhar.

Considere olhar para dispositivos packeteer e similares. Hoje em dia eles são quase mais caros do que comprar mais largura de banda (nos EUA e na Europa, nós, pessoas pobres na Austrália, ainda temos taxas muito altas).

    

Answer 4

dummynet é uma boa sugestão na minha opinião. Mas eu tenho certeza que o iptables é capaz de modelar o tráfego também, então você pode fazer isso no seu caixa debian.

    

Answer 5

tc deve funcionar bem .. Acredito que o que você deseja fazer é alterar suas regras iptables atuais para marcar em vez de REJEITAR o tráfego, então você pode usar um pequeno número de regras tc para aplicar a modelagem de tráfego a esses fluxos marcados.

veja também o ipset para gerenciar a lista de usuários link

    

Answer 6

O Trafficpanel parece ser uma solução. Entre outras características:

• Limitando a velocidade máxima do HTTP por conexão
• Limitando o tráfego total de recursos da web por host de rede local
• Registrar o tráfego da Internet por host da rede local
• Limitando a velocidade máxima de tráfego por host da rede local
• Limitando o tráfego total da Internet por host da rede local

Na verdade, nunca tentei isso, mas parece ok.