Ponto de acesso wireless

Capítulo 5. Solução proposta 32

atributos envolvidos são semelhantes aos do ponto de acesso, já que estão diretamente relacionados a eles, e outros utilizados para classificar o grupo, são estes:

• Descrição: Fornece a descrição do grupo

• SSID: Nome que deve ser utilizado na rede wireless dos pontos de acesso que pertencem ao grupo;

• Tipo de autenticação: Método de criptografia utilizado para a autenticação dos clientes que irão se conectar aos APs associados ao grupo;

• Senha: Senha utilizada para se conectar aos dispositivos pertencentes ao grupo;

Servidor WPA2E: Endereço lógico do servidor radius utilizado pelos APs associados ao grupo, caso a autenticação seja WPA2 Enterprise;

• Modo de seleção do canal: Define se a seleção de canal é feita de maneira automática ou manual para os pontos de acesso que pertencem ao grupo;

E por último, temos a classe “Clientes conectados”, nela estão representados todos os equipamentos, comosmartphones,tablets, notebooks,Smart Tvs, entre outros, que estão utilizando a rede wireless proveniente dos pontos de acesso gerenciados pelo controlador.

Cada cliente pode ser associado a apenas um ponto de acesso e cada ponto de acesso pode ter vários clientes conectados. Esta classe possui os seguintes atributos:

• Mac: Endereço físico que identifica o equipamento que está utilizando a redewireless do ponto de acesso;

• Status: Indica se o cliente está online, offline ou com o acesso bloqueado;

Capítulo 5. Solução proposta 33

necessário a utilização de ferramentas que permitissem a padronização da arquitetura do sistema, principalmente no que se refere a comunicação dos APs com a controladora.

Em virtude disso, a ferramenta escolhida que se adequa às necessidades do projeto é o firmware OpenWrt.

A instalação deste firmware nos APs possibilita a comunicação do equipamento com o controlador por meio das APIs e também garante a flexibilidade do sistema, pois permite que dispositivos de diversos fabricantes possam ser usados nesta solução. Ele também permite um melhor aproveitamento de desempenho e customização dos APs, já que, por padrão, alguns fabricantes impõem limitações a nível de software nos parâmetros que podem ser configurados. Entretanto, vale ressaltar que, para ser possível substituir o firmware original de um AP para o firmware OpenWrt é necessário que o modelo desejado seja suportado pela versão OpenWrt, tal informação pode ser consultada na página do projeto OpenWrt.

É recomendável, segundo o próprio site da OpenWrt, que o dispositivo a receber o firmware tenha mais que 8 MB (MegaBytes) de memória flash e 64 MB de memória ram, para que este consiga aproveitar todos os recursos da plataforma sem muitas limitações e de maneira consistente. Entretanto, dispositivos com configurações inferiores também estão aptos para receber o firmware e serem utilizados neste projeto, porém, dependendo do caso, será necessário instalar uma versão mais desatualizada do firmware ou até mesmo abrir mão da interface gráfica do OpenWrt.

Cada ponto de acesso, dependendo do modelo, pode ter um método diferente para realizar a instalação do OpenWRT, alguns permitem que instale o firmware diretamente da interface web do fabricante original do produto e em outros apenas por meio do protocolo TFTP (Trivial File Transfer Protocol), por isso é importante estar verificando o método correto de instalação no site oficial do OpenWrt.

Com o firmware devidamente instalado, para poder utilizá-lo no controlador, é necessário fazer a configuração da API e também realizar o download de alguns scripts e pacotes do sistema essenciais para o funcionamento correto da solução. Visando fa-cilitar este procedimento, foi disponibilizado no github (<https://github.com/Cirwiff/

AccessPoint-Scripts>) um instalador que ao executá-lo, realiza todas as configurações desse processo. Para executá-lo, deve-se informar como parâmetros, o IP do servidor controlador e o usuário e senha utilizados para realizar a autenticação da API, como demonstrado na figura 12.

Os scripts que são baixados pelo instalador são escritos em shell script e possuem as seguintes funcionalidades:

Capítulo 5. Solução proposta 34

• scan.sh - Realiza o escaneamento da rede espectral, identificando interferências e dispositivos wireless vizinhos;

• cb_channel.sh - Utiliza como base o resultado do script scan.sh para definir qual o melhor canal de operação que deve ser utilizado pelo AP;

• change_channel.sh - Script utilizado para realizar a troca do canal de operação;

• change_ssid.sh - Utilizado para trocar o SSID da rede;

• get_ca.sh- Script que lista todos os clientes (MACs) conectados ao ponto de acesso;

• password.sh - Script para realizar a troca do método de autenticação e a senha da rede wireless;

• reboot.sh - Faz o reiniciamento do equipamento;

• get_blacklist.sh - Lista os clientes (MACs) que estão com acesso bloqueado ao dispositivo;

• include_blacklist.sh - Script para incluir um MAC na lista de MACs com acesso bloqueado;

• exclude_blacklist.sh - Script para excluir um MAC da lista de MACs com acesso bloqueado;

• send.sh - Script para construir um objeto em formato JSON, com as informa-ções coletadas do ponto de acesso, e enviar para o controlador por meio da API, armazenando a resposta da solicitação em um arquivo;

• action.sh - Script para ler a resposta enviado pelo servidor controlador e fazer as devidas operações caso seja necessário

Como este projeto visa desenvolver uma solução flexível, que permita a utilização de diversos modelos de ponto de acesso, do mais simples ao mais sofisticado, a utilização da linguagem shell script para o desenvolvimento dos scripts se tornou necessária, pois é uma linguagem leve e nativa do sistema operacional, que respeita as limitações de armazenamento e processamento dos dispositivos wireless que podem estar presentes nos modelos mais simples.

Todos esses scripts são utilizados pelo ponto de acesso no processo de comunicação com o controlador, seja para coletar as informações para enviá-las, ou para efetuar modificações nas configurações a partir das informações recebidas pelo controlador.

Devido ao fato do controlador não se comunicar de forma direta com os pontos de acesso, como foi explicado no tópico arquitetura de rede (5.1.1), se torna necessário que de

Capítulo 5. Solução proposta 35

tempos em tempos os APs façam essa comunicação de maneira autônoma. Para isso, os dispositivos devem ter a tarefa de execução do script send.sh configurada no agendador de tarefas do linux (crontab), indicando a frequência que esse evento se repete, além disso, também deve ser configurado no crontab a execução de forma periódica do script cb_channel.sh que realizará a troca do canal de comunicação caso o método de seleção esteja definido como automático e seja encontrado um canal com menor interferência.

Para testar e validar a solução proposta por este projeto, foi utilizado um roteador wireless da marca TP-LINK modelo Archer C20 v.4.0 (figura11) como ponto de acesso a ser gerenciado. A versão do firmware utilizada foi a OpenWRT 21.02.0.

Figura 11 – Roteadorwireless usado como ponto de acesso

Fonte: Elaborado pelo próprio autor

Com o firmware OpenWRT devidamente instalado no dispositivo e este conectado a internet, foi realizado o acesso ao AP via ssh e baixado o script de instalação presente no repositório do GitHub citado anteriormente.

Capítulo 5. Solução proposta 36

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

Fonte: Elaborado pelo próprio autor

Analisando a figura12, é possível notar que foi utilizado o parâmetro -h para indicar o ip do servidor controlador, o parâmetro -u para indicar o usuário para autenticação da API e o parâmetro -p para indicar a senha para autenticação da API. Após a execução do instalador, os scripts necessário para o funcionamento da solução foram instalados no diretório /usr/share/controller/script como demonstrado na figura 13.

Além disso, com a execução do instalador, também foi configurado, de forma automática, o agendador de tarefas do ponto de acesso para a execução periódica dos scripts send.sh e cb_channel.sh como explicado anteriormente.

Capítulo 5. Solução proposta 37

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

Fonte: Elaborado pelo próprio autor

Figura 14 – Tarefas agendadas no ponto de acesso

Fonte: Elaborado pelo próprio autor

Na configuração indicada na figura14, o script send.sh está configurado para ser

Capítulo 5. Solução proposta 38

executado a cada 20 segundos e ocb_channel.sha cada 2h. Ou seja, a cada 20 segundos os pontos de acesso enviam seus dados para o controlador e recebem as possíveis mudanças que precisam ser realizadas e a cada 2h é verificado se o ponto de acesso precisa trocar o canal de operação, caso este esteja utilizando a seleção automática de canal.

Sempre que o script send.sh é executado, várias informações são coletadas do dispositivo e são armazenadas em um arquivo JSON e logo depois são enviadas para o controlador. Como resultado disso, o script action.sh entra em execução, analisando a resposta do controlador e efetuando as mudanças se necessárias. A figura 15demonstra esse processo.

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

Fonte: Elaborado pelo próprio autor

Na figura 15é possível notar que foi executado o script send.sh e este coletou os dados do ponto de acesso e os armazenou no arquivo data.jsone, em seguida, o conteúdo desse arquivo foi enviado para o controlador e este retornou uma informação em JSON que é armazenada no arquivo result.json. Neste caso específico, o ponto de acesso estava utilizando o SSID“IFF-CentroW”e para autenticação dos usuários a senha“teste123”, porém, no controlador estava designado para este dispositivo o SSID “IFF-Centro” e senha “12345678”. Portanto, foi enviado para o AP a informação que ele deve alterar as suas configurações nesses atributos, sendo que tais mudanças podem ser visualizadas analisando o arquivo result.json que é apresentado na figura 15.

Vale ressaltar que o ponto de acesso funciona independente da comunicação com o controlador, logo, caso por algum motivo essa comunicação seja quebrada, o AP continuará

Capítulo 5. Solução proposta 39

operando normalmente com as últimas configurações que foram salvas no dispositivo.