Sistema de controle centralizado para access points de baixo custo

(1)

Instituto Federal de Educação, Ciência e Tecnologia Fluminense

Davi da Silva Martins Nilo Hermes Neto

Sistema de controle centralizado para access points de baixo custo

Campos dos Goytacazes-RJ

Junho de 2022

(2)

Davi da Silva Martins Nilo Hermes Neto

Sistema de controle centralizado para access points de baixo custo

Trabalho de Conclusão apresentado ao curso Bacharelado em Engenharia da Computa- ção do Instituto Federal de Educação, Ci- ência e Tecnologia Fluminense, como parte dos requisitos para a obtenção do título de Bacharel em Engenharia da Computação.

Instituto Federal de Educação, Ciência e Tecnologia Fluminense

Orientador: M.Sc. Vinícius Barcelos da Silva Coorientador: M.Sc. Tiago Gomes da Silva Ribeiro

Luís Gustavo Sales de Souza França

Campos dos Goytacazes-RJ

Junho de 2022

(3)

Biblioteca Anton Dakitsch CIP - Catalogação na Publicação

Elaborada pelo Sistema de Geração Automática de Ficha Catalográfica da Biblioteca Anton Dakitsch do IFF com os dados fornecidos pelo(a) autor(a).

M386s

Martins, Davi da Silva

Sistema de controle centralizado para access points de baixo custo / Davi da Silva Martins, Nilo Hermes Neto - 2022.

68 f.: il. color.

Orientador: Vinícius Barcelos da Silva Coorientador: Tiago Gomes da Silva Ribeiro

Trabalho de conclusão de curso (graduação) -- Instituto Federal de Educação, Ciência e Tecnologia Fluminense, Campus Campos Centro, Curso de Bacharelado em Engenharia de Computação, Campos dos Goytacazes, RJ, 2022.

Referências: f. 66 a 68.

1. Controlador wireless. 2. Redes sem fio. 3. OpenWrt. I. Hermes Neto, Nilo. II. Silva, Vinícius Barcelos da, orient. III. Título.III. Ribeiro, Tiago Gomes da Silva, coorient. IV. Título.

(4)

MINISTÉRIO DA EDUCAÇÃO

SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL FLUMINENSE

CAMPUS CAMPOS CENTRO

RUA DOUTOR SIQUEIRA, 273, PARQUE DOM BOSCO, CAMPOS DOS GOYTACAZES / RJ, CEP 28030130 Fone: (22) 2726-2903, (22) 2726-2906

TERMO 7/2022 - CBECCC/DIRESTBCC/DGCCENTRO/REIT/IFFLU

6 de julho de 2022

Davi da Silva Martins Nilo Hermes Neto

Trabalho de conclusão de curso apresentado ao Ins tuto Federal Trabalho de conclusão de curso apresentado ao Ins tuto Federal de Educação, Ciência e Tecnologia Fluminense como requisito de Educação, Ciência e Tecnologia Fluminense como requisito parcial para conclusão do curso de Bacharelado em Engenharia parcial para conclusão do curso de Bacharelado em Engenharia da Computação.

da Computação.

Aprovado em 02 de Junho de 2022.

Banca Avaliadora:

M.Sc. Vinicius Barcelos da Silva (Orientador) / IFF M.Sc. Vinicius Barcelos da Silva (Orientador) / IFF

D.Sc. Fernando Luiz de Carvalho e Silva (Examinador) / IFF D.Sc. Fernando Luiz de Carvalho e Silva (Examinador) / IFF M.Sc. David Vasconcelos Correa da Silva (Examinador) / IFF M.Sc. David Vasconcelos Correa da Silva (Examinador) / IFF M.Sc. Tiago Gomes da Silva Ribeiro (Examinador) / IFF M.Sc. Tiago Gomes da Silva Ribeiro (Examinador) / IFF

Brasil Brasil 2022 2022

Código Verificador:

Código de Autenticação:

Documento assinado eletronicamente por:

David Vasconcelos Correa da Silva

David Vasconcelos Correa da Silva , PROFESSOR ENS BASICO TECN TECNOLOGICOPROFESSOR ENS BASICO TECN TECNOLOGICO, COORDENACAO DO CURSO TECNICO EM INFORMATICACOORDENACAO DO CURSO TECNICO EM INFORMATICA, em 06/07/2022 10:36:09.

Tiago Gomes da Silva Ribeiro

Tiago Gomes da Silva Ribeiro, TEC DE TECNOLOGIA DA INFORMACAOTEC DE TECNOLOGIA DA INFORMACAO , COORDENAÇÃO DE ADMINISTRAÇÃO DE REDESCOORDENAÇÃO DE ADMINISTRAÇÃO DE REDES, em 06/07/2022 10:31:38.

Fernando Luiz de Carvalho e Silva

Fernando Luiz de Carvalho e Silva, PROFESSOR ENS BASICO TECN TECNOLOGICOPROFESSOR ENS BASICO TECN TECNOLOGICO, COORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DACOORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO

COMPUTAÇÃO, em 06/07/2022 10:30:21.

Vinicius Barcelos da Silva

Vinicius Barcelos da Silva , PROFESSOR ENS BASICO TECN TECNOLOGICOPROFESSOR ENS BASICO TECN TECNOLOGICO, COORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃOCOORDENAÇÃO DO CURSO DE BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO, em 06/07/2022 10:27:09.

Este documento foi emi do pelo SUAP em 06/07/2022. Para comprovar sua auten cidade, faça a leitura do QRCode ao lado ou acesse https://suap.iff.edu.br/autenticar-documento/ e forneça os dados abaixo:

369809 354405ca3c

TERMO 7/2022 - CBECCC/DIRESTBCC/DGCCENTRO/REIT/IFFLU | Página 1 de 2

(5)

TERMO 7/2022 - CBECCC/DIRESTBCC/DGCCENTRO/REIT/IFFLU | Página 2 de 2

(6)

AGRADECIMENTOS

Acima de tudo, a Deus pelo dom da vida e pela conclusão deste projeto.

Aos nossos familiares, que nos incentivaram nos momentos difíceis e compreenderam nossa ausência enquanto nos dedicávamos à realização deste trabalho.

À Diretoria de Tecnologia da Informação e Comunicação (DTIC), na pessoa do Marcelo Pereira de Abreu, Tiago Gomes da Silva Ribeiro, Luis Gustavo Sales de Souza França e demais colaboradores que participaram direta ou indiretamente do desenvolvimento deste trabalho de pesquisa, pela oportunidade ofertada, onde conseguimos dar início a esse projeto.

Ao nosso professor e orientador Vinícius Barcelos que apesar da intensa rotina de sua vida acadêmica aceitou o desafio de nos orientar nesta monografia. As suas valiosas indicações fizeram muita diferença.

Aos professores, por todos os conselhos, pela ajuda e pela paciência com a qual guiaram nosso aprendizado.

Aos nossos amigos, Luidi Matheus Silva de Oliveira e Lucas Freitas da Rocha que cooperaram conosco no início dessa pesquisa.

Aos colegas de curso, pelo companheirismo e pela troca de experiências que nos permitiram crescer não só como pessoa, mas também como formandos.

Ao Instituto Federal FluminensecampusCampos centro, essencial no nosso processo de formação profissional e por tudo o que aprendemos ao longo dos anos do curso.

Dedicamos este trabalho aos nossos pais, Rogério dos Santos Martins, Luciana Amaral da Silva Martins, Dilomarcia de Azevedo Montezuma e Eduardo da Silva Hermes, e aos nossos irmãos, Matheus da Silva Martins, Monique Montezuma Hermes e João Pedro Abreu Hermes.

(7)

RESUMO

Com o rápido desenvolvimento e o avanço dos sistemas de informação e comunicação, as tecnologias de rede sem fio (wireless) têm sido amplamente utilizadas, buscando sempre uma melhoria no atendimento das necessidades dos usuários e, principalmente, na transparência de sua implementação, com a melhor qualidade possível. Em ambientes com considerável número de usuários, como empresas e instituições de ensino, um único ponto de acesso comum não é capaz de atender as necessidades de todos os usuários. Sendo necessária a utilização de vários pontos de acesso tradicionais que são gerenciados de forma individual ou a utilização de pontos de acesso mais sofisticados, com uma controladora proprietária, que tenham maior alcance e capacidade de suportar um número maior de usuários. A primeira solução, dependendo da quantidade de pontos de acesso utilizados, se torna inviável devido à dificuldade de gerenciá-los. A segunda solução, resolve o problema da primeira, porém exige um investimento alto para implementação, além da limitação com relação aos dispositivos compatíveis. Neste intuito, o projeto tem como objetivo desenvolver um software que atuará como controladora de access points de baixo custo, permitindo implementar e gerenciar de forma centralizada uma infraestrutura de rede sem fio, utilizando o padrão IEEE 802.11, considerando as seguintes características:

economicidade, usabilidade, escalabilidade e flexibilidade. A solução proposta é capaz de gerenciar, controlar e monitorar de forma centralizada pontos de acesso de várias redes distintas, localizadas no mesmo ambiente ou não. Além disso, o software controlador em questão não está limitado a apenas um modelo de ponto de acesso, sendo compatível com vários modelos de diversas marcas, bastando apenas que os mesmos suportem a instalação do firmware Openwrt.

Palavras-chaves: Controlador wireless, redes sem fio, OpenWrt.

(8)

ABSTRACT

With the quickly development and advancement of information and communication systems, wireless network technologies have been vastly studied, always looking for an improvement in meeting the needs of users and, mainly, in the transparency of their implementation, with the best possible quality. In environments with a considerable number of users, such as companies and educational institutions, a single common access point is not able to meet the needs of all users, requiring the use of several traditional access points that are managed individually or the use of more sophisticated access points, with a proprietary controller, which have greater range and capacity to support a greater number of users.

The first solution, depending on the number of access points used, becomes impracticable due to the difficulty of managing them. The second solution solves the problem of the first one, but it requires a high investment for implementation, in addition to the limitation regarding compatible devices. To this end, the project aims to develop software that will act as a controller for low-cost access points, allowing the centralized implementation and management of a wireless network infrastructure, using the IEEE 802.11 standard, considering the following characteristics: low cost of installation, ease of administration, scalability and flexibility. The proposed solution is able to centrally managing, controlling and monitoring access points from several different networks, which may or may not be in the same environment. In addition, the controller software in question is not limited to just one access point model, being compatible with several models from different brands, as long as they support the installation of Openwrt firmware.

Keywords: Wireless controller, Wireless network, Openwrt.

(9)

LISTA DE FIGURAS

Figura 1 – Demonstração da sobreposição dos canais na faixa 2,4GHz . . . 7

Figura 2 – Arquitetura de rede da solução proposta . . . 18

Figura 3 – Representação da forma de comunicação do controlador por meio de APIs 20 Figura 4 – Diagrama casos de uso do controlador . . . 24

Figura 5 – Diagrama casos de uso para gerenciar pontos de acessos ou grupos . . . 25

Figura 6 – Diagrama casos de uso para enviar requisições . . . 27

Figura 7 – Diagrama casos de uso para gerenciar clientes conectados . . . 27

Figura 8 – Diagrama casos de uso para gerenciar usuários . . . 28

Figura 9 – Diagrama casos de uso para visualizar logs . . . 29

Figura 10 – Diagrama de classes . . . 30

Figura 11 – Roteador wireless usado como ponto de acesso . . . 35

Figura 12 – Comando para rodar script de instalação no ponto de acesso . . . 36

Figura 13 – Arquivos criados após a execução do instalador . . . 37

Figura 14 – Tarefas agendadas no ponto de acesso . . . 37

Figura 15 – Demonstração de execução do script send.sh . . . 38

Figura 16 – Estrutura de arquivos do controlador . . . 41

Figura 17 – Serviço do controlador sendo iniciado em modo de desenvolvimento . . 41

Figura 18 – Servidor em execução exibindo os registros de atividades (logs). . . 42

Figura 19 – Tela de login do controlador . . . 43

Figura 20 – Tela de gerenciamento do pontos de acesso . . . 44

Figura 21 – Tela de gerenciamento dos clientes que estão aos APs controlados pelo servidor . . . 44

Figura 22 – Tela de gerenciamento dos grupos utilizados para organização dos APs 45 Figura 23 – Tela de gerenciamento dos usuários habilitados para utilizar o controlador 46 Figura 24 – Tela de visualização dos logs do servidor . . . 47

Figura 25 – Tela exibindo informações sobre o cadastro do usuário . . . 48

(10)

LISTA DE TABELAS

Tabela 1 – Comparativo soluções proprietárias . . . 11 Tabela 2 – Comparativo soluções proprietárias e livre . . . 48

(11)

LISTA DE SIGLAS

ACI Adjacent Channel Interference AES Advanced Encryption Standard

AP Access Point

API Application Programming Interface CCI Co-Channel Interference

IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol

IPV4 Internet Protocol Version 4 IPV6 Internet Protocol Version 6 JSON JavaScript Object Notation

JWT JSON WEB TOKEN

LAN Local Area Network MAC Medium Acesss Control NAT Network Address Translation PHY Physical Layer

OSI Open Systems Interconnection

RADIUS Remote Authentication Dial-In User Service RNP Rede Nacional de Ensino e Pesquisa

SGDB Sistema de Gerenciamento de Banco de Dados SSID Service Set Identifier

SCIFI Sistema de Controle Inteligente para redes sem Fio SQL Structured Query Language

QOS Quality of Service

(12)

OCI Oracle Cloud Infrastructure TFTP Trivial File Transfer Protocol), UI User Interface

UFF Universidade Federal Fluminense VPN Virtual Private Network

WEP Wired Equivalent Privacy WI-FI Wireless Fidelity

WLAN Wireless Local Area Network

WPA2E WiFi Protected Access 2 - Enterprise WPA-2 WiFi Protected Access 2

(13)

SUMÁRIO

Sumário . . . . xii

Contents . . . xiv

1 INTRODUÇÃO . . . . 1

1.1 Justificativa . . . 2

1.2 Objetivos . . . 2

1.2.1 Objetivo Geral . . . 2

1.2.2 Objetivos Específicos . . . 2

2 FUNDAMENTAÇÃO TEÓRICA . . . . 4

2.1 Redes de computadores . . . 4

2.1.1 Redes sem fio 802.11 . . . 4

2.1.1.1 Access point (AP) . . . 6

2.1.1.2 Ruído e Interferência em Redes Sem Fio . . . 7

2.1.2 Redes sem fio com controlador . . . 8

2.2 APIs . . . 8

3 SOLUÇÕES EXISTENTES . . . 10

3.1 Soluções Proprietárias . . . 10

3.1.1 WiseFi e Tanaza . . . 10

3.1.2 Unifi Network Controller . . . 10

3.1.3 Comparativo entre custos de implementação das soluções proprietárias . . . 11

3.2 Soluções livres . . . 12

3.2.1 SCIFI . . . 12

3.2.2 Diferenças entre SCIFI e a solução proposta neste trabalho . . . 12

(14)

4 TECNOLOGIAS UTILIZADAS . . . 14

4.1 OpenWrt. . . 14

4.2 Shell script . . . 14

4.3 Node.js. . . 14

4.4 React.js . . . 15

4.5 MySQL. . . 15

4.6 Oracle Cloud . . . 16

4.7 Basic Authentication HTTP . . . 16

4.8 Autenticação JWT . . . 16

4.9 JSON. . . 17

5 SOLUÇÃO PROPOSTA . . . 18

5.1 O projeto . . . 18

5.1.1 Arquitetura da rede . . . 18

5.1.2 Comunicação com o Controlador . . . 19

5.2 Análise e documentação . . . 21

5.2.1 Requisitos Funcionais . . . 21

5.2.2 Requisitos Não Funcionais . . . 22

5.2.3 Diagrama de casos de uso . . . 23

5.2.3.1 Gerenciar pontos de acesso ou grupos . . . 24

5.2.3.2 Enviar requisições com informações do dispositivo . . . 25

5.2.3.3 Gerenciar clientes conectados . . . 27

5.2.3.4 Gerenciar usuários . . . 28

5.2.3.5 Visualizar log . . . 28

5.2.4 Diagrama de classes . . . 29

5.3 Implementação e resultados . . . 32

5.3.1 Ponto de acesso wireless . . . 32

5.3.2 Controlador . . . 39

5.3.3 Intarface Web . . . 42

5.3.3.1 Pontos de acesso . . . 43

5.3.3.2 Clientes conectados . . . 44

5.3.3.3 Grupos. . . 45

5.3.3.4 Usuários . . . 45

5.3.4 Logs . . . 46

5.3.5 Meus dados e menus . . . 47

5.4 Avaliação dos Resultados . . . 48

6 CONCLUSÃO . . . 50

6.1 Trabalhos Futuros . . . 50

(15)

REFERÊNCIAS . . . 52

(16)

1

1 INTRODUÇÃO

O termo wireless, traduzido para o português, significa "sem fio", e representa qualquer forma de comunicação, entre dispositivos, onde as informações são transmitidas pelo ar via ondas eletromagnéticas, dispensando o uso de conexões físicas, podendo esses dispositivos estarem a metros ou a quilômetros de distância um do outro.

Existe uma tendência moderna de se implantar cada vez mais as redes sem fio ao invés de redes com fio. Este fato é motivado tanto por aspectos da inviabilidade da instalação de redes cabeadas em determinados ambientes, como pelo barateamento dos equipamentos sem fio e da interoperabilidade oferecida pelas tecnologias wireless (MACHADO et al., 2011).

Outros fatores relacionam-se com as facilidades de mobilidade e flexibilidade que as comunicações sem fio oferecem. A progressiva diminuição de custo aliada ao crescente uso de dispositivos móveis têm criado enorme demanda para a instalação de infraestrutura de redes sem fio.

Com o aumento do número de usuários e a necessidade de cobrir grandes áreas físicas, é necessário também aumentar o número de pontos de acesso para atendê-los de forma a manter os requisitos tanto de cobertura como de banda disponível. Em ambientes com considerável número de usuários, como empresas e instituições de ensino, um ponto de acesso (AP - do inglês Access Point) comum, em geral, não é capaz de atender as necessidades de todos os usuários. Nesse contexto, duas soluções convencionais podem ser utilizadas: (1) a utilização de vários pontos de acessos que são gerenciados individualmente, tornando a administração da rede um processo árduo; (2) uso de pontos de acesso mais sofisticados que tenham maior alcance e capacidade de suportar um número maior de usuários com uma controladora proprietária, que geralmente apresentam custos elevados para este tipo de ambientes.

A primeira solução citada, em geral, apresenta baixo custo, porém há problemas no gerenciamento dos pontos de acesso que, por ser individual, pode exigir elevados esforços e baixo desempenho dependendo da quantidade de equipamentos utilizados e também problemas na qualidade do sinal, já que o sinal de um ponto de acesso pode interferir na qualidade do sinal de outros pontos próximos, pois não há um controle centralizado que impeça a má utilização espectral. A segunda solução evita o problema da interferência do sinal e facilita o gerenciamento da rede, porém possui custo muito elevado para as organizações.

(17)

Capítulo 1. INTRODUÇÃO 2

1.1 JUSTIFICATIVA

Tendo em vista o elevado custo das soluções comerciais, a variedade de fabricantes de pontos de acesso com sistemas heterogêneos e o contexto apresentado, percebe-se a necessidade de uma solução de custo aceitável, flexível e escalável, que possibilite o gerenciamento centralizado dos pontos de acesso em ambientes com alta demanda de cobertura geográfica.

A solução proposta será capaz de controlar e monitorar redes sem fio em larga escala composta por pontos de acesso de baixo custo, a fim de minimizar a interferência excessiva entre os pontos de acesso e tornar dinâmica e automática a configuração de novos APs, facilitando o gerenciamento da rede e reduzindo consideravelmente o custo para implementação e controle da mesma. O grande diferencial do sistema é o fato de ele ser muito flexível em relação aos pontos de acesso compatíveis, partindo de modelos mais simples até os mais robustos, desde que suportem a substituição do firmware da original da fabricante pelo firmware OpenWrt (sistema embarcado baseado em Linux). Além disso, devido a esta flexibilidade de hardwares disponíveis, até mesmo dispositivos wireless mais antigos, que dependendo da situação seriam descartados, por meio desta solução podem ser reaproveitados adequadamente, gerando mais economia para a instituição e contribuindo para a preservação do meio ambiente.

1.2 OBJETIVOS

1.2.1 Objetivo Geral

O projeto tem como objetivo desenvolver umsoftware que atuará como controlador de access points de baixo custo que permite implementar e gerenciar de forma centralizada uma infraestrutura de rede sem fio, utilizando o padrão IEEE 802.11, que ofereça as principais funcionalidades existentes em soluções proprietárias e possua as seguintes características: baixo custo de instalação, facilidade de administração, escalabilidade e flexibilidade.

1.2.2 Objetivos Específicos

Dentre os objetivos específicos deste trabalho pode-se destacar:

• Avaliação do cenário inicial e da viabilidade de execução da solução proposta;

• Selecionar e instalar fisicamente os pontos de acesso que melhor se adequam a solução proposta;

(18)

Capítulo 1. INTRODUÇÃO 3

• Alterar ofirmware dos pontos de acesso com um sistema open source customizado baseado em Linux;

• Desenvolver um sistema (controlador) para gerenciar de forma centralizada os pontos de acesso;

• Desenvolver scripts para comunicação dos AP’s com o controlador;

• Desenvolver uma interface web para interação do usuário administrador da rede com o sistema desenvolvido;

• Testar e validar a solução proposta;

• Comparar os resultado com o cenário inicial e verificar o impacto da solução;

(19)

4

2 FUNDAMENTAÇÃO TEÓRICA

O presente capitulo está dedicado ao detalhamento dos conceitos teóricos, utilizados como base para o desenvolvimento da solução proposta, na visão de diferentes autores.

2.1 REDES DE COMPUTADORES

2.1.1 Redes sem fio 802.11

O IEEE 802.11 é uma norma desenvolvida pelo IEEE (Institute of Electrical and Electronics Engineers) que define um padrão internacional para WLAN (Wireless Local Area Network). Ela pertence a família IEEE 802, que engloba uma série de especificações tecnológicas para redes locais, LAN ( Local Area Network). Especificações IEEE 802 abrangem as duas camadas mais baixas do modelo OSI (Open Systems Interconnection), incorporando componentes das camadas física e de enlace. Todas as redes 802 possuem os componentes MAC (Medium Access Control) e PHY (Physical Layer). O MAC engloba um conjunto de regras que determinam como se dá o acesso ao meio para o envio de dados, enquanto o PHY se encarrega dos detalhes da transmissão e recepção.Este tipo de rede é comumente chamada de Wi-Fi (BALBI, 2012).

De acordo com Tanenbaum (2011), essas redes são compostas de clientes, que são os usuários, geralmente tratados como estações móveis, e infraestrutura chamada pontos de acesso, ou APs (Access Points). Toda comunicação entre os clientes passa por um ponto de acesso, e este, por sua vez, se conecta à rede com fios.

Segundo Balbi (2012), Uma rede IEEE 802.11 é constituída por um conjunto de estações que podem se comunicar umas com as outras, tal norma possibilita que, através do agrupamento de várias estações seja possível cobrir grandes áreas.

Além das características citadas, o padrão 802.11 também define quais os tipos de serviços essas redes devem fornecer ao clientes. Tanenbaum (2011) caracteriza esses serviços como:

Associação, responsável por viabilizar a conexão das estações móveis com os access points. Sempre que uma estação entra no raio de alcance de rádio do AP esse serviço é executado, nesse processo a estação descobre a identidade, recursos, tais como taxa de dados admitidas e padrões de segurança, e envia um pedido de associação ao AP que pode aceitar ou rejeitar o pedido;

(20)

Capítulo 2. FUNDAMENTAÇÃO TEÓRICA 5

Reassociação, recurso muito utilizado nas redes 802.11 que possuem mais de um access point, onde as estações móveis se deslocam do raio de alcance de um AP para outro da mesma rede, processo denominado de handoff. A finalidade desse serviço é reduzir a perda de dados que pode ser gerada nesse processo;

Autenticação, responsável por determinar quais estações podem enviar quadros e ter acesso à rede sem fio, essa restrição pode ser feita com o uso de credenciais de acesso e métodos de segurança, que segundo MORAES (2010), são implementadas de acordo com o subconjunto 802.11i, nele são definidos parâmetros de identificação, segurança e criptografia, dos quais podemos destacar:

• Quanto a identificação

– SSID (Service Set Identifier)

Basicamente é um nome responsável por identificar uma rede sem fio, ele é adicionado ao cabeçalho de todos os pacotes que pertencem àquela específica.

Baseado nisso, os access points divulgam para as estações que estão dentro do seu alcance o seu SSID, estas, por sua vez, utilizam justamente este atributo para diferenciar uma rede da outra. Vale ressaltar que podem existir múltiplos APs na mesma rede com o mesmo SSID (MORAES, 2010).

• Quanto aos métodos de autenticação – Aberto ou Livre

Esquema de segurança que não exige credenciais para autenticação, qualquer estação pode associar-se e ter acesso à rede do AP (TANENBAUM,2011).

– WEP (Wired Equivalent Privacy)

Um dos primeiros métodos de autenticação com uso de credenciais cujo intuito original era fornecer o mesmo nível de confidencialidade de uma rede cabeada tradicional, no entanto, falhou neste aspecto e caiu em desuso por apresentar algumas vulnerabilidades referentes a chave criptográfica utilizada por ele (MORAES, 2010).

– WPA2 (WiFi Protected Access 2)

Modelo de segurança que exige credencias para autenticação, surgiu como solução para os problemas de vulnerabilidade apresentados pelo WEP, pode funcionar de duas formas diferentes, Personal Mode, utiliza uma chave previa- mente compartilhada, a senha, e Enterprise Mode, tipo de autenticação onde o AP se comunica com um banco de dados de nomes de usuários e senha para decidir quem pode ter acesso à rede (MORAES, 2010).

(21)

Distribuição, responsável por determinar como os quadros serão roteados pelo meio físico, pelo ar ou pelo cabo diretamente conectado, o que vai determinar isso é o meio que a origem e o destino dos quadros estão conectados.

Integração, serviço que trata das traduções necessárias para que um quadro seja enviado fora da rede 802.11 ou para chegar de fora dela, por exemplo, conectar uma rede wireless à Internet.

Entrega de dados, serviço responsável por permitir que as estações enviem e recebam dados utilizando os protocolos de comunicação, como o Ethernet.

2.1.1.1 Access point (AP)

Um Access point ou ponto de acesso traduzindo para o português é um dispositivo muito utilizado, principalmente em empresas, para permitir os dispositivos sem fio se conectarem a uma rede cabeada (CISCO,2019). O equipamento é conectado a um roteador ou switch e distribui o sinal via wireless na outra ponta. Dessa forma, é possível que equipamentos sem fio tenham acesso a rede LAN de um determinado ambiente, facilitando a expensão da cobertura e evitando gastos adicionais com instalação de cabeamento.

OAccess point pode ter 3 tipos de configurações:

• Access point raiz

Nesta configuração, um access point é conectado diretamente a uma rede LAN cabeado, fornecendo um ponto de conexão para dispositivos sem fio. Se mais de um access point estiver conectado à LAN, os usuários poderão se movimentar de uma área das instalações para outra sem perder a conexão de rede (CISCO, 2019).

• Access point repetidor

Nesse caso, o ponto de acesso se conecta a um AP em modo raiz e retransmite o seu sinal aumentando a cobertura de acesso, funcionando como um repetidor (VASCONCELLOS,2013).

• Access point bridges

Access point em modo bridge são usados para realizar a comunicação entre duas redes com fio, através de uma rede sem fio (VASCONCELLOS,2013). Essa configuração costuma ser utilizado para interligar filiais de uma empresa quando, devido a distância ou outros fatores, se torna inviável a instalação de cabeamento para realizar a comunicação entre as duas partes.

(22)

2.1.1.2 Ruído e Interferência em Redes Sem Fio

Segundo Winter (2017), ruído representa qualquer sinal indesejado de natureza aleatória de uma fonte externa ou do próprio transmissor, o qual pode perturbar ou mascarar o sinal desejado. Sinal interferente é um sinal externo capaz de alterar as características do sinal transmitido. Ambos afetam a qualidade e desempenho da transmissão.

Nas redes de comunicação sem fio definidas pela família de protocolos IEEE 802.11, os principais ruídos e interferências na transmissão do sinal pelo meio são, interferências por co-canal, CCI (Co-Channel Interference), ocorre quando há mais de um transmissor operando na mesma frequência do sinal desejado; e interferência de canal adjacente, ACI(Adjacent Channel Interference), onde sinais transmitidos em faixas de frequências adjacentes a faixa do sinal desejado provocam imperfeições no filtro do receptor (WINTER, 2017).

Tanenbaum (2011, p.43) afirma que, "nas frequências usadas para as redes 802.11, os sinais de rádio podem ser refletidos por objetos sólidos, de modo que vários ecos de uma transmissão podem alcançar um receptor por diferentes caminhos. Os ecos podem cancelar ou reforçar um ao outro, fazendo com que o sinal recebido flutue bastante".

A Figura1 representa como ocorre a interferência entre diferentes canais da rede wireless, especificamente da faixa de 2,4GHz. Nela é possível observar que o canal 2 interfere nos canais de 1 a 5, com diferentes intensidades de acordo com a proximidade das frequências. MORAES (2010) afirmar que, considerando um ambiente isolado e um espaçamento de 22MHz, apenas três canais não estão sujeitos a sobreposição de frequências o 1, 6 e 11.

Figura 1 – Demonstração da sobreposição dos canais na faixa 2,4GHz

Fonte: Site Hardware.com¹

1 Disponível em <https://www.hardware.com.br/dicas/troque-canal-da-sua-rede-wi-fi-minimize-os- problemas-ligados-interferencia.html>. Acesso 28 Maio 2019

(23)

2.1.2 Redes sem fio com controlador

De acordo com Fischer, Tavares e Azevedo (2017), controlador de redes sem fio é um equipamento que exerce o gerenciamento de uma grande quantidade de pontos de acesso simultaneamente, de maneira integrada e coordenada, garantindo um maior desempenho e gestão da rede local.

Smith, Woodhams e Marg (2010) destacam que, uma WLAN baseada em controlador é tão importante para implementação de projetos de redes sem fio quanto um roteador é para a interconexão entre redes, dada a relevância das conexões sem fio no cotidiano para ambientes críticos que exigem alta disponibilidade. Segundo eles a transição de redes WLAN para redes WLAN baseadas em controlador favorece a escalabilidade e simplificação do processo de configuração dos acccess points, pois reduz a necessidade de intervenção direta de técnicos para essa finalidade.

Esses controladores podem ser dividas em dois tipos:

• Appliance

Consistem em uma solução completa dehardware esoftware dedicado exclusivamente para gerenciamento dessas redes. Exemplos desses modelos seriam o WLC da Cisco (CISCO, 2022) e o Aruba (ARUBA, 2022).

• Software

Compreende em um sistema que pode ser instalado ou executado sem necessariamente estar associado a umhardware específico, por exemplo, Tanaza e WiseFi, da Intelbras, Unifi Network Controller, da Ubiquiti Networks, SCIFI, etc.

Neste trabalho discorreremos sobre controladores de redeswireless do tiposoftware.

2.2 APIS

A sigla API corresponde às palavras em inglês “Application Programming Interface“, ou “Interface de Programação de Aplicações”. em português. Consiste em um conjunto de definições e protocolos usados no desenvolvimento e na integração de software de aplicações (RED HAT, 2020).

Segundo Fernandes (2018), as APIs possibilitam a integração entre sistemas que possuem linguagem totalmente distintas de maneira ágil e segura. Dessa forma, quando não se utiliza APIs, o profissional que precisa fazer a integração de sistemas, muitas vezes precisa instalar recursos compátiveis com o sistema que se busca trabalhar, o que ocasiona atraso na geração de negócios e processos produtivos de uma companhia.

(24)

Como aponta o site da Red Hat (2020), as APIs podem ser consideradas como contratos com documentações que representam um acordo entre as partes interessadas.

Assim, se uma das partes enviar um solicitação remota, a outra parte terá que responder a solicitação de acordo com o contrato.

(25)

10

3 SOLUÇÕES EXISTENTES

Este capítulo tem o objetivo de apresentar as principais soluções existentes no mercado que se assemelham a solução proposta nesta pesquisa. As soluções descritas a seguir foram encontradas por meio de pesquisas na internet e artigos acadêmicos.

3.1 SOLUÇÕES PROPRIETÁRIAS

3.1.1 WiseFi e Tanaza

Desenvolvido e fornecido pela Intelbras, empresa brasileira que oferece soluções em segurança, redes, comunicação e energia (INTELBRAS, 2021), WiseFi e Tanaza são softwares de gerenciamento centralizado para access points da Intelbras. Eles têm a sua disposição diversas funcionalidades, tais como: fornecimento de estatísticas, diversas opções de autenticação e segurança para redes wireless, limitação de banda por SSID (Service Set Identifier), entre outros.

A WiseFi consiste em um software gratuito disponibilizado no site da Intelbras que permite gerenciar e administrar a maioria dos APs que a fabricante disponibiliza no mercado (INTELBRAS BLOG, 2017). Até o momento dessa pesquisa é compatível apenas com o sistema operacional Windows e só permite gerenciar access points que estão conectados na mesma rede que a controladora (INTELBRAS, 2019).

A Tanaza é uma alternativa da fabricante para gerenciamento que usufrui de todos os benefícios da nuvem, ela possui recursos adicionais se comparado ao WiseFi. Por exemplo, limitação de banda para clientes específicos e não apenas por SSID, e o recurso Splash Page, que permite reproduzir vídeos e anúncios para liberação da rede wireless (INTELBRAS, 2020). Contudo, esta alternativa é gratuita por apenas trinta dias, após esse período é necessário adquirir uma licença na própria plataforma, cujos valores estão descritos na Tabela 1. As licenças disponíveis são: mensal, anual e vitalícia por access point. Vale ressaltar que ambas soluções só permitem gerenciar APs da Intelbras.

3.1.2 Unifi Network Controller

É uma solução de software para controle e gerenciamento de rede sem fio desenvolvido pela Ubiquiti Networks, empresa fundada nos Estados Unidos especializada em produtos com tecnologia wireless. O Unifi Network Controller permite gerenciar todos access points da família Unifi, uma das mais utilizadas nesse nicho de mercado, através

(26)

Capítulo 3. Soluções existentes 11

dele é possível: atualizar o firmware desses pontos de acesso, ver estatísticas por meio de gráficos intuitivos, configurar alertas e eventos, configurar diversos tipos de autenticação e parâmetros de redes wireless, criar um mapa interativo indicando os pontos onde os APs estão instalados, além de monitorar detalhadamente o acesso de determinado utilizador, entre outros (UBIQUITI NETWORKS,2022).

É um software gratuito disponível para download no site da fabricante, sendo compatível com os sistemas operacionais Windows e Linux, e por essa razão ele pode ser hospedado em Nuvem. Após o processo de instalação, o administrador pode acessar a controladora através de um navegador e tem à disposição todos os recursos apresentados acima. Além disso, a fabricante disponibiliza um aplicativo mobile que oferece funções muito semelhantes às que são disponibilizadas no Windows e Linux. Vale ressaltar também que o Unifi Network Controller permite gerenciar apenas APs da Ubiquiti.

3.1.3 Comparativo entre custos de implementação das soluções proprietárias

Observa-se na tabela1 que o custo de implementação das soluções proprietárias listadas acima, para ambientes que exigem uma vasta cobertura geográfica do sinal sem fio e provisionamento de acesso para muitos usuários, pode ser muito elevado dependendo da demanda do projeto.

Outro fator que deve ser levado em conta é o fato das soluções de gerenciamento centralizado apresentadas serem restritas apenas aos equipamentos da fabricante, por exemplo, o Unifi Controller Network não consegue gerenciar access points da Intelbras e a WiseFi não gerencia APs da Ubiquiti. Essa característica é comum em soluções proprietárias, o que pode ser um fator complicador em ambientes muito grandes onde pode ser inevitável utilizar modelos de uma fabricante apenas.

Tabela 1 – Comparativo soluções proprietárias

Fabricante Custo dos APs Controlador Custo do contro-

lador Intelbras Custo médio do produto mais aces-

sível: R$ 360 (AP 310)¹ Tanaza US$ 3.5/ mês² Intelbras Custo médio do produto mais aces-

sível: R$ 360 (AP 310) WiseFi -

Ubiquiti

Custo médio do produto mais aces- sível: R$ 590 ( Access Point AC lite)³

Unifi Controller

Network -

1 Intelbras. Disponível em: <https://loja.intelbras.com.br/access-point-ap310/p>. Acesso em: 25 de Abril 2022.

2 Conheça o Tanaza. Capterra. Disponível em: <https://www.capterra.com.br/software/186335/tanaza>.

Acesso em: 25 de Abril de 2022.

3 Ubiquiti Store. Disponível em: <https://br.store.ui.com/collections/unifi-network-

(27)

3.2 SOLUÇÕES LIVRES

3.2.1 SCIFI

O Sistema de Controle Inteligente para redes sem Fio (SCIFI) é um sistema criado pela Universidade Federal Fluminense (UFF) com apoio da Rede Nacional de Ensino e Pesquisa (RNP) e proposto na dissertação de mestrado da Helga Dolorico Balbi (BALBI, 2012). Esse sistema propõe operar e gerenciar pontos de acesso de baixo custo, desde que suportem a instalação do firmware OpenWrt, a partir de uma central controladora que permite ao administrador: reiniciar os access points; controlar e monitorar a potência de sinal; definir parâmetros específicos de frequência de canal baseado em um algoritmo de seleção de canais e permite organizar os APs em um mapa que pode facilitar a gerência.

O software controlador pode ser hospedado em uma máquina Linux e este por sua vez deve estar na mesma rede dos access points que serão gerenciados.

Por utilizar recursos de software open source os únicos custos gerados por essa solução são os de infraestrutura, tanto para conectividade dos APs quanto para o servidor que deve hospedar a controladora, e o de aquisição dos access points, que podem variar de acordo com a demanda. Vale ressaltar que, por utilizar sistemas embarcados Linux, por exemplo,o OpenWrt, essa solução não é restrita a access points de apenas um fabricante, é possível utilizar produtos de fabricantes diferentes desde que possuam compatibilidade com o OpenWrt.

3.2.2 Diferenças entre SCIFI e a solução proposta neste trabalho

As principais diferenças entre a presente pesquisa e a proposta apresentada no SCIFI estão relacionadas a arquitetura do sistema.

Enquanto o SCIFI se dedica ao gerenciamento de APs que estão na mesma rede LAN da controladora, o projeto proposto nesta pesquisa propõe uma arquitetura onde access points e controladora podem estar em redes diferentes, o que possibilita que esta solução seja implementada em diferentes estrutura e ambientes de rede, por exemplo, nessa arquitetura é possível que o controlador seja hospedada em um servidor na internet e gerencie access points situados em LANs, mas com acesso a internet.

O SCIFI é composto por uma solução unificada onde o controlador e interface de gerência estão acopladas e devem ser utilizadas em conjunto. Em contrapartida, o presente trabalho divide os módulos do sistema em interface gráfica e recursos do controlador, apropriando-se do conceito de microsserviços, que segundo a AWS (2022), é uma arquitetura de desenvolvimento de software onde o software é composto por pequenos

wireless/products/unifi-ac-lite>. Acesso em: 27 de Abril de 2022.

(28)

serviços independentes que se comunicam usando APIs, facilitando a escalabilidade e agilidade no desenvolvimento de aplicativos. Outro diferencial está na utilização de tecnologias mais recentes como Node.js e React.js, que tem sido amplamente adotados em diversas soluções de software devido a sua versatilidade, escalabilidade e desempenho.

(29)

14

4 TECNOLOGIAS UTILIZADAS

Este capítulo tem como objetivo descrever as principais tecnologias que foram utilizadas para o desenvolvimento e implementação desse projeto.

4.1 OPENWRT

O OpenWrt é uma distribuição Linux voltada para dispositivos embarcados que fornece um sistema de arquivos totalmente gravável com gerenciamento de pacotes. Ele libera o usuário das limitações de software impostas pelos fabricantes e permite personalizar o dispositivo por meio do uso de pacotes para atender a qualquer demanda (OPENWRT, 2019).

A ferramenta pode ser adaptada para ser utilizada de diversas maneiras e cenários.

Seu código de licença aberta disponibiliza uma maior abrangência de uso, porém se faz necessário conhecimentos na plataforma Linux para ter um melhor aproveitamento dos recursos da distribuição (AVELAR et al., 2010, p. 8).

De acordo com o site oficial daOpenWrt (2019), umas das grandes vantagens do firmware OpenWrt é que, além de flexível, ele também possibilita que dispositivos de diferentes fabricantes e configurações consigam se comunicar, bastando apenas que eles possuam compatibilidade para o mesmo e o tenham instalados em seu hardware.

4.2 SHELL SCRIPT

É um arquivo que possui uma ou mais instruções encadeadas que podem ser inter- pretadas e executadas pelo sistema operacional, geralmente utilizadas para automatização de tarefas. Geralmente é utilizado para manipulação de arquivos e execução de programas, por utilizar um interpretador nativo do sistema operacional é leve e permite criar instruções para gerenciar serviços e recursos do próprio sistema.

4.3 NODE.JS

O Node.js é um software open source multiplataforma, utilizado para executar instruções em JavaScript fora do navegador, ele permite construir aplicações web (backend), APIs e microsserviços. O Node.js se demonstra uma ferramenta flexível, leve e produtiva, já que pode ser utilizada em inúmeros cenários, possui uma arquitetura de funcionamento que demanda poucos recursos computacionais, com a utilização de threads, além de utilizar

(30)

Capítulo 4. TECNOLOGIAS UTILIZADAS 15

JavaScript, uma das linguagens de desenvolvimento Web mais utilizadas da atualidade (TOTVS, 2020).

Além dessas vantagens o Node.js se demonstra uma ótima alternativa na construção do backend, pois possui uma comunidade ativa e apresenta uma curva de aprendizado relativamente menor se comparado à outras linguagens voltadas para mesma finalidade.

Uber, IBM e Netflix são exemplos de empresas que utilizam esse software (PESSOA,2022).

4.4 REACT.JS

O React.js é uma biblioteca JavaScript desenvolvida pelo Facebook e utilizada para criação de UIs (User Interface) em páginas Web de forma interativa e fácil. Atualmente é uma das bibliotecas JavaScript mais utilizadas pelos desenvolvedores, dentre as vantagens podemos destacar a facilidade de aprendizado, a flexibilidade e agilidade, no sentido de permitir a reutilização de componentes de uma página em outra, diminuindo o tempo gasto na criação de aplicações.

Desenvolvedoresfront-end descrevem o React como uma biblioteca que possui uma curva de aprendizagem direta, o que simplifica sua adoção (HITCODE, 2020). Empresas como Netflix, Twitter, PayPal, Instagram e Airbnb integram o React em seus aplicativos Web(UDACITY BRASIL,2022).

4.5 MYSQL

MySQL é um SGBD (Sistema de Gerenciamento de Banco de Dados) SQL (Structured Query Language) open source desenvolvido, distribuído e suportado pela Oracle Corporation. Dados oficiais informam que ele é o SGBD open source mais popular entre os desenvolvedores, oferece suporte a multithread e multiusuário, e é indicado para sistemas de produção de carga pesada e de missão crítica (MYSQL, 2021). Ele opera na arquitetura cliente-servidor e possui compatibilidade com diversos sistemas operacionais e linguagens backends.

Grandes organizações como Facebook, Twitter, Youtube, Booking e Verizon utilizam o MySQL como solução para armazenamento de dados (MYSQL,2022). Por ser popular torna-se também uma sugestão ideal por ter à disposição diversas informações sobre instalação, implementação e integração com outras linguagens, desenvolvidas tanto pela comunidade quanto pelo site oficial.

(31)

4.6 ORACLE CLOUD

A OCI (Oracle Cloud Infrastructure) pode ser definida como um conjunto de serviços de computação em nuvem desenvolvida e disponibilizada pela Oracle Corporation.

De acordo com Bień (2019), a Oracle Cloud permite que seus usuários criem topologias e configurações flexíveis que podem ser facilmente ampliados e reduzidos. Além disso, a Oracle oferece alguns serviços Always Free, onde são disponibilizados ao usuário, por exemplo, recursos de infraestrutura e banco de dados. Esse serviço não tem custo, no entanto, possui algumas limitações. Ainda assim se demonstra uma excelente ferramenta que permite criar ambientes de teste ou até mesmo hospedar sistemas que não demandam muitos recursos computacionais, além do fato de apropriar-se de uma das características mais importantes da computação em nuvem, a alta disponibilidade.

Recentemente a Oracle vem expandindo cada vez mais sua infraestrutura de data centers em nuvem que conta com cerca de 25 regiões de nuvem situadas em mais de doze países(BANKS-LOUIE, 2020). Cisco, Mazda, Nissan, Zoom e TIM são exemplos de empresas que adotaram as soluções em nuvem da Oracle (OCI, 2020).

4.7 BASIC AUTHENTICATION HTTP

Basic Authentication é o sistema de autenticação mais comum do protocolo HTTP (Hypertext Transfer Protocol), consiste em um mecanismo simples de solicitação e resposta que funciona basicamente da seguinte forma: um servidor solicitar credencias de auten- ticação de um cliente, como usuário e senha, o cliente envia as informações solicitadas pelo servidor, nesse processo as informações são codificadas, com isso o servidor analisa as informações enviadas, se estiverem de acordo com o esperado o servidor aceita a conexão e encaminha ou libera o novo recurso, caso o servidor não recebe a informação esperada um código de erro é retornado (IBM,2022).

Esse recurso geralmente é utilizado por desenvolvedores para simplificar o processo de autenticação, tanto do lado do servidor como no lado do cliente, além de permitir esquemas de autenticação modernos como OAuth e OAuth2.

4.8 AUTENTICAÇÃO JWT

De acordo comJones, Bradley e Sakimura (2015), JWT (JSON Web Token) é um padrão compacto e seguro cujo objetivo é transmitir ou armazenar objetos JSON entre duas partes. Ele dispõe de recursos que permitem que as requisições Web JSON, por exemplo, sejam assinadas digitalmente usando um código de autenticação ou criptografia, esse recurso fortalece a segurança e assegura a integridade da informação trocada.

(32)

O JWT tornou-se um dos recursos mais utilizados entre os desenvolvedores nos casos em que é necessário realizar um processo de autorização em uma aplicação Web ou quando precisamos realizar a troca de informações, se destacam os casos em são implementados rotinas de autenticação via APIs (LYMA,2021).

4.9 JSON

ECMA (2017, p.1) declara que JSON (JavaScript Object Notation) é "uma sintaxe leve, baseada em texto e independente de linguagem para definir formatos de intercâmbio de dados. Foi derivado da linguagem de programação ECMAScript, mas é independente da linguagem de programação. JSON define um pequeno conjunto de regras de estruturação para a representação portátil de dados estruturados".

SegundoKotamraju(2014), é um formato que possibilita leitura e escrita fácil tanto para humanos quanto máquinas, e pode representar basicamente dois tipos estruturados, objetos, que são definidos como uma coleção não ordenada de zero ou mais pares de nomes/valores, e matrizes, definidas como uma sequência ordenada de zero ou mais valores, que podem variar entre strings, números, booleanos, nulos e estes dois tipos estruturados.

Bray (2017) afirma que o JSON pode ser usado para troca de dados em diversas linguagens de programação, tais como: ActionScript, C, C#, Go, Java, JavaScript, Lua, Perl, PHP, Python, Ruby, etc.

(33)

18

5 SOLUÇÃO PROPOSTA

Este capítulo está dedicado ao detalhamento da solução proposta por este trabalho.

Está dividido em três partes: A primeira relacionada a exposição das características e funcionamento de cada um dos componentes envolvidos neste projeto. A segunda focada na análise e documentação do projeto, no que se refere a levantamento dos requisitos, diagrama de casos de uso e diagrama de classes. E por último, na terceira parte, será demonstrado a implementação da solução e resultados.

5.1 O PROJETO

Neste trabalho foi desenvolvido um software controlador que atua de maneira centralizada para gerenciar, controlar e monitorar pontos de acesso sem fio de uma ou mais redes distintas, tornando mais barato e flexível a implementação e controle de uma rede wireless em ambientes com alta demanda de usuários.

5.1.1 Arquitetura da rede

A Figura 2 ilustra um exemplo de arquitetura de rede que pode ser usada para implementar a solução em um pequena, média ou grande organização.

Figura 2 – Arquitetura de rede da solução proposta

Fonte: Elaborado pelo próprio autor

Neste caso, o controlador (E1) é configurado em um servidor em nuvem e acessado por meio da internet por um usuário autorizado. A grande vantagem de utilizar esse tipo

(34)

Capítulo 5. Solução proposta 19

de arquitetura é a facilidade que os administradores do sistema possuem para gerenciar diversas redes distintas de forma centralizada em apenas uma máquina. É possível citar como exemplo, um administrador de redes que precise gerenciar as redes wireless da sede matriz de uma empresa, e também de suas filiais que estão em outras cidades. Com a solução desenvolvida neste projeto, o profissional poderia realizar esta tarefa sem maiores problemas. Isso é possível pois o controlador atua de forma passiva na rede, isto é, ele não se comunica com os pontos de acesso por conta própria, atuando apenas quando recebe uma requisição dos pontos de acesso ou dos administradores. Este fato decorre devido a dificuldade de conexões ponta a ponta em redes que utilizam NAT (Network Address Translation), pois nesses casos, os equipamentos a serem gerenciados utilizam um IP local que não é visível através da internet, logo, não podem ser acessados de maneira direta, a não ser que seja utilizado uma VPN (Virtual Private Network) para interligar essas redes distintas.

Um outro método de arquitetura que poderia ser utilizado seria a implementação do controlador na rede local da organização. Neste caso, o controlador também atuaria de forma passiva, entretanto, devido ao fato dele estar instalado em uma rede interna, tornaria o ambiente mais seguro, dificultando o acesso a ele por agentes externos mal intencionados.

Com relação ao funcionamento do sistema diante das duas arquiteturas apresentadas, em ambos os casos é exatamente o mesmo. O controlador utiliza um banco de dados para armazenar as informações de cada AP, tais como: endereço IP, MAC, parâmetros de configurações, status atual do dispositivo na rede (online ou offline), localização, etc. A partir dessas informações, o servidor controlador atua como mediador entre o administrador da rede e os pontos de acesso, recebendo e enviando informações para ambas as partes em um processo contínuo. Dessa forma, caso o administrador precise realizar alguma operação na rede sem fio, por exemplo, este enviará uma requisição ao controlador que irá armazenar a informação no banco de dados. Sendo assim, quando o ponto de acesso alvo do administrador se comunicar com o controlador, este irá comparar a informação recebida do AP com as informações que ele deveria ter, usando como base as informações inseridas pelo usuário e, caso haja alguma divergência, o ponto de acesso receberá uma mensagem do controlador com os ajustes que devem ser realizados.

5.1.2 Comunicação com o Controlador

Para garantir a comunicação do controlador com as demais partes, foram utilizadas APIs conforme demonstrado na figura 3. Neste modelo, o servidor controlador disponibiliza dois conjuntos de APIs de forma isolada, uma para se comunicar com os usuários administradores da rede e outra para se comunicar com os pontos de acesso.

(35)

Cada API é utilizada para realizar uma função diferente no sistema, existem APIs para consultar informação (GET), alterar informação (PUT), excluir informação (DELETE), cadastrar informação (POST) e até mesmo executar algum procedimento

interno (GET).

Para que seja possível a utilização da API, o cliente deve enviar uma requisição para o endereço do servidor controlador indicando o caminho da API, especificando a porta utilizada pelo serviço, escrevendo os parâmetros, se necessários, e também o método que será utilizado, podendo ser GET, POST, PUT ou DELETE. Após indicar corretamente a API a ser utilizada, o cliente também deve enviar a mensagem desejada utilizando o formato JSON, uma notação de objetos escolhida devido a sua flexibilidade e compatibilidade com diversas plataformas e linguagens. O controlador por sua vez, também responderá com uma mensagem no mesmo formato.

A partir desse processo, toda comunicação é realizada de acordo com o que será explicado no diagrama de casos de uso (5.2.3). Pela figura3, podemos observar na esquerda os APs, que no caso estão em locais distintos, se comunicando com o controlador através de um grupo de APIs, e do outro lado, temos o administrador da rede, representado pelo usuário, se comunicando com o controlador por meio de outro grupo. E no centro, temos o controlador, como intermediador dessa comunicação, fazendo todo o gerenciamento do sistema e atendendo as requisições de ambas as partes.

Figura 3 – Representação da forma de comunicação do controlador por meio de APIs

Com o intuito de evitar o uso não autorizado das APIs, o controlador utiliza a autenticação via token (JWT) para liberar o acesso aos usuários que irão gerir o sistema.

(36)

Para isso, estes devem realizar o login enviando o nome de seu usuário e senha em JSON para a API específica de login. Após esta etapa, se as informações estiverem corretas e o usuário habilitado, o controlador enviará ao usuário seu token de autenticação. A partir desse momento, o usuário deve armazenar esse token e sempre quando for utilizar alguma outra API, deve-se inserir no cabeçalho da API seu token para liberação do acesso. Os tokens gerados pelo servidor controlador expiram em 12 horas, após esse período deve ser feito o login novamente para a geração de um novo token.

Em relação aos pontos de acesso, a liberação para uso é feita através de autenti- cação básica (Basic Authentication) devido às limitações dos dispositivos. Nesse tipo de autenticação, o AP apenas informa qual a senha e usuário configurado no servidor para realizar requisições, e, no corpo da API, informa qual o MAC de seu hardware. Se seu MAC estiver cadastrado e o usuário e senha estiverem corretos, o ponto de acesso terá liberdade para enviar seus dados e receber as mensagens do servidor, informando possíveis mudanças que devem ser executadas.

Toda comunicação realizada por meio das APIs com o controlador, seja dos usuários ou dos pontos de acesso, pode ser criptografada utilizando o protocolo HTTPS (Hyper Text Transfer Protocol Secure), que adiciona uma camada de segurança, evitando que os dados sejam interpretados por agentes mal-intencionados, especialmente em redes sem fio, onde a vulnerabilidade do protocolo HTTP é maior devido a facilidade de rastrear e interceptar o trafego das informações.

5.2 ANÁLISE E DOCUMENTAÇÃO

5.2.1 Requisitos Funcionais

De acordo comFigueiredo(2011), os requisitos funcionais são declarações explícitas das funcionalidades e serviços do sistema, documento como deve reagir a determinadas entradas, como deve ser comportar em determinadas situações e em alguns casos, o que o sistema não deve fazer.

A seguir será listado os requisitos funcionais para o controlador:

RF 01: Deve permitir cadastrar, remover, configurar e monitorar pontos de acesso;

RF 02: Deve possuir um sistema de autenticação através de usuário e senha para acesso ao sistema;

RF 03: Deve permitir a criação, alteração e remoção de grupos;

RF 04: Deve permitir a associação e desassociação dos pontos de acesso a um grupo;

(37)

RF 05: Deve permitir o cadastro, alteração e remoção de usuários autorizados a utilizar o sistema;

RF 06: Deve permitir atribuir níveis de permissão diferentes para cada usuário, onde cada nível possui alguma ou nenhuma restrição das funcionalidades disponíveis;

RF 07: Deve listar e filtrar os pontos de acesso cadastrados;

RF 08: Deve listar e filtrar os clientes conectados a cada um dos pontos de acesso;

RF 09: Deve permitir realizar o bloqueio de um determinado cliente, no qual ele estará impedido de se conectar a qualquer um dos pontos de acesso que são gerenciados pelo sistema;

RF 10: Deve permitir realizar alterações em vários pontos de acesso simultaneamente tendo como base o grupo a qual pertence;

RF 11: Deve registrar em um arquivo de log todas as ações executadas por usuários e as requisições enviadas pelos pontos de acesso;

RF 12: Deve listar e filtrar todas as informações armazenadas no arquivo de log;

RF 13: Deve armazenar e mostrar aos usuários administradores as requisições enviadas pelos pontos de acesso periodicamente, tais requisições devem conter a atual configuração do dispositivo e também lista dos clientes conectados ao próprio;

RF 14: Deve responder às requisições dos pontos de acesso, confirmando o recebi- mento e, se necessário, informando as mudanças na configuração do ponto de acesso que precisam ser aplicadas;

RF 15: Deve verificar periodicamente quais dos pontos de acesso estão onlines e quais estão offlines;

RF 16: Deve permitir que um ponto de acesso ou um grupo de pontos de acessos sejam reiniciados remotamente por meio de sua interface;

RF 17: Deve atualizar periodicamente a lista de clientes conectados a cada um dos pontos de acesso informando quais destes clientes estão onlines e offlines;

5.2.2 Requisitos Não Funcionais

Descrevem propriedades e restrições do sistema, podendo ser do sistema como um todo ou apenas parte dele, na maioria dos casos esses requisitos não são visíveis ao usuário.

A seguir será listado os requisitos não funcionais para o controlador:

(38)

RNF 01: A comunicação do controlador com os usuários e com os pontos de acesso deve ser feita através de API;

RNF 02: Todas as informações que são recebidas ou enviadas pelo controlador devem estar no formato JSON;

RNF 03: Deve ser implementado mecanismo de segurança para impedir a utilização não autorizada das API, seja para os usuários ou para os pontos de acesso;

RNF 04: Deve ser possível a instalação do controlador em um servidor na nuvem ou na rede local;

RNF 05: Todos os dados modificados no sistema devem ter sua integridade garantida a fim de eliminar qualquer inconsistência existente no banco de dados;

RNF 06: A interface do web do controlador deve ser intuitiva, possibilitando o fácil entendimento e uso da ferramenta;

RNF 07: O desempenho do sistema deverá atingir um nível satisfatoriamente alto, a fim de minimizar os problemas de conexão e maximizar a experiência do usuário;

5.2.3 Diagrama de casos de uso

É uma forma de representar as funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema e, que com ele interagem (BEZERRA, 2007). Na figura 4, podemos visualizar de maneira geral, quais são as funcionalidades do sistema controlador de redeswireless e como os atores: Usuário (Administrador), Usuário (Comum) e Ponto de acesso irão interagir com ele.

Vale ressaltar que ambos os usuários presentes no diagrama se referem ao profissional de TI, responsável por administrar a rede, que irá usufruir dos recursos do controlador. A diferença está apenas relacionado as permissões que cada tipo de usuário terá.

(39)

Figura 4 – Diagrama casos de uso do controlador

Nos tópicos abaixo serão apresentados as particularidades de cada caso de uso, detalhando explicitamente o funcionamento e os relacionamentos dos atores com o sistema.

5.2.3.1 Gerenciar pontos de acesso ou grupos

Para realizar a atividade de gerenciar os pontos de acesso ou grupos cadastrados no sistema, os atores responsáveis primeiramente deverão efetuar a autenticação via login, e logo após poderão escolher entre:

• Consultar os pontos de acesso ou grupos cadastrados;

• Alterar a configuração de um ponto de acesso ou a configuração de dispositivos associados a um grupo;

• Cadastrar um novo ponto de acesso ou grupo;

• Excluir um ponto de acesso ou grupo;

Caso o ator realize alguma modificação relacionada aos pontos de acesso (Consultar, Editar, Cadastrar, Excluir), a ação é armazenada em log e a modificação é salva no banco de dados pelo controlador, para posteriormente ser usada como base para responder as

(40)

requisições efetuadas pelo ator ponto de acesso. Esse caso de uso específico será explicado no próximo tópico.

Quando é realizado um cadastro, ou uma alteração de um ponto de acesso, o usuário tem a opção de estar associando o respectivo dispositivo a um grupo previamente cadastrado. Dessa forma, caso seja necessário realizar modificações em vários APs ao mesmo tempo, o processo se torna mais rápido e fácil, bastando apenas aplicar as configurações para um determinado grupo e automaticamente será replicada para todos os dispositivos associados ao grupo.

Figura 5 – Diagrama casos de uso para gerenciar pontos de acessos ou grupos

Fonte: Elaborado pelo próprio autor 5.2.3.2 Enviar requisições com informações do dispositivo

O ator envolvido nesse caso de uso é o dispositivo ponto de acesso, ele é programado para periodicamente enviar informações a respeito de seu estado de operação para o servidor controlador que foi a ele designado. Tais informações incluem:

• Lista de clientes conectados ao dispositivo;

• Lista de clientes atualmente bloqueados pelo ponto de acesso (blacklist);

• Mac do ponto de acesso;

• Configurações básicas da rede wireless do ponto de acesso (SSID, Canal de operação, modo de autenticação utilizado, modo de seleção do canal);

(41)

Ao enviar essas informações, o dispositivo espera um retorno do controlador, já que se trata de uma requisição. O controlador recebendo a informação, compara os dados recebidos com os dados que foram armazenados no banco de dados para o respectivo dispositivo, caso ocorra alguma divergência relacionada a configuração que o dispositivo deveria ter com a configuração atualmente utilizada, o controlador responde a requisição, informando as novas configurações que devem ser aplicadas no AP.

Por exemplo, um usuário A fez uma alteração no ponto de acesso P informando que o dispositivo em questão deve conter o SSID ‘Laboratório B3’ e atuar no canal de operação

‘6’. O ponto de acesso P ao fazer o procedimento de rotina de enviar as informações para o servidor, alega estar utilizando o SSID ‘Auditório’ e atuando no canal de operação ‘11’.

Nesse caso, o controlador irá comparar a informação que foi armazenada no banco de dados pela ação do usuário A com a informação que foi recebida de P, e logo após enviará uma mensagem para P, informando que o dispositivo deve alterar o seu SSID para ‘Laboratório B3’ e o canal de operação para o ‘6’.

Quando o controlador recebe a informação dos clientes conectados ao dispositivo, ele verifica se algum dos clientes listados não está cadastrado no armazenamento do sistema, caso positivo, o cliente é cadastrado e a partir desse momento poderá ser gerenciado pelo controlador. Procedimento semelhante acontece com relação a blacklist, porém, caso um cliente esteja na blacklist do ponto de acesso e não esteja definido na blacklist do armazenamento do controlador, o sistema responderá a requisição solicitando para remover o cliente dablacklist. Caso um cliente esteja nablacklist do armazenamento do controlador e não esteja na blacklist do dispositivo, o sistema responderá a requisição solicitando para incluir o cliente na blacklist do dispositivo. O gerenciamento de clientes será explicado com mais detalhes no próximo tópico.

Além disso, se o ponto de acesso enviar uma requisição para o servidor controlador no qual o AP não está cadastrado, simplesmente receberá uma resposta informando que o dispositivo não tem autorização para fazer essa solicitação, sendo assim, ele continuará operando normalmente com as configurações pré estabelecidas. Caso o AP esteja cadastrado no servidor e devidamente configurado de acordo com o que está armazenado no sistema, ele receberá uma resposta apenas informando que sua mensagem foi recebida e que não há nenhuma mudança que precise ser feita.

(42)

Figura 6 – Diagrama casos de uso para enviar requisições

Fonte: Elaborado pelo próprio autor 5.2.3.3 Gerenciar clientes conectados

Para este caso de uso, o analista ou administrador, que são os atores envolvidos, devem primeiramente efetuar a autenticação via login, e logo após poderão escolher entre:

• Consultar os clientes que estão associados aos pontos de acesso gerenciados;

• Bloquear ou desbloquear o acesso de um determinado cliente para qualquer AP que seja gerenciado pelo controlador;

Sempre que um cliente é bloqueado ou desbloqueado, ou seja, inserido ou removido da blacklist, o controlador armazena a nova blacklist no banco de dados a partir da atualização que o usuário fez. E, a medida que os pontos de acesso vão enviando as requisições periódicas, o controlador faz a comparação da blacklist que o ponto de acesso informa com a blacklist armazenada no banco de dados, e ocorrendo divergências, envia os clientes que devem ser inseridos ou removidos da blacklist do AP, como explicado no tópico anterior.

Figura 7 – Diagrama casos de uso para gerenciar clientes conectados