Olá Pessoal,
Como vocês sabem a todo momento estou trazendo ítens adicionais para facilitar e oferecer escalabilidade dentro das estruturas Meraki, e hoje venho aqui trazer mais um teste executado e para alguns clientes finais, bem como para as corporações será de grande utilidade.
Porque digo isso? É porque hoje temos muitas estruturas que estão sendo disponibilizadas nos provedores de cloud ( Azure, AWS, GCP, IBM, Alibaba, etc ). Desta forma, precisamos oferecer escalabilidade para nossos pontos remotos, fazendo que via uma Infra Pública ou Privada você continue utilizando seus recursos em seus parceiros.
Com isso vem também a pergunta, Meraki pode-se conectar diretamente com esses parceiros? Você não consegue fechar uma VPN/Tunnel somente com equipamentos Meraki? Como é feito esse tipo de configuração?
Pois bem, recomendo você seguir nosso post que iremos detalhar todas essas dúvidas. 😉
Definição da Topologia
Para iniciarmos gostaria detalhar um pouco como esta nosso cenário, para que a partir dele vocês possam pensar se de alguma forma atende as suas necessidades, e as possíveis alterações que possa ser inserido conforme seu ambiente cresça internamente ( on-premises ) ou aplicações em Cloud.
Vale ressaltar que aqui estou simulando como sendo um HUB ( Meraki ) e por consequência ele pode ser considerado um Datacenter ou até mesmo um Spoke ( Meraki ), entretanto existem algumas restrições que estariam relacionados a sua estrutura na Cloud. Segue abaixo minha topologia:
Detalhamento da Tecnologia
Para criar essa demanda, foi utilizada uma conta ( Free Trial ) na Azure para que pudêssemos instalar os componentes necessários para esse ambiente. Após ler a documentação da Azure, identifiquei que temos a possibilidade de criar um tunnel IPSEC diretamente através de um componente denominado como ” VPN Gateway ” e com isso não haveria a necessidade de termos um vMX100 da Meraki instalado através do marketplace .
Entretanto, devido a não termos instalado um vMX, muito dos componentes e funcionalidades Meraki não será utilizada, mas o proposito aqui é justamente iniciar uma VPN ( Point-to-Point ) entre um device Meraki ( MX ) com uma estrutura de terceiros. Aqui podemos também pensar que esse terceiro seria um roteador Cisco ou Firewall Cisco.
Sempre que pensamos em nuvem precisamos observar as especificações/capacidade de cada componente para que você possa fazer o ” deploy ” de maneira correta, com isso existe as especificações conforme abaixo:
Para maiores detalhes sobre essas especificações recomendo observar neste link da Azure. Seguindo nossa linha detalhamento, temos que observar que Meraki utiliza apenas IKEv1, com isso precisamos observar que o ” VPN Gateway Azure ” no modo ” Basic ” não consegue fazer negociação em IKEv2, portanto se esse tutorial ajudar a montar essa estrutura com outro vendor é importante observar esse detalhe.
Com esses dados em mãos precisamos iniciar os trabalhos e subir a infra-estrutura na cloud para que possamos receber essa conexão vindo de nosso Meraki. Para esse parâmetro recomendo ler esse documento que detalha como criar seu ” VPN Gateway “, mas aqui também vou dar algumas dicas e as telas dedicadas para nosso ambiente.
Para meu ambiente eu criei um ” Resource Group ” dedicado para esse teste, conforme podem observar abaixo:
Antes de criar nosso VPN Gateway é necessário criar nossa rede virtual ” VNET “, para que seja nosso ponto de segmentação em nosso ambiente. Se desejar obter maiores detalhes você pode consultar a documentação do ” Virtual Network “, e mais abaixo você pode encontrar ele para adicionar em seu ” resource group “.
Com isso agora vamos criar nosso range relacionado ao nosso ” Address space ” que por consequencia eu coloquei o /16, pois a partir deles vamos criar as segmentações ( VLANs ) dentro dessa VNET. Portanto, foi definido uma sub-rede para eu associar uma máquina virtual, e assim efetuar apenas os testes básicos posteriormente. Segue abaixo a relação das definições:
Caso em um futuro próximo você deseje adicionar mais VLANs dentro de seu segmento, você pode facilmente criar conforme abaixo:
Após isso você irá adicionar seu “ Virtual Network Gateway “, ele que de fato é seu ” appliance virtual ” que irá processar todos seus dados que irão ser encaminhados para sua estrutura virtual, ou muitas das vezes também podemos denominar como ” HUB “.
Quando fizer o deploy do VPN Gateway, alguns parâmetros precisam ser preenchidos para que o processo seja finalizado e de fato ele seja instalado dentro de seu resource group. Em algumas situações o deploy dessa instância pode levar uns bons minutos. ( 15 a 20 minutos ).
Na figura acima podemos observar que estou definindo um nome para meu ” Gateway “. Como explicado anteriormente, olhando para o cenário Meraki ( S2S com vendor distinto ) necessitamos selecionar o ” Policy-Based ” que está atrelado automaticamente SKU ” Basic “, bem como essa função precisa ser selecionada, pois nossa VPN no Meraki não teremos a possibilidade de configurar roteamento dinâmico, e sim ele vai usar uma ” rota estática ” apontando para esse tunnel IPSEC. Temos um recurso para selecionar esse failover de tunnel no Meraki, utilizando ” TAGs “, mas irei detalhar posteriormente essa demanda.
Outro detalhe que estou criando um novo IP Público, pois não tenho reserva de IP Público na Cloud, porém a partir do momento que seu Gateway Azure adquirir um IP Publico da Cloud, ele sempre irá ser fixado para você, desta forma seus spokes podem sempre fechar no mesmo IP.
Neste momento precisamos criar nosso “ Local Network Gateway “, para que possamos associar nosso endereço público ” Meraki ” com a nossa Cloud, bem como mencionar para ele quais são os endereços que iremos buscar do outro lado do Meraki, ou seja, a sua LAN que está atrás de seu MX. Neste caso temos opção de BGP, mas para nosso exemplo não foi configurado pelos parametros já mencionados anteriormente.
A rede adicionada como 192.168.2.0/27 será para demonstrar para vocês sobre o controle que temos em ambos os lados ( Cloud e Meraki MX ), pois nesse segmento atrás do MX é de clientes que podem fechar uma VPN como o MX, que por consequencia ele também irá oferecer todos os serviços que estão hospedados na Cloud.
Finalmente agora iremos configurar nossa conexão ( ShareKey, Gateway, Tipo de Conexão ). Para isso devemos ir em nosso local network gateway executado acima para configurar. Verifique abaixo:
Após, você configurar seu Meraki poderá observar o status da conexão no portal através dessa nova conexão.
Devido a todo esse processo, resolvi criar uma maquina virtual Ubuntu para que eu pudesse adquirir um IP Privado na minha ” VNET ” e assim eu pudesse fazer as validações relacionadas a caminho ( traceroute ) e a disponibilidade ( ping ). A única disponivel de fato nos ” marketplace ” é sempre Server, mas não tenho nenhum serviço que é de fato necessário para nosso teste, será para adquirir apenas um IP Privado na interface e possamos fazer de minha máquina ” on-premise ” chegando na cloud. Segue a imagem que usei abaixo:
Detalhamento sobre VPN ( S2S ) no Meraki
Para nossa demanda dentro do portal Meraki temos poucas configurações para executar, pois ele de fato é simples e objetivo. Entretanto, devemos ressaltar que para concretizar a configuração de seu MX, precisamos definir ele como ” HUB ” ou ” Spoke ” e assim você terá opção de fazer o conexão ponto a ponto ( VPN ). Para isso devemos validar acessando Security & SD-WAN -> Site-to-Site VPN conforme abaixo:
Após esse processo, vamos definir as configurações do meu peer que foi criado na Cloud, bem como vocês pode perceber que aqui também vamos definir quais são endereços que estão atrás do meu ” Virtual Gateway Network ” e nossa key definida anteriormente na cloud.
Talvez vocês me perguntem, como ele adicionou as policies relacionado ao IPSEC. Aqui que temos as facilidades, pois já está tudo definido as politicas mais usuais baseado no seu fornecedor de Cloud que você esta fechando sua VPN. Logo abaixo você já pode observar as politicas tradicionais ( Phase 1 e Phase 2 ) para Azure.
Com isso finalizamos nossas configurações relacionadas ao ambiente Meraki, e assim devemos proceder para nossas validações em ambos os provedores ( Meraki e Azure ). Para isso, vamos validar os status logo abaixo:
No Dashboard Meraki podemos também consultar na aba de Logs, conforme abaixo:
Testes executados na Infra
Como efetuamos todas essas configurações, vamos agora consolidar o funcionamento fim-a-fim da solução para garantirmos que está tudo corretamente para nosso usuário final. Para isso, vamos apenas consolidar que nosso segmento de LAN ( MX ) está sendo permitindo para ser roteado por dentro de nossa VPN, ou seja, vemos aqui que somente minha rede 192.168.0.0/24 está liberada.
Segue validação sendo executada através da máquina on-premises.
Segue consolidação sendo feita através da console da Cloud:
Conclusão
De fato após a construção de sua infra na cloud as configurações dentro do ambiente é muito prático e facil de gerenciar. O único ponto que acho ainda crítico que estamos relacionado a trabalhar com IKEv1 e a menção de que não iremos usar um protocolo de roteamento, e somente iremos ficar mencionando quais as redes que deverão trafegar por dentro da VPN.
Isso dificulta no sentido de se você tiver redes novas sendo acrescentadas na LAN Meraki, você necessariamente também irá precisar configurar essa nova rede na cloud.
Comentários Recentes