Wireless Aruba – Modo de encaminhamento para os Access Points

Quando uma estação encaminha seus quadros para um Ponto de Acesso, existem diversas maneiras para o AP processar e encaminhar os dados, tudo dependendo de como o Access Point é configurado. 

Um Access Point configurado como IAP não necessita de uma Controller, pois todos os AP que estão na mesma sub rede irão formar um Cluster Virtual e operam independente da Controladora física.

Já os Pontos de acesso gerenciado por uma Controladora, devem ter seu tráfego permitido na rede (caso haja restrições de tráfego na rede).

O modo de encaminhamento (forwarding mode) define como os dados enviados pelo usuário são encaminhados pelo AP e podem ser classificados como:

  • GRE/tunnel
  • Bridge
  • Decrypt-tunnel
  • Split-Tunnel

Alguns termos nesse texto são utilizados com o mesmo significado:

Controladora = Controller = Mobility Controller

Quadros = Frames

Access Point = AP = Ponto de Acesso

GRE/Tunnel

Esse modo utiliza um Tunnel GRE para encaminhar os dados do Access Point para a Mobility Controller. Quando um cliente envia um dado para um SSID (em um AP) que é configurado para utilizar o forwarding mode como tunnel mode, o AP encapsula o quadro 802.11 dentro de um frame 802.3 e encaminha o quadro para a Controladora Aruba.

Nesse processo nem todos os frames são tunelados e encaminhados a controladora, os quadros 802.11 para autenticação e resposta de associação são gerados diretamente no AP.

Para o tráfego que é encapsulado e enviado a controladora, a Mobility Controller removerá o encapsulamento no recebimento, aplicará regras de firewall ao tráfego do usuário e encaminhará o tráfego como solicitado.

Um Access Point Aruba configurado como Campus (CAP), todo tráfego de controle é comunicado com a controladora utilizando o protocolo PAPI, que não é criptografado. Caso haja a necessidade de criptografar a comunicação PAPI é sugerido a utilização juntamente com o CPsec (Control Plane Security) que criptografa a comunicação PAPI com IPsec.

Já os APs configurados como Remote (RAP), a comunicação deverá utilizar um túnel VPN L2TP/IPsec.

Com o modo túnel, todo tráfego é enviado para a Controller que é responsável por prover a visibilidade das configurações e trafego dos usuários de forma centralizada, facilitando a configuração das redes WLAN.

Bridge

O mode bridge permite ao Access Point (não a Controladora) processar os quadros, de forma similar aos APs individuais processam as informações. O AP irá responder qualquer requisição de autenticação e associação com as respostas referentes ao processo, removendo a criptografia dos frames recebidos  e criptografando os quadros de saída para a estação.

 O modo bridge também pode ser configurado em APs configurados como CAP e RAP, mas a sua comunicação com a Mobility Controller deverá ser criptografada com CPsec (CAP) e túnel L2TP/IPsec para RAP.

A Aruba não recomenda esse modo em razão do firewall stateful não ser aplicado.

Decrypt-Tunnel

Este método possui similaridade com o modo tunnel, entretanto os quadros enviados pelo cliente têm a sua criptografia removida e encaminhada dessa forma para a Controladora, encapsulando apenas o quadro 802.11 em um quadro 802.3.

Uma imagem contendo captura de tela

Descrição gerada automaticamente

Esse cenário pode ser utilizado para propósitos de segurança para inspeção e monitoração do tráfego por outras ferramentas ou diminuir o processamento ocorrido no processo de criptografia.

O modo decrypt só pode ser utilizado com RAP e CAP. Todo trafego de sinalização entre a controladora e o ponto de acesso deve ser criptografada com CPsec(CAP) ou L2TP/IPsec (RAP).

O modo decrypt deve ter uma atenção especial em cenários com RAP, pois o tráfego do usuário não é criptografado pelo RAP, criando um risco de segurança para o tráfego sobre a rede pública (Internet).

Split Tunnel

O modo split tunnel é disponível nos RAPs, e é também conhecido com policy-based forwarding.  Quando um RAP constrói um tunnel L2TP/IPsec com a Controladora, não é recomendável encaminhar todo tráfego de usuário pela Internet para a Mobility Controller, por isso é possível criar regras de encaminhamento de firewall para processar o tráfego wireless diretamente no RAP. Essas regras podem permitir o tráfego dos usuários serem encaminhado localmente ou para a Controladora, de acordo com as necessidades, como por exemplo, o trafego HTTP/HTTPS sair diretamente para a Internet.

Referências

Aruba Certified Design Professional_ Official Certification Study Guide ( HPE6-A47)

Westcott, David. – Understanding ArubaOS

Comware 7 – Configurando o GRE

O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de tuneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.

O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como o GRE não faz a criptografia, o GRE pode trabalhar em conjunto com IPsec para garantir a integridade das informações quando necessário.

Abaixo podemos observar a representação do encapsulamento de um pacote IP pelo GRE como também a inclusão de um novo cabeçalho.

GRE header

O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.

Segue abaixo um exemplo de configuração de um túnel GRE para Roteadores com o Comware 7, fechando a adjacência OSPF entre 2 roteadores separados por uma rede MPLS. Nos testes usamos o roteador HP VSR1000.

comware 7 GRE

Tabela de Rotas e tracert do Roteador R2

[R2]disp ip routing-table | inc O
192.168.1.0/24     O_INTRA 10  1563        192.168.13.1    Tun0

<R2>tracert 192.168.13.1
traceroute to 192.168.13.1 (192.168.13.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
 1  192.168.23.2 (192.168.23.2)  0.488 ms  0.523 ms  1.668 ms
 2  192.168.13.1 (192.168.13.1)  0.962 ms  5.463 ms  0.881 ms

<R2>tracert 192.168.1.1
traceroute to 192.168.1.1 (192.168.1.1), 30 hops at most, 52 bytes each packet, press CTRL_C to break
 1  192.168.1.1 (192.168.1.1)  1.116 ms  2.588 ms  1.731 ms

Referências

http://www.comutadores.com.br/roteadores-hp-6600-protocolo-de-tunelamento-gre/

http://www.rotadefault.com.br/protocolo-de-tunelamento-gre/

Roteadores HP 6600 – MPLS L2VPN com Martini através de um Túnel GRE

O script abaixo permite a extensão de um domínio de Broadcast através de uma rede IP utilizando o protocolo MPLS sobre um Túnel GRE sem a utilização de BGP em um roteador HP 6600.

Utilizei o cenário durante uma demanda para a extensão de um domínio de Broadcast entre 2 Data Centers Pares em quem o link dedicado para o Serviços de Computação em Nuvem sofreu atraso. O sincronismo dos Serviços  utilizando a camada de enlace (camada 2 do modelo OSI) foi estabelecido com a solução abaixo, visto que haviam restrições para configurar o mesmo serviço com MP-BGP por políticas de roteamento.

A solução permite o trânsito de quadros tagueados com 802.1q.

Obs: Antes de estabelecer o túnel GRE, certifique que as interfaces Loopback estejam acessíveis via Roteamento.

MPLS L2VPN Martini atraves de GRE

Espero ter sido útil. 🙂

Roteadores HP 6600 – Protocolo de Tunelamento GRE

O GRE (Generic Routing Encapsulation) é um protocolo de tunelamento que pode encapsular diversos protocolos dentro de túneis IP, criando links ponto-a-ponto virtuais entre roteadores remotos.

O protocolo é extremamente funcional em diversos cenários, pois foi desenvolvido para permitir que redes remotas pareçam estar diretamente conectadas. Como GRE não criptografa as informações que são transmitidas através do túnel, podemos utilizar o GRE em conjunto com IPsec para garantir a integridade das informações.

Abaixo podemos observar a representação de encapsulamento  de um pacote IP pelo GRE e a  inclusão de um novo cabeçalho.

GRE header

O interessante é que o protocolo de transporte poderia ser o IPv6 e o protocolo encapsulado  poderia ser o IPX, tráfego Multicast, etc; E ao ser entregue ao roteador de destino, o novo cabeçalho é removido e o pacote é entregue intacto.

Agora você deve estar se perguntando. Em quais situações podemos usar o GRE ? Veja  o cenário:

GRE HPN cenario

Você em um dia normal como analista de redes e seu gerente de TI te informa que  sua   empresa acaba de adquirir uma nova filial e eles precisam ter acesso a alguns servidores que   estão na rede local do ambiente que você administra.  Depois de concluir todo processo de contratação do link e a conectividade com a filial estar finalizada, seu gerente de TI lhe informa   que na nova filial utilizará OSPF para declarar as redes locais.

Agora você pensa: como podemos configurar o OSPF nesses roteadores se eles não estão diretamente conectados? Como administrar o processo de roteamento via uma rede gerenciada pela Operadora como por exemplo, com MPLS,  que não está emulando um Lan-to-Lan ? É ai que entra o Túnel GRE.

Configuração

Antes de criar o tunnel, certifique-se que a origem e o destino mapeados na Interface Tunnel estejam acessíveis via roteamento. No nosso exemplo, usaremos  a Loopback.

Como os roteadores simularão uma conexão ponto-a-ponto, eles irão trocar informações  de  roteamento através do túnel como se estivessem diretamente conectados.

GRE HPN configuração v2

Por padrão o Comware habilita o protocolo GRE em túneis sem a necessidade de configuração adicional. Caso você precise utilizar uma Interface Tunnel para alguma outra função, segue abaixo algumas possibilidades:

 

[RA-Tunnel10]tunnel-protocol ?
  dvpn       Dynamic Virtual Private Network
  gre        Generic Routing Encapsulation
  ipsec      IPsec tunnel encapsulation
  ipv4-ipv4  tunnel mode ipv4 over ipv4
  ipv4-ipv6  tunnel mode ipv4 over ipv6
  ipv6-ipv4  tunnel mode ipv6 over(to) ipv4
  ipv6-ipv6  tunnel mode ipv6 over ipv6
  mpls       Multiprotocol Label Switching

Considerações para a utilização de Tunnel em Switches HP baseados no Comware

A utilização de interface Tunnel em Switches HP baseados no Comware pode ser um pouco mais complicada que em roteadores. Antes de utilizarmos o processo acima  é necessário criar uma configuração de “Service Loopback” (em alguns modelos de Switches), vincular à uma porta não utilizada (vazia) e também vincular o serviço ao Tunnel. Segue abaixo os passos:

• Crie um “tunnel-type service loopback group’.

• Adicione uma porta não utilizada ao “Service loopback group”.

# Criando o “Service-loopback” group 1 e especificando o tipo como tunnel.
[SwitchA] service-loopback group 1 type tunnel

# Vinculando a porta Giga 1/0/3 para o “Service-loopback” group 1. 
#Desabilite o STP e o LLDP da interface.
[SwitchA] interface GigabitEthernet 1/0/3
[SwitchA-GigabitEthernet1/0/3] undo stp enable
[SwitchA-GigabitEthernet1/0/3] undo lldp enable
[SwitchA-GigabitEthernet1/0/3] port service-loopback group 1
[SwitchA-GigabitEthernet1/0/3] quit

# Aplique  o “Service-loopback” group 1 à interface tunnel.
[SwitchA] interface tunnel 0
[SwitchA-Tunnel0] service-loopback-group 1
[SwitchA-Tunnel0] quit
# O tunnel ficará up mesmo que a outra ponta não esteja configurada

Até a próxima 

Referência

http://www.rotadefault.com.br/protocolo-de-tunelamento-gre/