Artigo TCC - ESTUDO COMPARATIVO ENTRE O PFSENSE E O ROUTEROS EM DOIS MODELOS DE REDE

ESTUDO COMPARATIVO ENTRE O PFSENSE E O ROUTEROS EM DOIS MODELOS DE REDE

Wanderson 1

RESUMO:
Após um período considerável, utilizando o RouterOS como sistema principal de gerenciamento em duas redes, sendo uma corporativa e outra de acesso público, utilizando hotspot, eis que surge a oportunidade de pesquisar e estudar outro sistema, com apoio e orientação acadêmica chegou-se ao pfSense. Esta pesquisa demonstra os resultados da comparação entre as duas soluções para gerenciamento das redes, denominados sistemas pré-configurados, o pfSense é baseado na gratuita plataforma Unix FreeBSD, já o RouterOS é baseado na plataforma Linux. O estudo mostra as vantagens e desvantagens em se aplicar cada um dos sistemas estudados nos dois modelos de redes, seja ela corporativa (privada) ou de acesso público (CyberCafé ou Provedores de Internet sem fio). Serão apresentadas algumas das principais características dos sistemas, sejam elas positivas ou negativas, o resultado coletado poderá servir de base em consultas futuras para administradores de redes e sistemas, auxiliando-os na tomada de decisão de qual sistema poderia ser mais adequado no gerenciamento de determinado tipo de rede. Os resultados incluem gráficos comparativos do trafego gerado pelos sistemas já em produção, permitindo analisar melhor o desempenho de cada um deles.

PALAVRAS-CHAVE: Rede. RouterOS. pfSense. Linux. FreeBSD. administrador. Solução. Servidor. Unix. Plataforma.

ABSTRACT:
After a considerable period, using the RouterOS as main system management in two networks, being a corporate and other public access, using hotspot, behold, there is an opportunity to browse and study other system, with support and academic guidance came to the pfSense. This research shows the results of the comparison between the two solutions for the management of networks, known as systems pre-configured, pfSense is based on free UnixFreeBSD platform, already the RouterOS and based on Linux platform. The study shows the advantages and disadvantages to apply each of the systems studied in the two models of networks, be it corporate (private) or for public access (Cyber café, or Wireless Internet Providers). Will Be presented some of the main features, available in systems, whether positive or negative, the result collected will serve as the basis for future consultations for network and systems administrators, assisting them in decision making system which could be more appropriate to manage determined kind of network. The results include comparative graphs of the traffic generated by the systems already in production, allowing better analyze the performance of each one of them.

KEYWORDS: Network. RouterOS. pfSense. Linux. FreeBSD. administrator. Solution. Server. Unix. Platform.

1.    INTRODUÇÃO
    No final da década do ano de 1960 ainda não era possível lançar mão de sistemas multitarefas de tempo compartilhado, para gerenciar redes de computadores como hoje. Com a ausência de um sistema operacional competente na época, os computadores resumiam-se em transferir dados de um lado para outro utilizando apenas disquetes, o que comprometia a integridade dos dados por causa das falhas de gravações, ou até mesmo no transporte e manuseio do disco. Em 1961, bem antes da popularização da Internet, foi desenvolvido pelo MIT (Massachusetts Institute of Technology) instituto de tecnologia de Massachusetts, o primeiro CTSS (Compatible Timesharing System) ou sistema de tempo compartilhado Compatível; em 1970 nasce o Unics pelas mãos de Ken Thompson, mais tarde Dennis Ritchie o reescreveu na linguagem C, criada por ele mesmo, passando a chamá-lo de UNIX.
    Com o passar do tempo as redes de computadores ficaram cada vez mais complexas, sendo cada vez mais necessário o aperfeiçoamento dos sistemas operacionais, para melhorar o gerenciamento de grandes infraestruturas; consequentemente diminuindo o exaustivo trabalho do administrador.
    Antes do CTSS, as universidades, onde mais se utilizavam computadores, levavam um tempo absurdo para transferir uma pequena quantidade de dados de um lado para outro, enquanto hoje esse limite é quase infinito, sendo possível enviar e receber grandes quantidades de dados atravessando continentes, não somente paredes como no passado.
    Essa realidade mudou, mas mesmo nos tempos atuais, é de extrema importância sistemas ainda mais avançados, para assim elevar o nível de desenvolvimento tecnológico das redes de computadores. Estes sistemas avançados já são realidade, e podem ser utilizados na forma dos sistemas pré-configurados.
  
1.1 Objetivo Geral
    O objetivo geral deste trabalho é analisar e apresentar como forma de comparação os resultados das duas tecnologias testadas. Mesmo aparentando similaridade entre as tecnologias; por gerenciar serviços básicos de rede, existindo sempre algum detalhe que será de vital importância no auxilio aos serviços do administrador.

1.2 Objetivos Específicos
    Identificar os pontos fortes e os fracos dos dois sistemas pré-configurados; para assim definir a melhor opção de gerenciamento para cada um dos modelos de redes, seja ele corporativo ou de acesso público.

1.3 Metodologia
    Foram realizados testes comparativos utilizando os dois sistemas configurados em duas infraestruturas de rede diferentes, afim de identificar os pontos positivos.
    A primeira, uma rede corporativa, visando fornecer acesso aos funcionários de uma instituição.
    A segunda, um provedor wi-fi, fornecendo acesso à Internet para usuários domésticos.

2. DESENVOLVIMENTO
    Atualmente é comum encontrar sistemas pré-configurados para computadores do tipo genérico. O único trabalho é baixar uma ISO, gravá-la no CD, e seguir os passos de instalação. A facilidade de configurar esse tipo de sistema é o fator chave para reunir adeptos. Existem várias distribuições desse tipo de sistema, como por exemplo: BrasilFW (Brasil Firewall and Router), IPCOP Firewall Linux, Coyote Linux Internet Security, ZeroShell Firewall e Net Service, Endian Firewall, m0n0wall dentre outros. Todos os sistemas citados, incluindo os estudados, são chamados system Appliance, sistemas criados e preparados para rodar, tanto em computadores comuns (instalados em HD's) como nos chamados system embedded (sistemas embarcados), instalados em memórias não voláteis de algum hardware dedicado às funções de firewall ou roteador, denominados Hardwares Appliances.
  
2.1 O pfSense
    Projeto iniciado em 2004 por Chris Buechler e Ullrich Scott, sendo que Buechler é atualmente o CTO (Chief Technology Officer) traduzido para Diretor Tecnológico da BSD Perimeter. Scott, é o arquiteto chefe dessa mesma empresa onde, além de cofundador, é o principal desenvolvedor do pfSense. A BSD Perimeter é a empresa oficial de desenvolvimento das soluções de segurança, suporte comercial e consultoria para Appliances Firewalls baseados em m0n0wall e pfSense para o mundo todo.
    O pfSense é baseado na então conhecida plataforma UNIX FreeBSD, ele possui um servidor web e suporta aplicações em PHP, proporcionando uma interação amigável entre usuário e sistema, chamada de Dashboard. Esse conceito de configuração em modo gráfico (WEBGUI) utiliza os mesmos recursos de um serviço web. Essa ideia foi aproveitada do sistema m0n0wall, seu irmão mais velho. Ele é uma versão reduzida de tudo que o UNIX FreeBSD possui de essencial para tecnologias em rede; o m0n0wall ocupa pouco mais que 8Mb de espaço; por ser um sistema tão reduzido, é possível ser gravado diretamente em pequenos dispositivos em estado sólido (O silício) embarcados em Hardwares Appliances, podendo ser instalado também em HDs ou Compact Flashes.
    A criação do pfSense, utilizando o FreeBSD como base de sua construção, foi motivada pelo fato de que este UNIX era o único que dominava a tecnologia wireless de forma bastante avançada, possuindo até mesmo suporte à criptografia do tipo WPA2, o que não era possível em outros sistemas na época. A opção por um BSD foi muito bem sucedida, principalmente porque o pfSense herdara a pilha TCP/IP da família de sistemas UNIX, que é considerada a de melhor performance e a mais robusta já existente. E não era pra menos, pois ela foi criada na própria plataforma BSD (Berkeley Software Distribution) para suprir as necessidades da então extinta ARPANET, hoje a Internet, tornando-se um padrão mundial.

-->

O Departamento de Defesa e Pesquisa Norte Americano havia contratado a consultoria Bolt Beranek & Newman para implementar um protocolo de rede para o governo. No BSD 4.1, os estudantes de Berkeley revisaram os conceitos por trás desse protocolo, modificaram e o aprimoraram, criando uma versão apropriada para atender suas próprias demandas. Em 1986, no BSD versão 4.3, o DARPA (Departamento de Defesa) testou esse protocolo, o TCP/IP, e decidiram adotá-lo ao invés da versão projetada por BBN.[...] Quando a DARPA quis construir a rede ARPANET hoje a Internet em 1983, descartou seu protocolo existente e confiou o serviço no TCP/IP do BSD Unix.(BABCOCK, 2006).

    O sistema pfSense utiliza a mesma licença da família BSD, que por sua vez é baseada em código aberto, possuindo poucas diferenças comparadas com as impostas por licenças como a GNU/GPL e a Copyright, ao ponto de poder ser chamada de licença de domínio público. É possível encontrar o termo da licença no site oficial da comunidade.
    Apesar do pfSense ser um Unix não é necessário que o usuário seja expert nesta modalidade de sistema. Por ser um sistema pré-programado, basta apenas que, após a instalação sejam adicionadas as configurações necessárias utilizando um navegador web; todavia, o utilizador deve possuir conhecimentos em protocolos e segurança de rede para configurá-lo corretamente.

Fig.1 – Dashboard de configuração do pfSene.Fonte: Própria

  
    Para configurar este tipo de sistema não é necessário estar na presença do servidor, é possível fazê-lo remotamente, bastando digitar o IP pré-configurado na barra de endereço de um navegador web, quando será solicitado login e senha; após a autenticação, receberá a Dashboard, ou painel de controle do sistema, como mostrado na gravura acima.

-->

SCOTT, afirma em entrevista para o site freesoftwaremagazine que o pfSense fornece muito além das funcionalidades encontradas em firewalls comerciais e completa dizendo que, o pfSense vem substituído firewalls de grande porte comercial em empresas pelo mundo afora, como os da Check Point, Cisco PIX, Sonicwall, Netgear, Watchguard, Astaro, dentre outras marcas, e em grandes quantidades (FREE SOFTWARE MAGAZINE, 2007).

    Por esse motivo o equipamento onde o pfSense foi instalado sequer precisará de um monitor, teclado ou mouse, podendo ser acessado remotamente, de onde se fará toda configuração e monitoramento do mesmo.
    É possível verificar a transcrição básica do passo a passo da instalação dos sistemas utilizados em laboratório que se encontra no APÊNDICE A.

2.2 O RouterOS
    RouterOS é o nome do sistema redesenhado pela empresa MikrotikLS a partir do Kernel Linux versão 2.6; ele pode ser considerado um system stand alone, traduzindo, um sistema autônomo, que não depende de nenhum outro sistema para funcionar. A empresa MikrotikLS foi fundada em 1995, na cidade de Riga, capital da Lativia, uma região próxima à Rússia.
    Apesar de ser construído utilizando o Linux como base do sistema, é cobrada pela empresa uma taxa de licença para utilizá-lo. Isto se dá pelo fato de que no sistema existem módulos desenvolvidos com recursos não livres, onde é necessário o pagamento de royalties a terceiro. “Este sistema é baseado em parte no trabalho da Independent JPEG Group jpeg (MIKROTIK, 2012)” como descrito na última linha do contrato da licença de utilização do software para usuário final.

-->

Para obter um CD com cópia do código fonte correspondente aos programas cobertos pela GNU/GPL que estão sendo utilizados no sistema RouterOS, é necessário que se faça uma transferência eletrônica no valor de US $45 a MikroTikls SIA, sediada em Pernavas 46, Riga, LV-1009, na Letônia. De maneira  que será preciso antes entrar em contato com a MikroTikls SIA para obter o número da conta corrente e/ou instruções para transferência bancária (MIKROTIKLS, 2012).

    A questão de não ser facilitado o acesso aos códigos fontes do RouterOS, com a mesma facilidade que se acessa os códigos de outras distribuições livres, é um fator que chama muito a atenção dos desenvolvedores do Linux, mas a MikrotikLS disponibiliza os códigos na medida em que são solicitados e em mídias de CD cobrando uma taxa de $45 dólares pelo mesmo. Só é possível fazer solicitações por correio, telefone ou fax, como é informado no termo de licença, fugindo ao paradigma da GNU/GPL que incentiva o livre acesso aos códigos de qualquer sistema ou software, baseados ou mantidos sobre licenças Open Sources.
    O RouterOS foi desenvolvido inicialmente para funcionar somente em computadores convencionais com arquitetura x86 (Processadores Intel). Hoje já existem os Hardwares Appliances Embedded (módulos Appliance com o sistema RouterOS embarcado), fabricado no padrão 1U para serem montados em racks. Não muito diferente do pfSense, o acesso é realizado utilizando o WINBOX, um aplicativo autoexecutável (não necessita instalação) que monta a GUI do RouterOS, sendo utilizado preferencialmente em sistemas Windows, mas podendo ser carregado no Linux utilizando o wine, um emulador de plataformas Windows. Se o computador utilizado para configurar o sistema estiver conectado de alguma forma a uma das interfaces de rede do servidor, será automaticamente identificado o endereço MAC e/ou IP dela, podendo ser iniciado o acesso.

Fig.2 – Área de trabalho de configuração do RouterOS.
Fonte: Própria

2.3 Roteamento
    Qualquer sistema de gerenciamento de rede precisa, de alguma forma, trabalhar com os principais protocolos de roteamento.
    O RouterOS possui suporte a uma variedade deles, como o OSPF, OSPFv3, BGP, RIP, RIPng, PIM, IGMP Proxy, Prefix Lists e inclusive o MME (Mesh Made Easy), protocolo específico para redes IP sem fio. O pfSense também possui capacidade de roteamento utilizando os principais protocolos, RIP e IGMP Proxy, estes já pré-instalados e prontos para serem configurados, mas é possível configurar também os protocolos OSPF e BGP, instalando complementos como o QuaggaOSPF, OpenOSPFD e OpenBGPd.
    Os comandos utilizados na configuração do OSPF utilizando o Quagga em modo texto (shell) é similar aos comandos do IOS CISCO, mas, no pfSense, mesmo quem nunca configurou um roteador destes, mas que conheça os parâmetros de configuração do protocolo, não terá dificuldade alguma, precisando somente confirmar alguns parâmetros pré-definidos e alterar outros poucos, se necessário. Já no RouterOS essa tarefa se torna um pouco árdua, até mais que em um roteador CISCO, por causa das várias informações que o administrador precisa assimilar no momento da configuração do protocolo, necessitando realmente reaprender como se configura o protocolo OSPF nesse sistema.
    Fica claro que os dois sistemas são capazes de trabalhar com diversos serviços de roteamento, porém, a necessidade do administrador, o protocolo a ser utilizado e o grau de dificuldade apresentado por cada um dos sistemas, aqui estudados, é que vão interferir na sua decisão; RouterOS ou pfSense para roteador? Só se terá a resposta depois de observar detalhes que irão proporcionar rapidez e objetividade na hora de configurar os serviços de que se necessita.

2.4 Filtragem de pacotes
    Uma das muitas funções de um filtro de pacote é aceitar ou negar, em uma rede, os acessos a conteúdos autorizados ou não, controlando o tráfego entre redes distintas. Utilizando técnicas de filtragem é possível impedir que usuários de uma rede acessem conteúdos indesejáveis ou nocivos e os propague na mesma, evitando principalmente a degradação do meio utilizado. Um filtro de pacotes pode possuir capacidades que vão além, dependendo de quem o configura, isso porque essas filtragens podem ser realizadas por portas, protocolos, endereços IP, endereços MAC, ou baseado no conteúdo que o usuário pode ou não acessar na Internet.
    Por ter sido utilizada a plataforma BSD como a base da criação do pfSense, existe a certeza de que carrega em seu “DNA” uma das maiores e históricas experiências tecnológicas: a criação do protocolo mais utilizado no mundo (Internet), o TCP/IP.

-->

Sistema BSD tem, desde seus primórdios, a reconhecida fama de ter uma das pilhas TCP/IP mais robustas e com melhor performance, além de ter sido o sistema onde o TCP/IP foi projetado, criado e popularizado (FREEBSD, 2007).

    Todos os recursos que otimizam o tráfego de rede no pfSense convergem para o fato da criação do protocolo TCP/IP ter sido em cima das necessidades do BSD, carregando consigo a mais perfeita sincronia da comunicação do protocolo com o kernel do sistema, sendo assim considerada a pilha TCP/IP de melhor performance.
    Para melhor entendimento será feita a analogia com um software escrito por um programador, e que ninguém consegue utilizá-lo por não conhecê-lo, salvo o próprio desenvolvedor e, mesmo que ele ensine alguém a utilizá-lo, somente ele, o criador do software, saberá utilizar o programa em todo seu potencial, por entendê-lo como a palma de sua mão. O mesmo acontece com o protocolo TCP/IP. Ele possui melhor desempenho e aproveitamento em cima da plataforma onde foi criado; ao ser portado para outra plataforma, geralmente são feitas adaptações que podem afetar o desempenho do serviço.
    É possível observar que sistemas baseados em qualquer outra plataforma que não a  BSD, como é o caso do RouterOS, que também trabalha com recursos de filtragem de pacote e conteúdo, não possuem a mesma performance da pilha TCP/IP BSD. Mas se regras de filtragem forem bem elaboradas, será capaz de superar a performance de um UNIX mal configurado, ficando claro que, de nada adiantará o pfSense ter a melhor pilha TCP/IP e não ser configurado corretamente por um especialista em filtragem de pacotes, prejudicando todo o seu desempenho, por conta do mau gerenciamento de suas regras.

2.5 Controle de Acesso e Bilhetagem
    Existe uma certa preocupação com relação ao controle de acesso à Internet, principalmente em redes sem fio, onde o administrador necessita escolher melhor as opções de ferramentas para autenticação dos usuários.
    Para controle de acesso, o RouterOS utiliza meios como captive portal ou hotspot e PPPoE para autenticar as conexões, podendo fazê-lo também utilizando um servidor Radius parente (em paralelo), necessitando somente configurar os parâmetros para a comunicação entre os dois servidores, ficando toda autenticação centralizada no Radius, aumentando a segurança dos usuários. O hotspot, mesmo sendo um método menos seguro, é o mais utilizado em redes de CyberCafé ou na maioria dos ISP Wireless (Provedor de Serviço de Internet Sem fio), por causa da facilidade de configuração e por ter, como aliado, as páginas html utilizadas para envio de mensagens e/ou propagandas antes e depois da autenticação do usuário.
    O pfSense também possui todos estes métodos de controle de acesso já citados, só que com um diferencial que o deixa em vantagem em relação ao RouterOS, a emissão de voucher. Para gerenciar um CyberCafé, e ter que administrar o sistema ao mesmo tempo seria muito trabalhoso, mas é ai que entra a emissão de vouchers; sem muito trabalho e com uma  qualidade que impressiona, o pfSense emite códigos de autenticação que ficam armazenados em um banco de dados, aguardando as autenticações dos usuários, que ao digitar tais códigos, são liberados automaticamente os acessos, sem a necessidade de um administrador de plantão. No RouterOS não foi possível obter os mesmos resultados por não apresentar ferramenta do pfSense. É possível sim, fazer controle de acesso por tempo de utilização ou por quantidade de tráfego pré estipulado, mas não chega perto da comodidade que o pfSense oferece. O RouterOS não é capaz de gerar vouchers, e ainda é preciso criar usuários e senhas, por demanda, na seção “user” do hotspot configurando o tempo e/ou a quantidade de tráfego permitido para o usuário adicionado, ou seja, é muito trabalhoso e pouco profissional; não esquecendo que é preciso descartar todos os usuários criados após a utilização, pois o sistema também não o faz automaticamente.
  
2.6 Controle de Banda
    O Trafic Shaper ou controle de banda, como é popularmente conhecido, proporciona igual condição para que os serviços de uma rede e os usuários dela utilizem a infraestrutura sem que um interfira no tráfego do outro.
    O pfSense dispõe de três opções para realizar Trafic Shaper, deixando a critério do administrador escolher qual qdisc (qualidade de disciplina) utilizar, sendo eles:
HFSC (Hierarchical Fair Service Curve) ou Curva de Serviço Hierárquico, utiliza o mesmo algoritmo de QoS (Qualidade de Serviço) do CBQ. É nativo em sistemas UNIX como, FreeBSD, NetBSD e OpenBSD.
PRIQ (Priority Queue) ou fila prioritária, controla a ordem de uma fila em andamento utilizando a prioridade como requisito.
CBQ (Class-Based Queueing) ou fila baseada em classes, é uma qdisc muito popular, mas obsoleto, para realizar controle de QoS. Este método controla a ordem de uma fila em andamento, baseando-se em um algoritmo de controle em esquema hierárquico.
    Existem várias qdiscs, incluindo as já citadas, que podem ser utilizadas conforme a necessidade. Segue a lista:
• FIFO: First In First Out (O primeiro a entrar é o primeiro a sair)
• SFQ: Stochastic Fair Queuing (enfileiramento estatístico justo)
• TBF: Token Bucket Flow (unidade de medida de sinal por fluxo)
• DS_MARK: Diff-Serv Marker (marcação de serviços diferenciados)
• RED: Random Early Detection (Detecção Prematura Aleatória)
• HTB: Hierarquical Token Bucket (unidade de medida por sinal hierarquizado)
    O RouterOS utiliza a qdisc HTB, para controle de QoS. O HTB é um módulo do kernel GNU/Linux (sch_htb) que, por sua vez, utiliza técnicas de enfileiramento de pacote classful (utilizando classes). Isso só é possível porque ele possui uma estrutura hierarquizada aliada à técnica de controle por token (sinal). Por isso o módulo HTB consegue utilizar a tabela mangle do Netfilter (IPTABLES) marcando pacotes para um controle de tráfego mais afinado, sendo possível direcionar todo tipo de tráfego de uma rede para diferentes canais de controle do HTB, muito útil em diferentes tipos de tráfegos; é possível afirmar que o HTB, da mesma forma que o IPTABLES, executa seus serviços em tempo de kernel, proporcionando maior controle de todos os serviços que lhes são confiados.
    Mesmo utilizando várias opções de qdisc, o pfSense demonstrou nos testes, não possuir facilidade similar a de um RouterOS para controle de tráfegos individualizados, demonstrando sim, facilidade em controlar o tráfego por interface ou protocolo. Ao acessar o módulo, “Firewall > Trafic Shaper > By interface”, fica explicito o controle somente por interface nesta aba, já a aba “Limiter” aparentou ser a solução para o controle individualizado, podendo nela ser criadas várias queues, com diferentes velocidades, como é feito no RouterOS, mas não foi encontrada uma forma de aplicar as queues criadas. Assim, ficou clara a dificuldade que um administrador poderá encontrar ao tentar lidar com velocidades diferenciadas por hosts conectados, como é feito no sistema RouterOS de forma facilitada.
    Depois das exaustivas e frustradas tentativas, para conseguir um controle efetivo de tráfego utilizando o pfSense, o RouterOS conseguiu provar que consegue dinamizar a forma com que ele trata o QoS de tráfego da rede, podendo realizar controle de banda por host individualizado, ou seja, cada usuário que acessa a infraestrutura será colocado em uma Queue (fila) hierarquizada, e será feita a marcação dos pacotes utilizando, como aliado, a tabela mangle do iptables. Todo tráfego da rede é redesenhado em tempo real e de forma transparente. O usuário sequer percebe que a rede está sobre controle de QoS, sentindo somente a diferença na velocidade da navegação, mas nem imagina o que está acontecendo, porque a qdisc HTB possui controle total sobre o link, seja ele local ou de Internet.
    Outro detalhe muito importante é a manipulação do controle de banda na utilização do portal captive, no pfSense, ao serem realizadas alterações na velocidade em alguma das interfaces, todos os usuários são desconectados no momento em que é efetivada a modificação no sistema, precisando que todos autentiquem-se novamente a fim de continuar utilizando os serviços da rede.
    No RouterOS isso pode ocorrer ou não, e de forma transparente, mas somente serão afetadas as conexões dos usuários que estiverem sob o controle de trafic shaper, isso porque o RouterOS gerencia suas conexões ativas por meio de cookies, mantendo as conexões dos usuários ativas, até que expire o tempo de vida deles, de forma que quando forem feitas alterações na velocidade de um determinado usuário (host) e se desejar que o mesmo passe a utilizar a nova velocidade em tempo real, é preciso “derrubar” a conexão dele. Tão logo o usuário atualize sua sessão pressionando (F5) ou abrindo uma nova página em seu navegador de internet, o sistema verificará se o cookie ainda continua ativo. Se estiver, então o usuário é reinserido automaticamente na navegação, sem a necessidade de logar, senão, ele terá que logar novamente, como acontece no pfSense quando é realizadas alterações nas velocidades.
    Existem vários tipos de redes e cada uma delas possui uma necessidade especifica, ao gerenciar determinado tipo de serviço, precisando, as vezes, lançar mão de sistemas individuais (a parte), por conta da deficiência apresentada pelo sistema adotado, evitando assim que serviços vitais fiquem sem gerenciamento adequado.
    No caso do controle de banda de uma rede não é diferente, ficando claro que, dos sistemas testados, o RouterOS é o mais indicado, quando se trata de Trafic Shaper sendo, dentre as duas soluções, a mais adequada para controlar, efetivamente, a velocidade do tráfego do link de rede, mas é preciso definir qual cenário de rede realmente utilizará este tipo de controle. Em um provedor de acesso à internet, por exemplo, o pfSense não conseguiria controlar o tráfego individualizado com a precisão com que o RouterOS realiza.
    Sendo assim, no que diz respeito ao controle de banda, o RouterOS demonstrou ser uma ferramenta muito eficiente, na forma como ele trata o tráfego da rede, garantindo a eficácia na entrega da banda garantida, ou seja, aquilo que for definido é o que ele vai entregar com total fidelidade, podendo ser classificado como um sistema de alta qualidade para este serviço.

2.7 Módulos e Plugins
    O ponto que mais chama atenção no pfSense é a possibilidade de agregar serviços de redes ao sistema, facilitando a vida do administrador. Essas aplicações ficam na Internet em forma de módulos e/ou plugins, e o administrador pode, facilmente, instalá-los com apenas um clique, deixando o sistema mais robusto.
    Alguns dos programas disponíveis para instalação a qualquer momento estão a seguir:

• Aplicação para Proxy Cache
• Filtragem de pacotes
• Anti-Vírus Proxy
• Proxy Reverso
• IDS (Intrusion Detect System)
• Analisador de tráfego
• Geradores de relatórios de acessos
• Monitoramento de tráfego
• Servidores de autenticação e muitos outros.

    Para instalá-los basta acessar a Dashboard, escolher o módulo de sua preferência no menu e aguardar a instalação. É preciso que haja internet disponível para que sejam baixados e instalados, automaticamente, os módulos escolhidos.
    O sistema RouterOS, apesar de ser considerado um system stand alone. No teste, demonstrou muita dependência de serviços paralelos, por não possuir tais serviços ou por não tê-los com a qualidade esperada, como é o caso do web-proxy. Contudo, isso não é um problema para o pfSense.

2.8 Atualização do sistema
    Todo sistema, seja ele qual for, precisa estar sempre atualizado, ainda mais se tratando de firewalls de borda ou sistemas de segurança. Em geral, qualquer administrador de redes ou sistema precisa ter em mente que a atualização é o fator primordial para manter a segurança da rede em dia, evitando que brechas encontradas nas versões anteriores comprometa todo seu trabalho.
    Existem várias formas de atualizar o RouterOS. O mais comum é baixando uma ISO com a versão mais recente e reinstalar o sistema novamente. Todavia pode ocorrer que a licença da versão anterior não seja mais compatível com a nova versão instalada. Isso acontece ao atualizar a versão 3.x para as versões 4 ou 5.x, sendo necessário adquirir uma nova licença, sem falar que boa parte das configurações não são compatíveis entre essas versões, precisando descartar os backups e iniciar uma nova configuração, ou seja, será instalado e configurado tudo novamente.

-->

Os indivíduos podem seguir cada uma das melhores práticas de segurança recomendadas pelos especialistas, podem instalar cada produto de segurança recomendado e vigiar muito bem a configuração adequada do sistema e a aplicação das correções de segurança. Esses indivíduos ainda estarão completamente vulneráveis. (MITNICK; SIMON, 2003, p. 3).

   
    No pfSense é possível atualizá-lo sem muita dificuldade, pois ele mesmo fornece as atualizações e avisa quando fazê-las. Antes de iniciar qualquer atualização é preciso fazer o backup das configurações, evitando um retrabalho em caso de pane na atualização. O pfSense, como qualquer outro sistema, ao ser atualizado demanda algum tempo, porque a maioria dos administradores, geralmente, instala complementos como proxy-cache, analisador de tráfego dentre outros, e o pfSense precisa reinstalá-los para reutilizar as configurações já existentes para cada um deles. Apesar do tempo gasto na atualização do pfSense, é possível afirmar que as vantagens dele comparadas ao RouterOS são muito grandes, principalmente na questão que envolve pagamento de royalties, demostrando claramente o interesse financeiro, ao ter que adquirir novamente as licenças e refazer todas as configurações.

3. ANÁLISE DOS TESTES
    Ao analisar as características de cada um dos sistemas estudados, foi possível identificar benefícios que seriam úteis apenas em determinados tipos de redes; ficando claro que o sistema RouterOS é um sistema bastante competente na execução de determinados serviços, mas não executa com perfeição as principais tarefas, o que é possível quando se utiliza o pfSense; nesse caso o controle dos conteúdos acessados na Internet e o proxy-cache efetivo, sendo esse um dos principais pontos fracos do sistema da MikrotikLS, mas que o pfSense executa com eficiência.
Outro detalhe que chama atenção é que, inversamente, o pfSense não consegue controlar a banda do usuário de forma efetiva, como o RouterOS, que consegue um controle de qualidade e precisão, proporcionando a harmonia entre todas conexões ativas no link de Internet.
    É preciso considerar que os testes foram realizados, inicialmente em laboratório, e depois implementados em ambientes reais, proporcionando uma melhor avaliação das principais ferramentas que cada um dos sistemas possui. Inicialmente as duas redes, tanto a corporativa quanto a pública, utilizavam o sistema RouterOS na gerência dos recursos das redes, mas, após analisar as principais necessidades de cada rede, foi possível chegar a resultado como os apresentados nas imagens logo a seguir:

Gráf.1 – Análise do tráfego do link dedicado da Internet corporativa de 3MB, com controle de banda.Fonte: Própria.

  
    Então o RouterOS foi substituído, com a intenção de que o pfSense gerenciasse os recursos da rede com mais precisão do que o anterior, por possuir tais ferramentas avançadas de gerenciamento que o sistema da Mikrotik não dispunha. Foi possível então coletar o seguinte resultado apresentado no gráfico abaixo. Uma observação: o resultado que o gráfico apresenta, é referente à configuração do pfSense, utilizando somente o controle de banda por interface e o resultado não foi favorável em relação ao traffic shaper.

Gráf.2 – Análise do tráfego do link dedicado da Internet corporativa de 3MB, somente com controle de conteúdo.Fonte: Própria.

    Por isso, foi realizada a instalação dos módulos SquidGuard, para filtrar conteúdos pesados, e squid-proxy, para armazenar conteúdos já acessados pelos usuários na rede, visando a redução o Throughput do link dedicado, para assim poder analisar a possíbilidade de manter o pfSense como sistema principal de gestão da rede corporativa, mesmo sem um controle de banda efetivo.

    E assim foi possível obter um resultado favorável, como se vê no gráfico abaixo.

Gráf.3 - Estatística das interfaces, com ênfase para placa do link local, que chega dar picos de 60Mbps quando os dados que já estão em cache são entregues pelo squid, aliviando o link de Internet de 3Mbps.
Fonte: Própria.

Fig.3 – Diagrama simplificado da rede local corporativa, utilizando o pfSense para proxy cache.Fonte: Própria utilizando o software livre DIA.

    

    O diagrama acima mostra o fluxo dos pacotes em vários contextos de acesso, demonstrando um aumento considerável no trafego da interface da LAN, causado pelos acessos diretos ao conteúdo do cache já armazenado, evitando que objetos (conteúdos) fossem buscados diretamente na Internet, consequentemente, desafogando o link corporativo.
    Ficou claro que não era necessário um controle da banda, mas sim, de um controle efetivo de todo conteúdo que era acessado na rede corporativa. Após uma breve análise dos acessos realizados na rede, utilizando relatórios gerados no Sarg (gerador de relatórios), chegou-se ao fato de que os funcionários passavam mais de 60% do tempo acessando sites de downloads, baixando grandes arquivos, como filmes e executáveis, passando também bastante tempo acessando redes sociais, sites de streaming (canal que transmite fluxo contínuo de áudio e vídeo) como youtube, fazendo com que o throughput (Taxa de transmissão) do link de Internet ficasse sempre saturado, a ponto de atrapalhar aqueles que realmente precisavam acessar informações relevantes e necessárias para executar os serviços pertinentes à instituição, como era o caso do acesso ao webmail corporativo e as aplicações on-line.
    Na rede de acesso público, o caso foi totalmente inverso. Baseando-se nos testes e implementações realizadas na rede corporativa, foi possível tomar a decisão de que não era possível implementar o pfSense, por causa da sua deficiência em controlar a banda do usuário individualmente, o que é considerado o controle de banda o ponto chave deste modelo de rede, por se tratar de venda de serviço preestabelecido e que o usuário ao adquire tal serviço, paga o valor baseado na velocidade contratada, sendo então impossível o controle de conteúdo, neste modelo de rede.

    Gráf.4 – Análise do tráfego do link VDSL de 35MB gerenciado pelo Mikrotik.
Fonte: Própria

    Os resultados dos testes podem ser observados na forma de gráficos e capturas de telas dispostos no APÊNDICE B.

    Logo, o pfSense foi implementado na rede corporativa, substituindo o RouterOS após os estudos feitos em laboratório, antecipando os possíveis impactos que poderia causar e também os benefícios que traria nas duas infraestruturas. Logo após a substituição do antigo sistema, e análises comparativas, foi observado um melhor aproveitamento do link com o pfSense na gestão da rede na instituição, o que não ocorria na gestão com o Mikrotik, mesmo utilizando o seu excelente controle de banda. Com a redução do consumo do link, os e-mails corporativos e as aplicações onlines passaram a funcionar como deveriam; as reclamações cessaram por parte dos usuários que se preocupavam com os serviços pertinentes à instituição, mas iniciaram-se outros tipos de reclamações, principalmente em relação a determinados tipos de conteúdo, que não era mais possível ser acessado, como downloads diversos, que não era possível sem previa autorização do responsável pelo setor. Não era possível acessar sites com conteúdo de streaming. Toda implementação foi previamente autorizada pela administração da instituição, a fim de tentar resolver de vez a questão dos problemas causados pela falta do controle da rede, o que de certa forma foi resolvido somente controlando o conteúdo que os usuários acessavam. Já era possível também validar a navegação dos mesmos, com os relatórios dos logs do squid, podendo ser apresentado à diretoria como forma de relatório do conteúdo acessado na Internet, se assim fosse solicitado.
    O pfSense demonstrou grande capacidade para resolver a deficiência do tráfego da rede corporativa, sem a utilização de um controle de banda efetivo neste modelo de rede.
    Já na rede pública não houve alterações, mantendo o RouterOS como sistema principal deste modelo de rede, onde o pfSense entraria somente como um servidor paralelo para gerenciar o cache efetivo desta rede. Como o sistema da MikrotikLS possui um controle de tráfego eficiente, e não havendo a possibilidade de um controle de conteúdo, faltava um sistema que realizasse o serviço de proxy-cache para dar apoio ao link de Internet, entregando objetos já armazenados em cache, antes que fossem buscados na Internet, o que aumentaria a sensação de velocidade para o usuário final e evitaria possíveis saturações no link do provedor, então, é aí que entraria o pfSense.
  
4. CONCLUSÃO
    Podemos concluir que a escolha de um sistema depende muito do modelo da rede a ser gerenciada. É possível afirmar que um sistema pode muito bem complementar o outro, como por exemplo, O pfSense poderia utilizar o controle de banda do RouterOS, para elevar, ainda mais, o nível dos serviços da rede corporativa, garantindo um maior aproveitamento do link e dos serviços de rede num contexto geral. Já o RouterOS da rede pública, poderia utilizar todo potencial que o pfSense tem a oferecer, aproveitando recursos que complementariam suas deficiências, como a falta de um proxy-cache efetivo, o serviço de voucher, o gerador de relatórios dos acessos realizados. Concluimos ser esse um serviço de grande importância em redes de acesso a Internet do tipo pública, principalmente quando são requisitados por meio de ordem judicial, relatórios dos acessos realizados pelos clientes na rede, para utilização em investigações de possíveis crimes virtuais.
    Existem muitos pontos positivos nos dois sistemas, que somados só tem a oferecer benefícios a qualquer infraestrutura de rede, mas isso vai depender da necessidade de cada uma delas. Em casos como da rede corporativa, bastou a utilização do pfSense com seus recursos para que o link dedicado de 3MB fosse suficiente para 25 acessos simultâneos, apenas controlando os conteúdos pesados que trafegavam na rede, como: downloads de vídeos, imagens, programas e principalmente a grande audiência dos vídeos onlines, o que não estava sendo suficiente com o RouterOS e seu controle de banda.
    Já em uma rede de Internet do tipo público, onde não é possível controlar o conteúdo acessado, por se tratar de serviço pago, inviabiliza a utilização unicamente do pfSense como sistema gestor da rede, mantendo o Mikrotik como sistema principal de gerenciamento da rede de acesso público, por controlar o tráfego individualizado de forma precisa para os 20 acessos simultâneos. O que poderia ser feito, neste caso, ao invés de substituir o RouterOS, era utilizar o pfSense em paralelo para fazer o cache efetivo dos acessos realizados, aliviando assim o link nos momentos de pico, quando necessário.

REFERÊNCIAS

BABCOCK, Charles: Cronica - O maior software de todos os tempos. Disponível em: <www.fug.com.br/content/view/138/60/> Acesso em: 28 abr 2012.

BUECHLER , Christopher M.; PINGLE, Jim. (no prelo) Livro digital, pfSense: The Definitive Guide, 2009

COELHO, Vinícios Teixeira. QoS. Disponível em: <projetos.inf.ufsc.br/arquivos_projetos/projeto_819/RascunhoRelatoriov0.2-Vinicius_Teixeira_Coelho.pdf> Acesso em: 04 mai 2012.

COMUNIDADE PFSENSE. O que é o pfsense. Disponível em: <www.pfsense-br.org/blog/o-que-e-o-pfsense/> Acesso em: 27 abr 2012.

FÓRUM PFSENSE. Resolução do problema de instalação. Disponível em: <forum.pfsense.org/index.php?topic=31907.0> Acesso em: 05 de abr de 2012.

FREEBSD. Licença. Disponível em: <www.freebsd.org/copyright/freebsd-license.html> Acesso em: 03 de abr de 2012.

______. Relatório Revisional Analítico sobre a Pilha TCP/IP. Disponível em: <www.freebsdbrasil.com.br/fbsdbr_files/File/public_docs/melhorias-stack-rede.pdf> Acesso em: 25 abr 2012.

FREE SOFTWARE MAGAZINE: Entrevista. Disponível em: <www.freesoftwaremagazine.com/articles/interview_with_jeff_starkweather_chris_buechler_and_scott_ullrich> Acesso em: 07 mar 2012.

JAMHOUR, Edgard. Slide Acadêmico Mestrado. Disponível em: <www.ppgia.pucpr.br/~jamhour/Pessoal/Mestrado/TARC/QoSLinux.pdf> Acesso em: 07 mai 2012.

LIMA, Luísa e Vilela, João. Mecanismos de escalonamento de pacotes. Disponível em: <www.dcc.fc.up.pt/~pbrandao/aulas/0405/TAR/relatorios/0304-t2-scheduling.pdf> Acesso em: 10 abr 2012.

MIKROTIKLS. Licença. disponível em: <demo.mt.lv/help/license.html> Acesso em: 03 fev 2012.

MIKROTIKLS. Trafic Shapper com HTB. Disponível em: <wiki.mikrotik.com/wiki/Manual:HTB>Acesso em: 03 mai 2012.

MITINIK, Kevin; SIMON, William. ROQUE, Katia Aparecida. A Arte de Enganar: São Paulo, 2003.

OLIVEIRA, José Geraldo. Qos transparente com GNU/Linux. Disponível em: <www.ginux.ufla.br/files/mono-JoseOliveira.pdf> Acesso em: 05 mai 2012.

PUC – RIO. Algoritmo de enfileramento. Disponível em: <www.maxwell.lambda.ele.puc-rio.br/7583/7583_4.PDF> Acesso em: 02 mai 2012.

MULTICS. Histórico. Disponível em: <http://www.pop-rs.rnp.br/ovni/unix/history.html> Acesso em: 26 mai. 2012.

______. História. Disponível em: <http://www.multicians.org/history.html> Acesso em: 27 mai. 2012.

UNIX. História do Unix e sua evolução. Disponível em: <http://cm.bell-labs.com/cm/cs/who/dmr/hist.html>  Acesso em: 27 mai. 2012.