[MÚSICA] Oi, bem-vinda ou bem-vindo a este treino da Aruba Mobility Essentials. Meu nome é Ricardo Cobos e vou começar com a parte 2-4, arquitetura de WLAN. Realmente este módulo vai falar muito dos tipos de implementações que nós podemos ter com os access points. Vai depender dos requisitos do cliente, então você poderia determinar qual é a melhor solução que poderia oferecer a ele. Então vamos começar. A primeira é o autonomous AP. O autonomous AP é realmente access point independente, autônomo, que você vai ter que configurar de forma individual e nele as configurações ficarão salvas. Isso quer dizer que você pode gerenciar desde o seu computador o access point e fazer modificações na configuração desse dispositivo. Agora importante entender é que se você quiser adicionar outro AP você teria que configurar esse outro AP de forma individual também. Esta solução foi de fato a primeira solução para configurar redes sem fio e foi uma boa opção quando nós tínhamos apenas três ou até seis access points. Mas se você tem ambiente muito maior e se você precisa dúzias ou centenas de APs, então a verdade é que esta solução não escala bem. Isto quer dizer que você perderia muito tempo tendo que configurar e monitorar cada desses access points de jeito individual, ao configurar mesmo que apenas dez deles é possível que você já tenha feito algum erro na configuração e esse erro vai continuar aí até que você o encontre e faça o troubleshooting. Por outras palavras este tipo de solução é boa quando você tem implementações pequenas, mas se realmente o seu cliente precisa de uma implementação com dez, vinte, trinta ou mais access points a verdade é que esta opção não é recomendável. Uma característica boa desta configuração é que obviamente você apenas precisa o investimento inicial dos access points, não precisa de nenhum tipo de licença ou nenhum tipo de hardware adicional. Depois nós temos o seguinte modelo que é thin AP, ou AP magro. Isso quer dizer que o access point vai receber a configuração de outro dispositivo, você não vai ter que configurar este dispositivo individualmente, porém ele não ter a sua própria configuração localmente no AP. A verdade é que o AP vai precisar de identificador, praticamente nome e vai ter que pertencer a grupo e depois o AP vai contactar sistema de gerência centralizado onde ele vai providenciar o seu nome e o grupo a que pertence e com isso é como o access point vai descarregar a sua configuração e depois corrê-la. Por outras palavras a configuração não vai ficar salva dentro do equipamento, a configuração tem que ser descarregada cada processo de boot que o AP tenha que fazer. Diferentes tipos para implementar esta solução: por exemplo esse ponto central de gerência pode ser controlador, no caso de Aruba nós temos Mobility Controller na versão ArubaOS 6.x ou ArubaOS 8.x. A verdade é que esta é uma das últimas versões que nós estamos a implementar produtos Aruba e aqui o que nós temos é dispositivo central que é o cérebro da solução e que nós chamamos de Mobility Conductor. Antigamente nós chamávamos de Mobility Master mas agora o novo termo é Mobility Conductor. E esse Mobility Conductor é servidor ou uma máquina virtual que vai gerenciar múltiplos controllers. Então a verdade é que aqui com wireless controllers nós temos duas opções: já sei que os access points vão ser controlados por controlador que é appliance, é uma caixa, que vai controlar os access points ou você poderia fazer uma solução ainda muito mais escalável onde grupo de controllers que tem os seus access points debaixo deles vão ser gerenciados por cérebro superior que nós vamos chamar de Mobility Conductor. Faz sentido se você tem uma implementação pequena, você pode ter access point autônomo, se você quer algo mais escalável você pode ter access points debaixo de controller e se você precisa de algo ainda mais escalável, você poderia ter muitos access points debaixo de múltiplos controllers que eles também vão ficar debaixo de outro dispositivo que é superior, falando hierarquicamente. Então neste caso o Mobility Conductor seria este servidor, ou este cérebro central. Agora, há outras opções, por exemplo nós poderíamos ter uma solução de gerência chamada de Wireless Network Management/Monitoring System que não é outra coisa que apenas servidor que vai gerenciar os access points diretamente. Aqui importante é que a Aruba tem produto que pode fazer isto que é o Aruba Airwave. O Aruba Airwave é servidor que você tem que ter dentro da empresa e ele pode gerenciar múltiplos access points autônomos. Agora neste caso nós não precisamos do Mobility Controller, mas é importante entender que nem todas as funcionalidades podem estar disponíveis para você fazer o seu servidor. Por isso é que quando você tem uma rede muito grande o que a gente, na Aruba realmente recomenda, é você implementa o seus access points com controllers e além disso você poderia ter este servidor centralizado de gerência. E a razão para isto é que este servidor se utilizado também pode monitorizar outro tipo de dispositivos como switches ou equipamentos de outros fabricantes. Que outras opções nós temos? Nós temos por exemplo Cluster Management, isto quer dizer que nós não vamos precisar de controller, nós não vamos precisar de uma caixa física. Nós vamos ter múltiplos access points que correm software que nós chamamos instant e entre eles vão-se descobrir, vão eleger deles, vão fazer uma escolha de deles e ele vai ser o dispositivo que nós chamamos de virtual controller. Então quando você tem múltiplos access points na mesma VLAN, deles vai ser virtual controller e é aquele que vai gerenciar e monitorar todos os outros access points vizinhos, eles vão gerar o que chamamos de cluster, instant cluster. E finalmente nós temos uma última opção que nós chamamos de cloud management. Neste caso a opção, ou o produto que a Aruba tem é o Aruba Central. E o que é isto? Neste caso também não precisamos de controller, os access points podem gerar cluster e escolher quem vai ser o seu virtual controller e depois todos os access points vão contactar a Aruba Central e você vai poder gerenciar todos eles desde esta solução, ou plataforma na nuvem. Aqui é importante entender que ainda quando nós não precisamos gastar pelo Mobility Controller, licenças ou subscrições para os gerenciar desde o Aruba Central. Então aqui como nós podemos ver AP magro tem múltiplas opções para ele trabalhar. Pode ser gerenciado por controller, wireless networking management system e na nuvem ou através de dos próprios access points que se tenha tornado virtual controller. Agora vamos discuti-los mais detalhe. Quando nós temos controller que está gerenciando os access points, bom aqui o que nós temos é uma caixa que antigamente nós chamávamos de switch sem fio. Switch sem fio porque esta caixa vai receber o tráfego dos clientes como switch faria. O que acontece aqui é que no lugar de portas de rede, o controller vai ter múltiplos access points. E estes access points vão propagar a rede sem fio, os clientes vão se associar neles e o tráfego dos clientes vai chegar até ao Mobility Controller. Nós vamos ver pouco mais disso no slide seguinte. Importante entender, como já falei, é que este controller poderia ficar sozinho ou se você quer uma solução ainda mais escalável você poderia ter muitos deles e estar gerenciando eles desde Mobility Master ou Mobility Conductor. Agora para as redes sem fios, para as WLAN, nós temos uma coisa que nos chamamos de modo forwarding. E o modo forwarding é aquilo que diz o que é que o AP vai fazer com o tráfego quando este vem dos clientes. Por outras palavras, o AP poderia enviar todo o tráfego através de túnel até ao Mobility Controller e então o Mobility Controller vai processar ele ou nós poderíamos permitir ao access point que ele movimente os pacotes localmente sem ter que centralizar o tráfego no controller, mas porque nós temos a opção... ...de enviar outra [INCOMPREENSÍVEL], porque isso aparenta que o controller não é apenas uma caixa de gerência, mas também ponto central para receber o tráfego dos clientes, e essa é a verdade, essa é a realidade, mas porquê? Bom, se você tem esse caso no modo tunnel, vamos para a seguinte página. Quando nós temos o modo forwarding tunnel, o que acontece é que o cliente vai gerar os pacotes, ele vai criptografar eles, sobre todos nós temos nível de segurança com WPA2 ou WPA3, vamos escrever isso, WPA2, WPA3. Então, o cliente vai gerar os dados com pacotes e criptografar eles, adicionar cabeçalho 80211 e depois enviar pelo ar. O access point vai servir ele e o access point não tem a chave para descriptografar esses pacotes. Então, o que o access point vai fazer é encapsular ele sobre GRE, Generic Routing Encapsulation, e enviar os pacotes até o mobility controller. O mobility controller vai receber eles, fazer esse desencapsulado, remover os cabeçalhos, decriptografar o tráfego e depois enviar ele pela rede. No entanto, aqui há ponto fundamental que temos que mencionar e é a ração mesma pela que o mobility controller vai receber o tráfego no primeiro lugar e isso é firewall. Acontece que o mobility controller é firewall, de fato é uma caixa de múltiplos serviços. Ele pode fazer spectrum analysis, traffic analysis, routing, switching, e também pode trabalhar com firewall, firewall da camada do acesso. Isso quer dizer que realmente a razão para não se enviar o tráfego até o controller é porque nós queremos analisar ele com deep packet inspection, queremos analisar ele no nível da camada da aplicação e também saber se este tráfego é ou não é permitido. Se não é, o mobility controller vai atirar no lixo, se é permitido, então ele vai fazer o forwarding. Essa é a razão fundamental para centralizar o tráfego no controller. E é que assim nós podemos ter a certeza de que o tráfego antes de chegar a qualquer destino, o tráfego dos clientes fio, este tráfego, estes pacotes vão ser analisá-los por equipamento de segurança que acontece que é o mobility controller, tá? Então, muito, muito importante essa é a razão. Agora, obviamente, este modo forwarding é apenas disponível quando nós temos controllers e também temos outra alternativa que é o modo bridge. Neste caso, os access points ainda estão gerenciados pelo controller e, possivelmente, o controller pode estar gerenciado pelo mobility conductor ou mobility master, mas esse não é o ponto, o ponto é que o cliente vai gerar os seus pacotes, criptografar eles, pôr ou colocar o cabeçalhos 80211, enviar pela rede, mas agora a diferença entre este modo e o anterior é que neste, o access point vai ter a chave de criptografado. O access vai ser capaz de decriptografar os pacotes e depois colocar eles no cabo. Então, neste caso, o tráfego não fica centralizado pelo mobility controller, o access point vai poder enviar ele direto até o destino. Alguns casos para nós usar isto, mas a verdade é que aqui nós vamos perder uma coisa, que é o firewall do controller, tá? Então, se lembra desse ponto, porque o firewall no controller é uma dessas características que diferenciam Aruba de outros vendedores, e são principais ao ao qual muitos clientes realmente preferem Aruba ou acham que Aruba é uma melhor opção. Depois, nós temos o virtual controller. Neste caso, como eu já falei, nós vamos ter múltiplos access points, mas nós não temos uma caixa, nós não temos controller. Nesse caso, quando todos esses access points ficam dentro do mesmo transporte de camada 2, tá, aqui, e deles vai ser escolhido como o virtual controller. Nós vamos fazer uma escolha ou eles vão fazer uma escolha e o access point seja o primeiro que você conecta na rede ou aquilo que você manualmente conectou como master, ele vai ficar como o virtual controller. E esse virtual controler é aquilo que vai começar a gerenciar todos os demais. Então, o que nós temos aqui é cluster de múltiplos controllers que dependem de só e ele vai controlar a configuração geral de cada deles que inclui, por exemplo, as WLANs, VLANs, segurança, rádios, etcetera. Agora, muito importante, se este access point cai por alguma razão, então algum outro vai ser convertido o novo virtual controller, tá? E esse virtual controller agora vai pegar controle total do cluster como todo, tá? Por último, o que é que acontece com os clientes? Bom, primeiro entender que os access points vão estar enviando do VLAN, propagando do VLAN, os clientes vão se associar e quando eles vierem, pacotes que vão estar obviamente criptografados, estes pacotes quando forem ao ar, vão ser recebidos pelo access point e o access point não vai enviar o tráfego até o virtual controller. Realmente, o access point, o membro do cluster, vai enviar o tráfego do cliente diretamente até o seu destino, vai fazer local bridging, tá? Então, realmente aqui o virtual controller oposto ao que nós tínhamos com physical mobility controller, aqui o controller não centraliza o tráfego dos usuários. Ele é apenas para monitoração e configuração, tá? Por último, nós temos a solução de nuvem, Cloud Managed APs, e é aqui onde nós realmente podemos ter [INCOMPREENSÍVEL] múltiplos clusters de access points e esses clusters de access points ainda devem escolher o seu próprio virtual controller local na VLAN. Além disso, todos eles vão falar com esta solução da nuvem. No caso da Aruba, a nossa solução é Aruba Central e é praticamente uma plataforma que você sempre pode acessar ela do seu computador, não importa onde você esteja, se você está na sua casa ou num café-internet, ou se você está numa viagem, a verdade é que você sempre vai poder acessar esta plataforma na nuvem e através dela, monitorar e gerenciar cada desses APs de jeito individual e também como grupo. Então, isso realmente dá a você muita flexibilidade de poder monitorar a rede, não importa onde você esteja, porque esta plataforma sempre vai estar acima. Além disso, ela também oferece outras ferramentas, como pode ser relatórios, presence analytics, alertas e muitos outros serviços que oferece para os clientes. Importante entender é que esses access points não vão enviar o tráfego dos clientes para esta solução na nuvem, eles apenas vão enviar estatísticas e informação de controle e informação de gerência, tá? Por último, importante entender é que se os access points não têm acesso mais para Aruba Central, eles ainda ficam trabalhando. Isso quer dizer que se a internet cai, as redes sem fio, as redes do VLAN ainda vão ficar no ar. E a última coisa importante, você tem que licenciar ou pagar essas licenças dessa solução, que são as inscrições de três ou até cinco anos por cada dos APs que você tem na sua rede, tá? Então, com isso, nós já vimos as diferentes opções que nós temos para oferecer aos nossos clientes a depender das necessidades deles, como podem ser quão grande a sua rede é, ou quantos access points ele tem e quanto eles podem investir componentes adicionais como controladores ou mobility conductor, licensas e inscrições. Espero que você tenha gostado desse vídeo. Eu vou ver você no próximo parte 2-5, onde nós vamos falar de controle do acesso. Obrigado por assistir. [MÚSICA]
