Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Portuguese / Re: Bloqueio de P2P (Ares)
« on: November 12, 2010, 11:11:24 am »
Olá,
O Ares Galaxy usa a porta 32285 como padrão, porém possui configuração dinâmica (um inferno para os administradores de firewalls) e pode escolher alternativas, inclusive a porta HTTP (80). Até onde conheço, o protocolo dele é bastante difícil para ser limitado, as extensões do netfilter IPP2P e L7-Filter (usado pela Zentyal) permitem bloqueá-lo somente.
As versões mais recentes do Ares suportam também os protocolos Bittorrent e Shoutcast.
Abraços,
O Ares Galaxy usa a porta 32285 como padrão, porém possui configuração dinâmica (um inferno para os administradores de firewalls) e pode escolher alternativas, inclusive a porta HTTP (80). Até onde conheço, o protocolo dele é bastante difícil para ser limitado, as extensões do netfilter IPP2P e L7-Filter (usado pela Zentyal) permitem bloqueá-lo somente.
As versões mais recentes do Ares suportam também os protocolos Bittorrent e Shoutcast.
Abraços,
2
Portuguese / Re: Verdade ou Mito: Proxy e Controle de Banda não funcionam juntos!
« on: November 11, 2010, 05:12:35 pm »
Caro Júnior,
É isso mesmo, "Política de Estrangulamento de Banda". Você determina o tamanho máximo de download sem limitação de velocidade e a taxa máxima que será permitida pelo proxy após atingido este tamanho. A classe 1 tem prioridade e se aplica à toda sub-rede, enquanto a classe 2 é aplicada por clientes (limitados a 256)
Só para esclarecer o que postei sobre a impossibilidade de se fazer um controle minucioso do tráfego que entra por uma interface, esta restrição não é exclusiva da Zentyal, mesmo com CBQ ou HTB (que particularmente acho melhor) o problema ainda existe. Não conheço as entranhas do MyAuth, pode ser que ele possua algum mecanismo intermediário como os que citei.
A explicação para isso é a seguinte:
Os pacotes que trafegam na rede são gravados em buffers de recepção e transmissão ligados à interface de rede. Um processo local sabe quando o buffer de transmissão está cheio e "segura" o envio de pacotes, ou seja, não existe a perda destes internamente. Um processo externo (em outro host) não tem conhecimento que o buffer de recepção do destino está cheio e continua a mandar pacotes, os quais são simplesmente ignorados pela interface até que haja espaço no buffer para recebê-los, o que acarreta perda de pacotes. Isto é especialmente verdade nos casos de protocolos sem aviso de recebimento, como SMTP ou UDP. Pois bem, aqui já temos um "controle de banda" natural, onde a taxas são limitadas pelas capacidades dos buffers e também pela capacidade do meio de conexão. No protocolo TCP, o mecanismo de controle de transmissão percebe as perdas e ajusta o ritmo para reduzí-las, "economizando" o link pela menor quantidade de retransmissões. Mesmo assim as taxas podem saturar a conexão, então, no caso do TCP, podemos limitá-las ajustando o tamanho do buffers.
Em um controle de banda avançado os pacotes são classificados (marcados) conforme critérios como origem, destino, protocolo, portas, etc., e roteados, de acordo com esta classificação, para buffers com capacidades pré-definidas, permitindo-se fazer a limitação seletivamente. Acontece que esta marcação no cabeçalho do pacote só pode ser feita e utilizada internamente, ou seja, pacotes recebidos de fora não podem ser discriminados. Assim, se quisermos limitar determinado protocolo, serviço, ip, etc, ou dar garantia de banda a outro, a ação tem que ser aplicada na saída da interface conectada à rede interna. Mas note que, ainda desta forma, estaremos apenas regulando os fluxos que atravessam a máquina controladora, e não impedindo que os pacotes vindos de fora continuem batendo à porta da interface externa.
Abraços,
É isso mesmo, "Política de Estrangulamento de Banda". Você determina o tamanho máximo de download sem limitação de velocidade e a taxa máxima que será permitida pelo proxy após atingido este tamanho. A classe 1 tem prioridade e se aplica à toda sub-rede, enquanto a classe 2 é aplicada por clientes (limitados a 256)
Só para esclarecer o que postei sobre a impossibilidade de se fazer um controle minucioso do tráfego que entra por uma interface, esta restrição não é exclusiva da Zentyal, mesmo com CBQ ou HTB (que particularmente acho melhor) o problema ainda existe. Não conheço as entranhas do MyAuth, pode ser que ele possua algum mecanismo intermediário como os que citei.
A explicação para isso é a seguinte:
Os pacotes que trafegam na rede são gravados em buffers de recepção e transmissão ligados à interface de rede. Um processo local sabe quando o buffer de transmissão está cheio e "segura" o envio de pacotes, ou seja, não existe a perda destes internamente. Um processo externo (em outro host) não tem conhecimento que o buffer de recepção do destino está cheio e continua a mandar pacotes, os quais são simplesmente ignorados pela interface até que haja espaço no buffer para recebê-los, o que acarreta perda de pacotes. Isto é especialmente verdade nos casos de protocolos sem aviso de recebimento, como SMTP ou UDP. Pois bem, aqui já temos um "controle de banda" natural, onde a taxas são limitadas pelas capacidades dos buffers e também pela capacidade do meio de conexão. No protocolo TCP, o mecanismo de controle de transmissão percebe as perdas e ajusta o ritmo para reduzí-las, "economizando" o link pela menor quantidade de retransmissões. Mesmo assim as taxas podem saturar a conexão, então, no caso do TCP, podemos limitá-las ajustando o tamanho do buffers.
Em um controle de banda avançado os pacotes são classificados (marcados) conforme critérios como origem, destino, protocolo, portas, etc., e roteados, de acordo com esta classificação, para buffers com capacidades pré-definidas, permitindo-se fazer a limitação seletivamente. Acontece que esta marcação no cabeçalho do pacote só pode ser feita e utilizada internamente, ou seja, pacotes recebidos de fora não podem ser discriminados. Assim, se quisermos limitar determinado protocolo, serviço, ip, etc, ou dar garantia de banda a outro, a ação tem que ser aplicada na saída da interface conectada à rede interna. Mas note que, ainda desta forma, estaremos apenas regulando os fluxos que atravessam a máquina controladora, e não impedindo que os pacotes vindos de fora continuem batendo à porta da interface externa.
Abraços,
3
Portuguese / Re: Verdade ou Mito: Proxy e Controle de Banda não funcionam juntos!
« on: November 11, 2010, 01:46:35 pm »
Olá,
Ainda não sou nenhum expert na Zentyal (estou tentando
), e este é o meu primeiro post, mas aí vão meus dois centavos:
Se o controle e o proxy rodarem na mesma máquina, há um pouco de verdade sim.
A razão é simples: Somente é possível manipular os pacotes que saem pela interface. A limitação da velocidade em que entram pode ser feita apenas descartando o excesso, o que na prática não é controle de banda, porque a origem não sabe exatamente quais pacotes deverão ter maior ou menor prioridade.
Então, um controle mais efetivo no download deve ser feito na interface interna da máquina que controla a banda, a que envia os pacotes para a rede local, e por isso fica evidente que, se o proxy estiver instalado nesta mesma máquina, o tráfego HTTP não vai chegar a ele por esta interface e não poderá ser manipulado.
Se o proxy usado for o Squid, forma mais prática de se amenizar esta questão é usar o mecanismo de "delay pools", que pode ser configurado facilmente na Zentyal.
Entretanto, para se ter um controle mais apurado, do tipo distinguir os protocolos que cruzam o proxy (HTTP e HTTPS, por exemplo), este deve ficar em uma máquina separada (pode ser até virtual, dentro da que controla a banda, já fiz assim). Outra alternativa é usar dispositivos IFB (Intermediate Functional Block) ou IMQ (Intermediate Queueing Device), que são pseudo-interfaces que se conectam às físicas e permitem que se controle o que sai delas para estas últimas.
Um grande abraço,
--
Márcio H. Parreiras
GNU/Linux Professional
+55(31)9632-0320
Pedro Leopoldo - MG - Brazil
"Faça a mudança: http://makethemove.net/"
"Livre-se dos vírus e outras ameaças digitais: http://www.ubuntu-br.org/"
"Get rid of viruses and other digital threats: http://www.ubuntu.com/"
.
Ainda não sou nenhum expert na Zentyal (estou tentando
), e este é o meu primeiro post, mas aí vão meus dois centavos:Se o controle e o proxy rodarem na mesma máquina, há um pouco de verdade sim.
A razão é simples: Somente é possível manipular os pacotes que saem pela interface. A limitação da velocidade em que entram pode ser feita apenas descartando o excesso, o que na prática não é controle de banda, porque a origem não sabe exatamente quais pacotes deverão ter maior ou menor prioridade.
Então, um controle mais efetivo no download deve ser feito na interface interna da máquina que controla a banda, a que envia os pacotes para a rede local, e por isso fica evidente que, se o proxy estiver instalado nesta mesma máquina, o tráfego HTTP não vai chegar a ele por esta interface e não poderá ser manipulado.
Se o proxy usado for o Squid, forma mais prática de se amenizar esta questão é usar o mecanismo de "delay pools", que pode ser configurado facilmente na Zentyal.
Entretanto, para se ter um controle mais apurado, do tipo distinguir os protocolos que cruzam o proxy (HTTP e HTTPS, por exemplo), este deve ficar em uma máquina separada (pode ser até virtual, dentro da que controla a banda, já fiz assim). Outra alternativa é usar dispositivos IFB (Intermediate Functional Block) ou IMQ (Intermediate Queueing Device), que são pseudo-interfaces que se conectam às físicas e permitem que se controle o que sai delas para estas últimas.
Um grande abraço,
--
Márcio H. Parreiras
GNU/Linux Professional
+55(31)9632-0320
Pedro Leopoldo - MG - Brazil
"Faça a mudança: http://makethemove.net/"
"Livre-se dos vírus e outras ameaças digitais: http://www.ubuntu-br.org/"
"Get rid of viruses and other digital threats: http://www.ubuntu.com/"
.
Pages: [1]