Introdução Remote Access Point Aruba


Boa noite a todos! Hoje vou falar um pouco sobre o Remote Access Point da Aruba Networks. Essa postagem vai cobrir as características principais de implementação de um "RAP" e as configurações iniciais executadas na controladora para funcionamento do dispositivo.

Antes de falar sobre o Remote Access Point, precisamos compreender a arquitetura de conexão remota fornecida pela Aruba, mais conhecida como VBN (Aruba Virtual Branch Network Solution). VBN é uma arquitetura criada pela Aruba que surgiu para suprir as necessidades de acesso remoto provendo todos os serviços Wireless necessários de maneira segura para o usuário corporativo.

A Aruba sempre sustentou a visão de que competir no mercado por features relacionadas ao encaminhamento de dados sobre o ar não era uma vantagem, tendo em vista que muitas das features proprietárias acabam sendo padronizadas pelos órgãos regulamentares e depois de um tempo acabam não sendo mais uma vantagem e sim um pré requisito para se manter no mercado. Um exemplo que posso citar olhando para o passado, seria a Meru sendo a primeira a resolver problemas de voz sobre Wi-Fi, e atualmente varias das soluções proprietárias em cima de voz passaram a ser padronizadas não sendo mais uma vantagem de um fabricante especifico. Com essa visão, a Aruba desde o inicio focou em fornecer uma solução robusta de segurança juntamente com a solução Wireless, se distanciando dos demais fabricantes que em meados de 2008 seguiam o caminho contrario focando somente em features relacionadas a qualidade de transporte de dados sobre o ar.

Com políticas, regras de usuário, application category, web category, serviços de reputação web, deep packet inspection e integração com servidores de autenticação, as controladoras da solução Aruba passaram a concentrar serviços críticos de uma rede corporativa. Com a grande aceitação do mercado em cima das features de segurança providas pelas controladoras Aruba, surgi a necessidade de estender essas funcionalidades de segurança para as localidade remotas que pertenciam a essa rede corporativa como pequenos escritórios que fazem parte da organização.

O design mais utilizado hoje em dia para implementações com varias localidades espalhadas geograficamente seria uma implementação com controladoras MASTER/LOCAL, mas esse tipo de design fica totalmente inviável financeiramente quando estamos falando de escritórios com 10 funcionários que demandam os mesmos serviços da localidade principal. Foi assim que surgiu a arquitetura VBN com foco em implementações de pequeno a médio porte mas que precise envolver o mesmo nível de segurança de uma implementação de grande porte. A solução VBN é composta de três componentes principais que são:

  • RAPs  (Remote Access Point)
  • VIA (Virtual Intranet Access)
  • IAP (Instant Access Point)
Hoje vamos falar sobre os RAPs.

Um Remote Access Point mais conhecido como RAP, é utilizado para prover conexão segura em pequenos escritórios ou pequenos eventos que precisam de todas as funcionalidades de uma rede corporativa implementada na localidade principal.

Anteriormente quando se falava de RAP, estávamos falando diretamente sobre uma linha de Access Points projetadas exatamente para atender as necessidades ditas anteriormente. Hoje além dos modelos de Access Points nomeados como RAP, podemos falar de RAP como um modo de operação que pode ser habilitado diretamente em um Campus AP ou IAP.

Possuímos basicamente 4 modelos de RAPs nos produtos HPE/Aruba. Vou mostrar alguns modelos abaixo:

  • RAP3: O RAP3 trabalha na frequência de 2.4GhZ e possui 3 portas conforme podemos ver na imagem abaixo:



Como podemos observar, uma das portas é utilizada para conexão com o link de internet e as outras portas podem ser utilizadas para conexão de dispositivos como impressoras, telefones e etc.

  • Os RAPs da serie 100, são equipamentos 802.11n e trabalha nas duas frequências (dual rádio):
A maior diferença dessa linha se comparada com o RAP3 está nas configurações dual rádio e na quantidade de portas fornecidas para conexão de dispositivos cabeados como impressoras e telefones IP. Ambos possuem conexão 3G/4G para redundância no caso de falha do link WAN.

Falando um pouco sobre modos de operação, podemos converter um IAP ou um Campus AP para realizar as funcionalidades de RAP, ou seja, não precisamos ter um equipamento das series mostradas anteriormente para executar as funcionalidades de RAP. A desvantagem de você utilizar um IAP ou Campus AP para operar no modo RAP, é a quantidade de portas que serão limitadas se comparado aos modelos específicos lançados para esse propósito e a falta de conexões 3G/4G que só existem nos modelos RAP.

Alguns pontos que devemos saber antes de começar as configurações:
  • Não existe uma licença especifica para RAP. Devemos ter em mente que independente do modo em que o Access Point esteja operando (RAP, ou Campus AP), o consumo de licença será a mesma, que no caso será uma licença de AP (LIC-AP) com exceção do IAP que possui uma controladora virtual nos Access Points e não exige nenhuma licença para executar suas funcionalidades.
  • Como vamos utilizar a controladora para fechar tuneis VPN para os RAPs, vamos precisar que o modulo de VPN esteja instalado. Para quem não sabe, o modulo de VPN é instalada uma única vez na controladora e será ativada a quantidade máxima de conexões VPN com base no modelo da controladora, diferente das demais licenças que são compradas em valores unitários baseados na quantidade de Access Points. Como dito anteriormente, não existe uma licença especifica para a funcionalidade de RAP, ou seja, essa licença de VPN pode ser utilizada para conexões de usuários através do VIA e para conexões de clusters IAPs através de IPSEC.
  •  NUNCA utilize uma porta do RAP para fazer uma "extensão" de conexão com um outro RAP, ou seja, a porta de UPLINK de um RAP não deve ser ligada a porta Ethernet de outro RAP para compartilhar a conexão WAN. Por exemplo, se o RAP-1 estiver conectado através do RAP-2, o túnel IPSEC do RAP-1 será formado dentro do túnel IPSEC do RAP-2 e isso causará dupla criptografia e descriptografia do tráfego entre a controladora e o RAP-1. A dupla criptografia IPSEC e descriptografia do tráfego afeta diretamente no desempenho, aumentando a fragmentação e delay da conexão.
 
  • No caso de a controladora ficar atrás de um Firewall, é necessário a liberação da porta 4500.

Configurando VPN Server na Controladora:

Primeiramente vamos checar se o modulo de VPN está instalada corretamente e vamos configurar os parâmetros necessários para ativação do servidor VPN na controladora.

Vamos acessar a controladora via Web e navegar até Configuration -> Controller -> Licenses:


Como podemos observar, estou utilizando uma controladora Aruba 650 e possuo o modulo de VPN ativo na controladora para até 512 conexões. O número mostrado acima, é o máximo de conexões que essa controladora suporta.

Caso você não tenha o modulo de VPN ativo na controladora, será necessário a aquisição do modulo PEFV. O Part Number deste modulo muda de acordo com o modelo da controladora. 

Com a licença devidamente instalada, vamos fazer as configurações necessárias para ativação do servidor VPN da controladora.  Vamos acessar o menu Configuration -> VPN Services:

Vamos realizar todas as configurações na aba de IPSEC que é o protocolo utilizado para manter o tunnel entre o RAP  e a controladora:




 
Como podemos observar na imagem acima, é necessário que L2TP e XAuth estejam ativos juntamente com o protocolo PAP. No meu caso, eu configurei um servidor DNS externo para testes. O endereço DNS é utilizado para o RAP fechar o túnel com a controladora via FQDN, ou seja, é necessário que o servidor DNS conheço o FQDN da controladora para funcionar corretamente. Apesar de eu ter preenchido esse campo para testes, estou no momento com um IP publico configurado nesta controladora que se encontra localizada na DMZ da minha rede.

O RAP vai possuir basicamente dois endereços. O primeiro endereço é o da porta WAN utilizado para fazer a comunicação com o endereço publico configurado na controladora e pode ser utilizado como um gateway para os usuários da localidade (No caso de encaminhamento local de trafego). O segundo endereço é um endereço da sua rede interna, utilizado para fechar o tunnel GRE (O tunnel GRE é criptografado pelo tunnel IPSEC formado anteriormente).

Como podemos ver na imagem compartilhada anteriormente, eu criei um "rap-pool" para entregar o endereço interno para os meus RAPs.

Descendo um pouco a pagina, vamos configurar os últimos passos para funcionamento do servidor VPN:


A primeira configuração é referente ao agressive mode do IKE. Esse modo era um meio de autenticação para dispositivos legados e não é mais utilizado atualmente. Mesmo assim, é preciso que essa configuração fique ativa pois ela faz parte do processo de autenticação IPSEC. Recomendo somente a alteração do group name para um nome aleatório.

O próximo passo é a configuração da chave que será trocada com o RAP. Muita atenção nessa configuração pois as chaves devem ser idênticas em ambos os lados para a autenticação funcionar corretamente. Eu fiz uma configuração simples, mas no caso de uma implementação real, é altamente recomendado que além do fornecimento da senha, seja configurado a subnet dos dispositivos que vão realizar o processo de autenticação. Isso aumenta a segurança tendo em vista que em caso de tentativa de conexão sem permissão, o invasor precisa estar com um dispositivo na rede especificada desse campo para ter sucesso. Outro detalhe nessa configuração: É altamente recomendado configurar uma senha diferente para cada RAP que for conectar em sua controladora, ou seja, para cada novo RAP você terá que adicionar uma nova linha nesse campo.

Para aumentar a segurança, é possível realizar uma segunda fase de autenticação baseado em certificado. No caso do control plane security estar ativo, a controladora valida o certificado instalado no RAP através de um certificado raiz instalado nela, dessa maneira ela determina se permite ou não o registro do RAP na controladora. Vou explicar o processo de configuração do control plane security em uma próxima postagem.

Deixo claro que os demais campos não explicados nesse post pode ser necessário dependendo do modelo de implementação. Eu vou detalhar esses campos em uma outra postagem futuramente mas caso alguém tenha dúvida me deixe uma mensagem que respondo sem problemas. 

Criação de grupo de AP:

Agora vamos criar um grupo de AP que será utilizado por todos os meus RAPs. Dependendo da implementação realizada, podemos criar diferentes tipos de grupos de RAP e aplicar diferentes profiles para cada grupo:


Como podemos ver na imagem acima, criei um grupo com o nome rap. Clicando no grupo podemos realizar a amarração de todos os profiles. Não vou demonstrar a criação dos profiles tendo em vista que a ideia aqui é realizar a aplicação de profiles corporativos já existentes em sua rede em uma localidade remota. Se alguém tiver dúvida na criação de profiles deixe um comentário.




Como podemos ver na imagem acima, já realizei as amarrações dos profiles que eu havia criado anteriormente para esse propósito. O mínimo de profiles que devem estar amarrados a um VAP (Virtual AP) são os profiles de SSID e AAA. Vou mostrar em detalhes algumas configurações do VAP que contem campos utilizados pelos RAPs:




Os campos que marquei na imagem em vermelho, são os mais importantes para provisionamento de um SSID em um Access Point em modo RAP. Existem três tipos de encaminhamento de trafego no ArubaOS 6.4. Vou explicar cada um deles a seguir:

  • Split-Tunnel: Implementamos o modo Split Tunnel quando precisamos "segmentar" o trafego. Em certos casos, eu preciso que determinada comunicação seja enviada através de um tunnel para a controladora e pode ser que determinadas comunicações possam ser tratadas na rede local. Neste caso, o RAP determina o destino do pacote através de uma ACL configurada na controladora especificamente para essa questão. Se a rede estiver nesta ACL, os dados são encaminhados localmente, no caso de o endereço não estar configurado nesta ACL, os dados são encaminhados para o tunnel. A controladora é responsável por entregar o endereço IP das estações através do DHCP local ou através de um relay na Interface L3 da controladora com o modo Split-Tunnel habilitado.
  • Tunnel: O modo tunnel é o modo padrão para os CAPs e RAPs. Esse é o modo mais utilizado em implementações com CAPs (Campus AP). Nesse modo todo o trafego é encaminhado para a controladora através de um tunnel.
  • Bridge: No modo Bridge, todo o trafego dos RAPs são tratados localmente e apenas informações de estatísticas são enviadas para a controladora. Esse modo é utilizado quando todos os serviços necessários são fornecidos localmente não existindo a necessidade de encaminhar todo o trafego para uma controladora que se encontra remotamente, tendo em vista que nessa situação a controladora encaminharia o trafego de volta para a origem e duplicaria o processamento de pacotes sendo que este pacote já poderia ter sido tratado de maneira local sem a necessidade de roteamento da controladora.
O modo de operação é selecionado de acordo com o modo de encaminhamento. Vou apresentar uma tabela com os modos de operações compatíveis para cada modo de encaminhamento:


Como podemos analisar na tabela acima, quando estamos utilizando o modo de encaminhando Bridge, todos os modos de operação são permitidos. Utilizamos o modo "Always" quando a controladora não é o meio principal de encaminhamento. Nesse modo o RAP não precisa ter uma conexão inicial bem sucedida com a controladora para iniciar a propagação do SSID. Independente do status de conectividade com a Controladora, o SSID sempre será propagado e estará acessível para os clientes.

No modo Backup, O RAP mantém um tunnel com a controladora e propagada o SSID designado de acordo com as configuração da controladora. No caso da existência de falha de comunicação entre a controladora e o RAP, um SSID backup configurado no RAP passa a ser propagado até a conectividade com a controladora ser restaurada.

O ultimo modo conhecido como Persistent, é utilizado em localidades que possuem um link externo de baixa qualidade e perde conectividade com a controladora constantemente. Pense em um escritório remoto que possui uma conectividade de baixa qualidade e nenhum serviço é acessado localmente. Neste caso ativamos o modo Persistent. Quando o RAP realizar o processo inicial de comunicação com a controladora e obter sucesso, ele passa a propagar o SSID. No caso de uma oscilação de link, o RAP continua propagando o SSID e mantém os usuários conectados localmente aguardando restabelecer a conexão com a controladora. Com a conexão restabelecida, o RAP volta a encaminhar o trafego pelo tunnel ativo.

Por ultimo o modo Standards é utilizado para encaminhamento padrão de pacotes através do tunnel e o único modo de operação permitido entre os modos de encaminhamento Tunnel e Split-Tunnel.

Convertendo um Campus AP para RAP:

Com todas as configurações prontas, podemos provisionar o nosso Access Point para o modo RAP. Existem basicamente três métodos para um RAP encontrar a controladora:

  • O primeiro método é o que vamos utilizar. Vamos realizar a conversão de um Campus AP já registrado na controladora para RAP.
  • O segundo método que pode ser utilizado, é realizando as configurações através da GUI apontando o IP da controladora e as credencias de acesso no momento da conversão.
  • O ultimo método utilizado é o deploy automático do RAP através do serviço Activate da Aruba.

 


Acessando o menu de configuração podemos provisionar o Access Point em questão, siga o caminho da imagem acima para acessar o AP que será convertido para RAP (No meu caso eu já havia convertido o AP anteriormente mas vou refazer todos os processos para demonstração).
Acessando o Access Point já podemos observar alguns parâmetros importantes. Logo de cara, ele já pede para selecionarmos o grupo do RAP. Devemos selecionar o grupo que configuramos anteriormente, possuindo todos os parâmetros de conexão incluindo os modos de encaminhamento e os modos de operação.




O próximo parâmetro que devemos configurar é a chave IKE que configuramos anteriormente no Servidor VPN da controladora. a chave IKE deve ser idêntica a configurada anteriormente. Seguindo os parâmetros de configuração, devemos configurar um usuário e senha para a autenticação PAP. Recomendo gerar de maneira automática através dos geradores de usuário e senha da controladora.




Para finalizar, devemos configurar os parâmetros de rede com endereço da controladora e endereço do RAP. No meu caso, estava realizando alguns testes com um endereço IP interno do meu LAB, mas em um ambiente real provavelmente o IP da controladora será um IP publico ou um IP interno com NAT para um IP Publico.

Após finalizar os últimos passos devemos aplicar e reiniciar o AP em questão para que ele faça a conversão para o modo RAP e aplique todas as configurações do VAP configurado no inicio do post.

Checando configurações:

Para checar se a conversão do CAP para RAP ocorreu normalmente, vamos acessar a aba de monitoramento:





No resumo de Access Points, podemos observar que dois Access Points estão registrados na controladora. O CAP não possui dois endereços diferente do RAP e se observamos no final da coluna, o RAP está com IPSEC ativo. OS dois estão com o status "UP" na controladora. Selecionei um IP interno apenas para testes mas em um ambiente real o campo "Outer AP IP" estará com o IP publico obtido pelo RAP.




Clicando em cima do RAP, vamos ser levados para informações mais detalhadas. Aqui poderíamos checar a autenticação PPPoE, informações de canais e etc.

Vou finalizar esta postagem por aqui para não me estender muito. Nas próximas postagens vou falar um pouco sobre as configurações avançadas que podemos fazer para o modo RAP. Espero ter ajudado a entender o conceito dessa solução e que todos consigam fazer as configurações necessárias para o funcionando de um RAP.

Até a próxima!

Comentários

Postagens mais visitadas deste blog

NPS PEAP-MSCHAPV2 + WLC CISCO e WLC HP

802.11 Medium Access - CSMA/CA Overview