Empresas que possuem diversos sites espalhados pelo Brasil (ou mundo) muitas vezes precisam que essas localidades se comuniquem entre si. Quando estamos pensando em ambientes ‘pequenos’ manter a conectividade entre as localidades não é um desafio tão grande, mas a medida que o ambiente cresce, manter uma rede full-mesh se torna impraticável.

Considerando a topologia abaixo, temos uma rede com 4 sites, um número relativamente baixo para alguns modelos de negócio, algumas empresas passam de centenas de sites e é responsabilidade da equipe de conectividade/redes garantir que a comunicação necessária para o negócio funcionar ocorra de maneira adequada. Essa comunicação pode ocorrer de diversas maneiras, mas muitas vezes a opção mais ‘econômica’ é o estabelecimento de VPNs Site-to-Site entre as localidades.

Muitas vezes esses sites hospedam serviços distintos que são consumidos/acessados entre si, sendo assim, se faz necessário o estabelecimento de túneis VPN entre cada endereço, criando uma malha ‘full-mesh’ ou seja, todos os sites possuem comunicação/conexões entre si.

Considerando que cada site possui apenas uma conexão de internet, estamos falando de 6 túneis, os quais precisarão ser criados manualmente. Esse cálculo pode ser realizado com a fórmula ‘N(N-1)/2’, onde ‘N’ é a quantidade de sites.

Quando um quinto site for adicionado, o número de túneis VPN para manter a arquitetura full-mesh pula de 6 para 10, com 6 sites temos 15 túneis, com 7 sites temos 21 túneis...como pode ver o número começa a sair do controle, manter todos esses túneis se torna um grande desafio, principalmente em locais remotos onde a qualidade/confiabilidade de circuitos não é adequada.

A tabela abaixo apresenta a quantidade de túneis necessários para manter a topologia full-mesh com até 50 sites (número que pode ser maior dependendo do tamanho da rede e requisitos).

Conforme apresentado, uma rede full-mesh (50 localidades), onde cada site possui apenas um link necessitaria de 1,225 túneis em total, se cada site possuir 2 links esse número pula para 4,900 túneis, a manutenção disso se torna quase impraticável. Mesmo que a estrutura seja bem estável e pouco problemática a topologia se torna um ‘polvo’ que vai estar sempre precisando de alguém ‘apertando um parafuso’ e ‘consertando vazamentos’, tempo que poderia ser mais bem empregado em outra ação.

Quando falamos de Fortinet a solução oferecida para esse desafio é Auto Discovery VPN (ADVPN), apenas para referência a solução oferecida pela Cisco é Dynamic Multipoint VPN (tópico que abordarei em outro artigo).

ADVPN permite que túneis dinâmicos entre firewalls sejam criados sob demanda, vamos olhar novamente a topologia inicial.

Considerando o exemplo abaixo, temos a situação em que cada site hospeda serviços e comunicação entre eles é necessária, numa arquitetura Hub-and-Spoke todo o tráfego entre os Spokes precisa passar pelo Hub (Site 01), o que pode não ser a melhor opção em questão de performance, no mesmo exemplo podemos ver que tráfego gerado do Site 03 até o Site 04 tem uma latência de 90ms (30 até o Hub e mais 60 do hub ao site destino).

A latência em algumas situações pode ser bem maior do que a apresentada, principalmente se estamos falando de sites internacionais.

Numa estrutura com ADVPN implantada teríamos a seguinte situação:

• Tráfego é enviado do Site 03 para o Hub (com destino ao servidor no Site 04)
• O tráfego é enviado pelo Hub para o Site 04, porém o Hub sabe que ao invés de ficar no meio da comunicação é melhor que os dois sites se comuniquem entre si diretamente
• O Hub avisa ao Site 03 que é possível o estabelecimento de um túnel dinâmico com o destino que ele está buscando, o Hub faz um isso enviando um ‘Shortcut Offer’ (oferta de atalho)
• O Site 03 recebe a oferta e confirma que deseja estabelecer o túnel dinâmico com o destino, isso é feito através de um ‘Shortcut Query’ (Consulta/requisição de Atalho)
• O Hub encaminha a solicitação ao Site 04
• O Site 04 recebe a requisição e encaminha um ‘Shortcut Reply’ para o Site 03 através do Hub e aguarda os pacotes para estabelecimento do túnel chegar do Site 03
• O Hub encaminha o ‘Shortcut Reply’ ao Site 03
• Site 03 recebe as informações e estabelece o túnel diretamente com o Site 04
• A partir desse momento não é mais necessário utilizar o Hub para alcançar o Site 04 (e vice-versa)

O diagrama abaixo mostra os passos e processos de estabelecimento/negociação do túnel:

Voltando ao exemplo original, podemos ver que a comunicação entre os Sites remotos com ADVPN pode apresentar uma performance elevada em comparação com o modelo Hub-and-Spoke (ao invés de termos 90ms de latência temos apenas 40).

É importante mencionar que para a comunicação/comutação do tráfego entre os sites ocorra, se faz necessário a utilização de um protocolo de roteamento. Fortinet atualmente suporta BGP, OSPF e RIP. Sendo BGP o protocolo mais recomendado.

Utilizando BGP, o HUB opera como Route-Reflector, sendo assim, as rotas enviadas/aprendidas pelos sites remotos são encaminhadas para os demais.

 Como pudemos ver, ADVPN permite que túneis dinâmicos sejam estabelecidos entre os sites remotos permitindo uma topologia full-mesh, mas sem a necessidade de manter túneis estáticos com cada site, se Site 01 precisa alcançar algo no Site 02 um túnel direto é estabelecido entre eles, isso permite que dezenas, centenas ou até milhares de sites possam se comunicar entre si de forma dinâmica.

Também é importante mencionar que uma topologia ADVPN não necessariamente requer que todos os sites estabeleçam túneis diretos. Se por algum motivo um site ‘X’ não possa participar da topologia ADVPN, é só via configuração desabilitar o estabelecimento de túneis dinâmicos nesse site.

Um dos objetivos era também apresentar a forma de configuração da solução, porém a Fortinet oferece um guia bem completo que apresenta um exemplo de configuração:

https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/985659/advpn-and-shortcut-paths

A solução ADVPN por si só já resolve o problema da complexidade de manter diversos túneis estáticos, mas sobre essa topologia é possível (e recomendado) utilizar também SDWAN, principalmente em situações em que os sites possuem mais que um circuito de internet (ou qualquer outro meio de comunicação).

Utilizar SDWAN sobre ADVPN permite que além da facilidade de túneis dinâmicos, seja possível fazer proveito de caminhos alternativos entre os sites. Por exemplo, mesmo com um túnel direto entre os Spokes, pode ser que a comunicação para o outro Spoke via o Hub seja mais interessante, além de funcionar como um possível caminho backup em caso de falha de comunicação entre os spokes.