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
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 disponi-biliza 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.
Capítulo 5. Solução proposta 20
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
Fonte: Elaborado pelo próprio autor
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.
Capítulo 5. Solução proposta 21
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.