LAD Cloud Experts Portuguese Blog
-
Networking
April 20, 2020
OCI - Gateways de Comunicação (Parte 3)
Em meu último post “OCI - Gateways de Comunicação (Parte 2)”, expliquei em detalhes como conectar seu data center on-premises na Cloud da Oracle usando uma VPN IPSec.
Neste post, iremos avançar e criar uma configuração de rede conhecida como “Roteamento de Trânsito” (Transit routing) ou Hub-and-Spoke layout. Basicamente, iremos unir as construções que realizamos nos posts “OCI - Gateways de Comunicação (Parte 1)” e “OCI - Gateways de Comunicação (Parte 2)”, utilizando mais um dos gateways de comunicação disponíveis na Cloud da Oracle, o Local Peering Gateway (LPG).
1. O que é Roteamento de Trânsito (Transit Routing)?
É uma configuração de rede no qual permite que seu data center local (on-premises), acesse recursos ou utilize serviços Oracle através da conectividade de uma VCN. A conectividade entre seu data center e a Cloud da Oracle pode ser via FastConnect ou IPSec VPN.
Tendo a conectividade estabelecida, e o roteamento devidamente configurado, os dados então “transitam” pela VCN até seu destino final.
Será criada uma VCN na qual iremos chamar de vcn-hub. Esta torna-se o “ponto de entrada principal” entre sua rede on-premises para outras VCNs, também chamadas de spoke, e/ou serviços Oracle existentes na cloud. É por isto que também chamamos esta configuração de Hub-and-Spoke.
Falando desta arquitetura, ela nos traz algumas vantagens:
- Separação das redes: A ideia é termos uma separação dos ambientes em redes diferentes (VCNs). Aqui podemos criar uma rede para nossos serviços e servidores de produção, uma rede para homologação e outra para desenvolvimento. Cada uma com políticas de acessos diferentes.
- Ponto único de entrada, conexão VPN ou FastConnect: Conectamos nosso FastConnect ou VPN em uma única VCN, e a partir dela temos acesso a todas outras redes e serviços da Oracle Cloud.
- Acesso privado ao serviços da Oracle: Através desta arquitetura é possível acessar de modo privado, a partir do seu on-premises, os serviços da Oracle Cloud sem que os dados “passem” pela Internet. Toda comunicação é feita via endereço IP privado.
NOTA: Para saber detalhes sobre como conectar seu datacenter à Oracle Cloud usando uma VPN, consulte este post.
NOTA: Lembrando que as VCNs devem estar na mesma região, porém podem estar em diferentes Tenancy.
2. Ambientes segregados na Nuvem
Irei apresentar um exemplo no qual eu particularmente gosto bastante quando falamos de rede ou VCN de Trânsito. Observe o desenho abaixo:
Neste exemplo, temos do lado da Oracle Cloud três VCNs diferentes. Começando pela vcn-hub, que possui uma conexão VPN para interligar o on-premises à Oracle Cloud. A vcn-prod que é uma rede para conter os recursos de produção, e a vcn-dev para conter recursos de desenvolvimento. Todas elas são conectadas por um recurso especial presente na Oracle Cloud que irei apresentar neste post. O Local Peering Gateway.
NOTA: Por padrão você pode criar até 10 VCNs. Consulte este link aqui para saber sobre os limites, além de informações para solicitar aumento quando necessário.
Criamos diversas redes por uma simples razão, de ter os ambientes de desenvolvimento e produção separados. Do ponto de vista de arquitetura, essa seria uma boa prática pois o desenvolvimento de uma aplicação ocorre em um ambiente separado, evitando qualquer problema ou interferência no ambiente produtivo. Para melhorar, poderíamos ter também uma vcn-hml para homologação e testes da aplicação.
Diferentes ambientes para diferentes estágios do ciclo de vida de uma aplicação. Segregar para atingir a qualidade, essa é a ideia!
3. Decompondo o desenho em recursos Cloud
A partir do desenho apresentado, temos os seguintes recursos que serão criados:
- vcn-hub → VCN hub 10.50.0.0/28 localizada na região de Ashburn, VA.
- subnprv-1_vcn-hub → Subrede privada 10.50.0.0/29 da VCN hub.
- secl-1_subnprv-1_vcn-hub → Security List da subrede privada da VCN hub.
- rtb_subnprv-1_vcn-hub → Route Table da subrede privada da VCN hub.
- vm-lnx-1_subnpub-1_vcn-hub → Máquina Virtual Pritunl para VPN Client-To-Site.
- lpg_vcn-hub_vcn-prod → Conexão via Local Peering Gateway entre a vcn-hub e vcn-prod.
- rtb_lpg_vcn-hub_vcn-prod → Route table do Local Peering Gateway vcn-hub e vcn-prod.
- lpg_vcn-hub_vcn-dev → Conexão via Local Peering Gateway entre vcn-hub e vcn-dev.
- rtb_lpg_vcn-hub_vcn-dev → Route table do Local Peering Gateway vcn-hub e vcn-dev.
- drg_vcn-hub → Gateway de Roteamento Dinâmico (DRG) da VCN hub.
- rtb_drg_vcn-hub → Route Table do Gateway de Roteamento Dinâmico (DRG) da VCN hub.
- vcn-prod → VCN de produção 10.60.0.0/16 localizada na região de Ashburn, VA.
- lpg_vcn-prod_vcn-hub → Conexão via Local Peering Gateway entre vcn-prod e vcn-hub.
- vcn-dev → VCN de desenvolvimento 10.70.0.0/16 localizada na região de Ashburn, VA.
- lpg_vcn-dev_vcn-hub → Conexão via Local Peering Gateway entre vcn-dev e vcn-prod.
NOTA: Para não ficar muito extenso, listei somente os recursos mais relevantes para demonstração do nosso exemplo.
NOTA: Antes de prosseguir, é recomendado que você leia os posts anteriores “OCI - Gateways de Comunicação (Parte 1)” e “OCI - Gateways de Comunicação (Parte 2)”, para detalhes sobre a criação de VCN, route table, security lists, VPN, etc. Aqui não entraremos nestes detalhes.
4. Conectando as VCNs via Local Peering Gateway
A partir das nossas VCNs já criadas, iremos demonstrar como elas se conectam através do recurso Local Peering Gateway. Este gateway possibilita que as instâncias criadas dentro de duas VCNs conectadas, se comuniquem usando o seu endereço IP privado.
NOTA: Lembrando que as VCNs devem ser criadas dentro da mesma região, e os blocos IPv4 das VCNs devem ser diferentes. Além disto, o Local Peering Gateway pode conectar VCNs de diferentes tenancy.
Networking → Virtual Cloud Networks
1. A partir do menu principal, em “Networking”, “Virtual Cloud Networks”, podemos observar nossas VCNs já criadas:
2. Clique sobre “vcn-hub” para abrir suas configurações. Na tela seguinte, clique em “Local Peering Gateways”:
3. Em seguida, clique no botão “Create Local Peering Gateway”:
4. Após preencher com o nome correto do recurso, clicamos no botão “Create Local Peering Gateway” para que ele seja criado:
5. Pronto! Temos o nosso primeiro Local Peering Gateway criado. Perceba pela imagem abaixo que ele ainda não está conectado:
6. Devemos criar outro Local Peering Gateway, agora na vcn-prod. O processo de criação é o mesmo que foi apresentado, exceto que o recurso será criado dentro da vcn-prod:
NOTA: Perceba que o nome do recurso agora faz referência contrário, a partir da vcn-prod para vcn-hub.
7. Vamos voltar as configurações do Local Peering Gateway dentro da vcn-hub. Iremos expandir o menu do recurso lpg_vcn-hub_vcn-prod clicando em “Establish Peering Connection”, localizado no canto direito da tela:
8. Na tela que irá se abrir, iremos selecionar a vcn-prod e o recurso Local Peering Gateway lpg_vcn-prod_vcn-hub que acabamos de criar. Para finalizar, clique no botão “Establish Peering Connection”:
9. Pronto! Temos o peering estabelecido entre vcn-hub e vcn-prod:
10. Repita o mesmo procedimento para conexão entre vcn-hub e vcn-dev.
Após conclusão dos procedimentos, podemos observar na tela do Local Peering Gateway da vcn-hub, que temos as conexões devidamente estabelecidas:
5. Configurando o Roteamento
Após conectarmos as VCNs via Local Peering Gateway, temos que configurar todo o roteamento entre o on-premises e os recursos na Oracle Cloud. Para que os detalhes fiquem mais claros, criei o desenho abaixo que exibe somente as tabela de roteamento e suas regras:
NOTA: É uma boa prática do ponto de vista de segurança, ter o “roteamento de trânsito” funcionando somente entre as subredes privadas na cloud. Não seria legal uma subrede pública conseguir se comunicar com o seu on-premises. Fica a dica!
Seguimos por partes ...
5.1 - Configurando o roteamento no DRG
Começando pelo DRG. Sabemos que todo pacote de dados entre o seu on-premises e a Oracle Cloud passa por ele (drg_vcn-hub). Por conta disto, ele deve ser devidamente configurado para saber “alcançar” a vcn-prod e vcn-dev.
Vamos criar uma nova tabela de roteamento e anexá-la ao drg_vcn-hub:
Networking → Virtual Cloud Networks → vcn-hub → Route Tables
1. A partir da vcn-hub, crie uma nova tabela de roteamento com o nome rtb_drg_vcn-hub:
2. Dentro das suas configurações, iremos inserir duas regras de roteamento. Cada regra deve conter uma de nossas redes IP como destino (vcn-prod e vcn-dev), e o Local Peering Gateway correspondente.
Nas regras acima, estamos dizendo para que o DRG consiga alcançar a rede 10.60.0.0/16 (vcn-prod), ele deve encaminhar os pacotes de dados para o Local Peering Gateway de nome lpg_vcn-hub_vcn-prod. O mesmo princípio se aplica para a rede 10.70.0.0/16 (vcn-dev), porém para o outro Local Peering Gateway lpg_vcn-hub_vcn-dev.
NOTA: Para saber detalhes de como criar e configurar uma tabela de roteamento, consulte este post aqui.
Após isto, devemos associar a tabela de roteamento rtb_drg_vcn-hub ao DRG drg_vcn-hub.
Networking → Virtual Cloud Networks → vcn-hub → Dynamic Routing Gateways
3. Dentro das configurações da vcn-hub, clique em “Dynamic Routing Gateways”. Clique em “Associate Route Table” a partir do menu de configuração do drg_vcn-hub:
4. Na tela que irá se abrir, selecione a tabela de roteamento rtb_drg_vcn-hub e em seguida clique no botão “Associate”:
5. Pronto! O drg_vcn-hub agora possui a tabela de rota rtb_drg-vcn-hub associada:
5.2 - Configurando o roteamento nos LGPs
Após configurar as rotas do drg_vcn-hub, chegou a hora de configurar o roteamento dos Local Peering Gateways. Lembrando que somente os Local Peering Gateways criados dentro da vcn-hub é que precisam ter uma tabela de roteamento associada.
Networking → Virtual Cloud Networks → vcn-hub → Route Tables
1. Vamos criar duas tabelas de roteamento, uma para cada Local Peering Gateway criado dentro das configurações da vcn-hub:
| Tabela de Roteamento | Local Peering Gateway |
|---|---|
| rtb_lpg_vcn-hub_vcn-prod | lpg_vcn-hub_vcn-prod |
| rtb_lpg_vcn-hub_vcn-dev | lpg_vcn-hub_vcn-dev |
NOTA: Para saber detalhes de como criar e configurar uma tabela de roteamento, consulte este post aqui.
2. Essas tabelas de roteamento terão somente uma regra. A rede IP do on-premises como destino, passando pelo drg_vcn-hub:
3. Como resultado, teremos algo semelhante a imagem abaixo:
4. Tendo as tabelas de roteamento prontas, vamos associar cada uma ao seu respectivo Local Peering Gateway presente na vcn-hub. O processo para associação é bem semelhante ao do DRG. Basta selecionar o recurso, clicar em “Associate Route Table”, e seguir os passos da tela que irá se abrir:
5. Pronto! Ambos Local Peering Gateways conectados e com suas tabelas de rotas associadas. Teremos algo parecido com a imagem abaixo:
5.3 - Configurando o roteamento das Subredes
A comunicação entre diferentes subrede, em diferentes VCNs, necessita do roteamento entre elas devidamente configurado. É verdade também, que toda subrede que precisa se comunicar com o on-premises, necessita também do roteamento devidamente configurado.
NOTA: Subredes criadas dentro da mesma VCN não necessitam de regras de roteamento para se comunicarem.
Visto isto, iremos começar pela vcn-hub. Vamos configurar as regras de roteamento da subrede privada subnpriv-1_vcn-hub.
Networking → Virtual Cloud Networks → vcn-hub → Route Tables
1. Em “Networking”, “Virtual Cloud Networks”, clique na “vcn-hub” e depois em “Route Tables”.
2. Localize a tabela de roteamento rtb_subnprv-1_vcn-hub e adicione as regras conforme exibido abaixo:
NOTA: Lembrando que você pode configurar as mesmas regras para qualquer outra subrede que tenha sua tabela de rotas independente dentro da vcn-hub.
Vamos finalizar configurando as regras de roteamento da subrede subnpriv-1_vcn-prod da vcn-prod, que é um pouco diferente.
Networking → Virtual Cloud Networks → vcn-prod → Route Tables
1. Novamente a partir de “Networking”, “Virtual Cloud Networks”, clique agora em “vcn-prod” e depois em “Route Tables”.
2. Localize a tabela de roteamento rtb_subnprv-1_vcn-prod e adicione as regras conforme exibido abaixo:
Configurações concluídas ...
6. Dica final
Se você vem acompanhando a sequência dos meus posts, especificamente o post “OCI - Gateways de Comunicação (Parte 2)” no qual criamos um servidor Linux, configuramos e instalamos o software Libreswan para conexão VPN IPSec à Cloud da Oracle. Lembre-se de acrescentar o roteamento para as duas redes (vcn-prod e vcn-dev) que acabamos de criar:
|
[root@libreswan ~]# ip route add 10.60.0.0/16 nexthop dev vti1 nexthop dev vti2 |
Além disto, não se esqueça de permitir acesso configurando as respectivas Security Lists das subredes. Para maiores detalhes, consulte este post aqui.
7. Conclusão
Neste post, procurei demonstrar uma configuração de rede na Cloud da Oracle um pouco mais avançada. Eu particularmente gosto bastante desta configuração por termos os ambientes separados uns dos outros. Com as devidas regras de segurança e políticas de acesso aplicadas, evitamos qualquer interferência entre os ambientes, principalmente protegendo uma aplicação em execução no ambiente de produção.
Muitas pessoas do seu time interno desenvolvem (ambiente de desenvolvimento), seu cliente externo verifica e homologa (ambiente de homologação) e o mundo utiliza (ambiente de produção). Essa é a ideia!
Espero ter ajudado. Vamos em frente!
Um Abraço!