Os testes iniciais de funcionamento da rede foram feitos a partir de uma máquina Windows conectada à máquina cliente que possui o firmware do Althea instalado. Os testes realizados seguiram a topologia mostrada na figura 15, com uma máquina Windows conectada a interface LAN do cliente 1. O teste foi disposto dessa maneira para simular um usuário que possua um computador em casa conectado a um roteador sem conexão WAN, mas que esteja na rede Althea local. O ambiente utilizado foi o ambiente de teste mostrado na seção [6.3.2.1 Configuração da rede], seguindo a topologia apresentada na figura 15.
6.3.1 Rastreamento da rota para Internet
Para o teste de rastreamento foi utilizado o comando traceRT. TraceRt é um comando para visualizar um pacote de rede sendo enviado e recebido e a quantidade de lugares em que ele passa até chegar no seu destino final. No teste indicado na figura 25, fizemos o rastreamento da rota para o website do google.
Figura 25: TraceRt
Fonte: Autor (2020)
Na figura 25 podemos visualizar que até chegar ao destino o pacote efetuou 11 saltos, sendo o primeiro salto para o roteador Althea cliente, seguindo para o nodo de saída representado pelo IP 172.168.0.254. No terceiro salto a resposta de tracert pode estar bloqueada pelo administrador, mas mesmo assim o pacote é encaminhado para o endereço do próximo salto. Neste momento os dois nodos de retransmissão estavam ligados e conectados ao cliente, além de conectados ao nodo de saída, representado no teste pelo segundo salto. 6.3.2 Failover
Ao executar o traceRT e acompanhar o consumo dos dados a partir da interface Althea dos nodos, identificamos que o nodo cliente estava utilizando o nodo de retransmissão 2 para que seus pacotes fossem encaminhados. De acordo com a pesquisa realizada, o protocolo de roteamento utilizado pelo firmware faz a checagem TLV [4.1 BABEL] a cada 5 segundos, e em caso de falha, encontra uma nova rota de saída.
Sendo assim, o nodo de retransmissão 2 foi desligado enquanto o cliente o estava utilizando para transmissão de pacotes. Houve uma perda de sinal durante alguns segundos, por conta da redefinição da rota de saída, mas logo após os pacotes voltaram a ser encaminhados dessa vez utilizando o nodo de retransmissão 1, isso pode ser observado no dashboard do usuário, no campo de uso de dados como demonstra a figura 24.
6.3.3 Túneis VPN
Após verificar a rota seguida a partir de uma máquina Windows, foram realizados testes diretamente no firmware do cliente 1. Por ser baseado no openwrt o sistema Althea dispõe de diferentes ferramentas para teste de rede.
O sistema Althea cria túneis para a conexão entre os nodos da rede utilizando o software de VPN WireGuard (Donenfeld, 2020). O Althea cria esses túneis para realizar a contabilização do tráfego e posteriormente fazer as cobranças. Ao digitar o comando wg é possível verificar as interfaces da máquina, e seus respectivos túneis (VPN), como demonstra a figura 26.
Figura 26: WireGuard cliente 1
Fonte: Autor (2020)
A figura 26 demonstra as interfaces do cliente 1 e suas respectivas VPNs, a interface wg2, é referente a placa eth1, conectada ao nodo de retransmissão 2, já a interface wg3 se refere a placa eth2, conectada ao nodo de retransmissão 1. Para que a conexão funcione corretamente cada máquina possui uma chave WireGuard pública que é utilizada para conexão. O sistema Althea se encarrega de criar essas conexões de forma automática, a partir do momento que os dois dispositivos estão conectados a partir de portas do tipo mesh.
Na Figura 27 podemos comprovar que a chave pública para interface wg0 tem o mesmo valor do campo peer da interface wg2 no nodo cliente. Este campo indica a que máquina a interface está conectada.
Figura 27: WireGuard nodo de retransmissão 2
Fonte: Autor (2020)
Sendo assim, o campo peer da interface wg0 na figura 27, demonstra a conexão entre o nodo de retransmissão e o nodo cliente.
6.3.4 Escolha da melhor rota
O sistema Althea utiliza um protocolo de roteamento muito eficiente que além da disponibilidade do nodo, leva em conta o custo financeiro que esse nodo tem para o encaminhamento de pacotes, esse custo é conhecido como métrica de preço [4.1 BABEL]. O custo que cada nodo tem para o encaminhamento de pacotes pode ser gerado de forma automática pelo sistema, ou definido manualmente pelo usuário, na página 𝘚𝘦𝘭𝘭𝘪𝘯𝘨
como mostra a figura 28. 𝘉𝘢𝘯𝘥𝘸𝘪𝘥𝘵𝘩
Figura 28: Preço nodo de retransmissão 1
Fonte: Autor (2020)
O preço configurado para o nodo de retransmissão 1 foi de 0.0002 tETH por GB mostrado na figura 28. No momento da configuração do preço para o nodo 1, o nodo de retransmissão 2 estava sendo usado para o encaminhamento dos pacotes do cliente a um preço de 0.000333 tETH por GB. O experimento conduzido quis validar se o protocolo conseguia mudar a rota utilizada tendo como base uma rota com uma métrica de preço mais atrativa.
O Althea distribui para as portas mesh da rede endereços IPV6 e para validar a rota escolhida pelo cliente foi executado o comando traceroute6, apontando para o endereço IPV6 do nodo de saída como mostra a figura 29.
Figura 29: Traceroute nodo de saída
Fonte: Autor (2020)
A primeira execução do traceroute para o nodo de saída é indicada pela primeira seta da imagem 29. O endereço após o comando é o endereço IPV6 do nodo de saída. Na imagem podemos ver que antes de chegar ao destino, o pacote passa por um outro endereço IPV6, mostrado no salto número 1. Esse endereço está atribuído ao nodo de retransmissão 2. Assim podemos observar que este dispositivo está sendo utilizado como intermediário no encaminhamento de pacotes.
Após esse primeiro teste, foi feito a alteração do valor cobrado pelo encaminhamento de pacotes no nodo de retransmissão 1, como mostra a imagem 28, para um valor abaixo do cobrado pelo nodo de retransmissão 2. Depois da alteração o serviço de rede do nodo de retransmissão 1 foi reiniciado e ao executar o comando traceroute novamente a rota havia mudado, como indica a segunda flecha da imagem 29. O endereço que consta no salto 1 do comando é referente ao IPV6 do nodo de retransmissão 1, que agora atua como intermediário no encaminhamento de pacotes.
Podemos observar que a rota foi reconfigurada, levando em conta o melhor preço oferecido entre as rotas disponíveis, já que a distância no cenário virtual é a mesma. Sendo assim o sistema consegue entregar uma de suas principais premissas, oferecendo um serviço eficiente com o menor custo possível.
O custo e a métrica dos diferentes links disponíveis são checados utilizando o protocolo BABEL [4.1 BABEL]. No seguinte teste, foi utilizado a ferramenta tcpdump (Jacobson; Leres; McCanne, 2020), para verificar se o nodo cliente está recebendo as atualizações e está checando as rotas e métricas enviadas pelos outros nodos da rede. O tcpdump permite monitorar os pacotes trafegados em uma rede e esses pacotes podem ser salvos em um arquivo. A partir de uma máquina Windows foi feita a conexão ssh com o nodo cliente e então iniciado o monitoramento, como mostra a figura 30.
Figura 30 Tcpdump
Fonte: Autor (2020)
Na figura 30, podemos verificar o comando tcpdump sendo executado, da forma como foi construído esse comando está monitorando os pacotes trafegados em todas as portas do nodo cliente e salvando esses pacotes em um arquivo chamado tcpdumpAll com formato pcap. O formato pcap é o formato utilizado para salvar dados de pacotes de rede, permitindo
que esse arquivo seja aberto em ferramentas externas para análise. Nesse experimento os pacotes foram capturados com o tcpdump e a captura foi aberta utilizando o Wireshark, como apresentado na figura 31.
Figura 31: Wireshark preço 1
Fonte: Autor (2020)
Na figura 31 podemos visualizar os pacotes capturados na rede Althea, com ênfase nos pacotes do protocolo Babel. Isso porque, esse é o protocolo utilizado para a definição de rotas com base nas métricas. A primeira seta indica o pacote que está sendo analisado, podemos verificar que esse pacote foi transmitido a partir do nodo de retransmissão 1 com final do IPV6 3010. A segunda seta analisa a mensagem update enviada nesse pacote. A mensagem
update, é enviada pelo nodo de retransmissão para atualizar os nodos da rede com os seus
dados, contendo dentre os dados o custo que esse link tem para transmissão de pacotes, esse custo é indicado pela elipse vermelha na figura 31.
Esse valor é passado utilizando o formato hexadecimal com 8 caracteres, cada qual com 4 bits e está atribuído a um campo chamado price, sendo que o valor 000186A0 presente na mensagem foi convertido para o seu respectivo valor decimal, para fins de checagem. O campo price não está por padrão no protocolo Babel, sendo uma modificação realizada pelo Althea. Por esse motivo não foi reconhecido isoladamente no Wireshark, como os outros campos, mas pode ser identificado pois ele deve estar presente antes do campo Prefix. Sendo assim os primeiros 32 bits do Prefix na verdade são referentes ao preço da rota. Nesse
momento o nodo de retransmissão 1 tinha o seu preço definido como 0.0001 tETH.
Para confirmar que em caso de atualização do preço, o protocolo envia o update com o valor atualizado para os nodos da rede, foi feita a alteração do preço do nodo de retransmissão 1 para 0.0009 tETH. Os pacotes da rede foram capturados novamente utilizando o tcpdump e analisados utilizando o Wireshark, como mostra a figura 32
Figura 32 : Wireshark preço 2
Fonte: Autor (2020)
As elipses vermelhas da figura 32 indicam o preço obtido para o nodo de retransmissão 1 realizar o encaminhamento de tráfego. O valor foi obtido na nova captura de pacotes realizada pelo nodo cliente. A primeira seta da figura 32 indica que o pacote analisado vem do nodo de retransmissão 1, já a segunda seta indica a mensagem que está sendo analisada, no caso a de update. O preço 000DBBA0 contido na mensagem de update foi convertido para o seu respectivo valor decimal, para fins de checagem. Podemos observar uma atualização no valor hexadecimal do preço quando comparado com o preço presente na figura 31, indicando que as modificações são realizadas e enxergadas pela rede. Assim podemos verificar que a métrica de preço foi efetivamente alterada e anunciada pelo nodo através do protocolo Babel, de forma que os demais nodos possam calcular a rota mais barata.
7. CONCLUSÃO
Como descrito no início deste trabalho, as redes comunitárias oferecem para diferentes tipos de comunidades a chance de estarem inseridas no mundo digital em que vivemos. Pude observar durante minha pesquisa que essa oportunidade é de extrema importância pois possibilita uma democratização do acesso ao oferecê-lo a um grupo que geralmente era negligenciado no aspecto digital. Essa inclusão se tornou ainda mais importante durante o ano de 2020.
Devido ao fato de que, durante a crise do coronavírus, vimos uma verdadeira revolução na forma que vivemos, com diversos serviços sendo migrados para o meio digital, a ampliação do tipo de trabalho remoto e a expansão de diversas áreas do meio digital como ecommerce. Esse novo fator aumentou ainda mais a importância do acesso à rede mundial de computadores. Tendo isso em vista, acredito que redes comunitárias oferecem uma oportunidade ímpar, para que zonas afastadas também façam parte dessa revolução e tenham um acesso mais democrático a rede.
Com base na configuração e nos testes realizados, posso concluir que o sistema Althea oferece uma solução eficiente e funcional para criação de redes mesh incentivadas. Observei como ponto de destaque, a interface gráfica intuitiva que o sistema disponibiliza para configuração do roteador e adição do nodo na rede. Durante os testes, o sistema atendeu ao que se propõe. Fundos são adicionados e gerenciados na carteira e podem ser enviados para outros nodos de forma fácil e intuitiva. Isso é de extrema importância em um contexto no qual pessoas que não estão muito habituadas com novas tecnologias, tentam construir suas próprias redes comunitárias seja para suprir uma necessidade ou para promover um novo serviço.
Nesse sistema o roteamento funciona da maneira esperada, encontrando a melhor rota disponível, assim oferecendo resiliência pois em caso de falha em um dos nodos, o protocolo encontra uma nova rota rapidamente. Além de definir uma nova rota em caso de falhas, o sistema também define uma nova rota caso encontre uma onde o custo e a distância sejam mais vantajosos quando comparados a rota utilizada no momento. Pude observar isso através dos comandos de rede traceroute, analisando os pacotes enviados na rede e acompanhando o uso de dados no nodo cliente e nos retransmissores.
Também pude verificar que a premissa de oferecer uma rede confiável e que possibilita o controle e cobrança de tráfego, pode ser atingido com a combinação das diferentes ferramentas do sistema. Entre elas o WireGuard. Durante minha pesquisa verifiquei que a configuração desse serviço se feita de forma manual, requer certo conhecimento técnico
para que chaves possam ser geradas e a conexão criada entre os nodos. O fato do Althea trabalhar essa questão de forma automática, facilita muito para que uma gama mais ampla de usuários possam configurar as suas próprias redes. Assim sendo o Althea oferece uma solução eficiente para criação e gerenciamento de um rede comunitária incentivada.
Concluo que a pesquisa realizada e a implementação feita, me proporcionaram um maior entendimento teórico e técnico sobre redes comunitárias e seu funcionamento. A pesquisa destacou a importância dessa tecnologia e o impacto positivo que pode ser alcançado com ela quando difundida e aplicada, além de provisionar o conhecimento teórico do funcionamento das diferentes tecnologias envolvidas na construção dessa rede. Enquanto a implementação me provisionou um conhecimento técnico para criar um cenário virtual, que no futuro, pode ser reaproveitado para implementação desse tipo de rede em um ambiente real.