Centralize a comunicação por meio de uma arquitetura VPC Transit Hub and Spoke - Parte um
Este tutorial pode incorrer em custos. Use o Estimador de custos para gerar uma estimativa do custo baseada em seu uso projetado.
Um Virtual Private Cloud (VPC) fornece isolamento de rede e segurança no IBM Cloud. Uma VPC pode ser um bloco de construção que encapsula uma divisão corporativa (marketing, desenvolvimento, contabilidade, etc.) ou uma coleção de microsserviços pertencentes a uma equipe de DevSecOps. Os VPCs podem ser conectados a um empreendimento no local e um ao outro. Isso pode criar a necessidade de rotear o tráfego através de dispositivos de gateway de firewall centralizados. Este tutorial caminhará pela implementação de um hub e arquitetura falada retratada nesta visão de alto nível:
Esta é parte um de um tutorial de duas partes. Esta parte introduzirá o hub de trânsito VPC como o conduto para a empresa. Empresa para falar conectividade VPC entre microserviços será discutida e implementada. Esta arquitetura apoiará uma série de cenários:
- O hub é um ponto central de roteamento de tráfego entre a empresa e a nuvem.
- O tráfego corporativo para nuvem é roteado por meio do hub e pode ser monitorado e registrado por meio de um dispositivo Network Function Virtualization (NFV) em execução dentro do hub.
- O hub pode monitorar todo ou parte do tráfego: spoke <-> spoke, spoke <-> transit ou spoke <-> corporativo.
- O hub pode conter microsserviços compartilhados usados por spokes..
- O hub pode conter recursos de nuvem compartilhados, como bancos de dados, acessados por meio de gateways de terminais privados virtuais controlados por grupos de segurança de VPC e listas de controle de acesso de sub-rede, compartilhados por spokes
- O hub pode segurar os recursos de VPN que são compartilhados pelos spokes.
(Parte dois) irá estender este tutorial roteirizando todo o tráfego VPC para o tráfego VPC através do hub, implementar um firewall altamente disponível-roteador e tráfego de rotas para IBM Cloud instâncias de serviço com resolução DNS.
Há um acompanhante GitHub repositório que provisiona recursos e configura roteamento em camadas incrementais. No tutorial as camadas finas permitem a introdução de desafios e soluções de tamanho de mordida.
Durante a viagem os seguintes são explorados:
- Planejamento de Rede VPC.
- VPC egress e roteamento de ingresso.
- Conectividade via IBM Cloud® Direct Link.
- Conectividade via IBM Cloud Transit Gateway.
- Funções de Rede Virtual.
Uma arquitetura em camadas introduzirá recursos e demonstrará conectividade. Cada camada adicionará conectividade e recursos adicionais. Uma camada pode introduzir pequenos problemas e demonstrar soluções no contexto de uma arquitetura maior. As camadas são implementadas usando Infra-estrutura como Código na forma de arquivos de configuração Terraform. Será possível alterar parâmetros, como número de zonas, alterando uma variável Terraform.
Objetivos
- Entenda os conceitos por trás de um hub baseado em VPC e modelo falado.
- Entenda a implementação de um firewall-roteador e um ambiente VPC de trânsito.
- Entenda o ingresso VPC e o roteamento de egressos.
- Identificar e resolver opcionalmente problemas de roteamento assimétrico.
- Conecte VPCs através de um Transit Gateway.
Antes de Iniciar
Este tutorial requer:
terraform
para usar Infraestrutura como código para provisionar recursos,python
para executar opcionalmente os comandos pytest,- Implementar um firewall-roteador exigirá que você ative verificações de spoofing IP,
- Uma chave SSH para se conectar aos servidores virtuais. Se você não tiver uma chave SSH, siga as instruções para criar uma chave para a VPC.
Veja os pré-requisitos para algumas opções incluindo um Dockerfile para criar facilmente o ambiente de pré-requisitos.
Além disso:
- Verifique as permissões do usuário. Tenha certeza de que sua conta de usuário tenha permissões suficientes para criar e gerenciar todos os recursos neste tutorial. Veja a lista de:
Endereço IP e Layout de Subnet
Nesta etapa você irá provisionar os recursos da rede VPC. Planee cuidadosamente o projetando um plano de endereçamento para um VPC e use blocos CIDR não sobrepostos.
É tentador dividir o espaço CIDR primeiro pela VPC mas isso complica o roteamento. Em vez disso pense em uma zona de disponibilidade como um único bloco CIDR e cada VPC como consumir uma fatia dele.
Este diagrama mostra apenas a zona 1 em mais detalhes. Os tamanhos subnet e o layout são idênticos nas outras zonas:
Acima a empresa está à esquerda e a IBM Cloud à direita. No IBM Cloud para simplictiy uma única zona é representada para o VPC de trânsito e o Spoke 0. Percebem que os blocos CIDR não se sobrepõem e VPCs todos consomem um bloco CIDR em cada zona:
- O CIDR no local é 192.168.0.0/16.
- As zonas nesta região de multi-zona são 10.*.0.0/16. O segundo dígito: 1, 2, 3 é o número da zona (mostrado para Dallas/us-sul):
- 10.10.1.0.0/16, zona 1, Dallas 1, us-south-1.
- 10.10.2.0.0/16, zona 2, Dallas 2, us-south-2.
- 10.10.3.0.0/16, zona 3, Dallas 3, us-south-3.
- O VPC de trânsito consome CIDRs 10.*.15.0/24:
- 10.1.15.0/24, zona 1.
- 10.2.15.0/24, zona 2.
- 10.3.15.0/24, zona 3
- O spoke 0 consome 10.*.0.0/24 ou CIDRs:
- 10.1.0.0/24, zona 1.
- 10.2.0.0/24, zona 2.
- 10.3.0.0/24, zona 3.
- Os CIDRs sub-net dividem ainda mais o /24 em /26.
As sub-redes no trânsito e spoke são para os diferentes tipos de recursos:
- worker-network acessível recursos de cálculo VPC instâncias, balanceadores de carga, Red Hat OpenShift, etc. As instâncias do VPC são demonstradas neste tutorial.
- dns- DNS Services aparelhos de localização usados na parte dois.
- vpe- VPE for VPC usado na parte dois.
- Instâncias do VPC fw-firewall-router (somente em trânsito).
Provimento de recursos de rede VPC
-
A companheira GitHub Repositório tem os arquivos de origem para implementar a arquitetura. Em um shell de desktop clone o repositório:
git clone https://github.com/IBM-Cloud/vpc-transit cd vpc-transit
-
O diretório config_tf contém variáveis de configuração que você é necessário para configurar.
cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
-
Edite config_tf/terraform.tfvars e use os comentários nesse arquivo como seu guia.
-
Uma vez que é importante que cada camada esteja instalada na ordem correta e algumas etapas neste tutorial instalará várias camadas um comando shell ./apply.sh é fornecido. A seguir exibirá ajuda:
./apply.sh
-
Você poderia aplicar todas as camadas configuradas executando
./apply.sh : :
. Os dois pontos são abreviados para primeiro (ou config_tf) e último (power_tf). O -p imprime as camadas:./apply.sh -p : :
Será algo parecido com:
directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
-
Se você ainda não tiver uma, obtenha uma chave de API da plataforma e exporte a chave de API para uso pelo Terraform:
export IBMCLOUD_API_KEY=YourAPIKEy
-
Nesta primeira etapa, aplique-se em config_tf, enterprise_tf, transit_tf, porta-voz e transit_spoke_tgw_tf:
./apply.sh : transit_spoke_tgw_tf
Os VPCs e as sub-redes foram criados O VPC de trânsito e os VPCs spoke foram conectados por meio de um Transit Gatewayprovisionado. Abra o Virtual Private Clouds no navegador.. Abra o VPC de trânsito e observe os blocos CIDR para prefixos de endereço e sub-redes. Examine os VPCs corporativos e spoke também. Abra Transit Gateway e clique no gateway de trânsito para ver a conexão entre as VPCs de trânsito e spoke.
Criar instâncias de teste
As Instâncias do Servidor Virtual do VPC, VSIs, são provisionadas para testar a conectividade de rede. Uma instância de teste será adicionada a cada uma das sub-redes do trabalhador (um por zona) na empresa, no trânsito e em cada uma das spokes. Se a configuração padrão de 3 zonas e 2 spokes for usada então 12 instâncias serão provisionadas.
-
Criar as instâncias de teste
./apply.sh test_instances_tf
Pode ser esclarecedor para explorar os recursos criados em cada etapa no console IBM Cloud. Opcionalmente abra o Virtual Private Clouds. No clique esquerdo sobre as instâncias do servidor virtual e observe as instâncias que foram criadas.
Teste
Este tutorial irá adicionar caminhos de comunicação uma camada de cada vez. Uma suíte de testes pytest será usada para testar exaustivamente caminhos de comunicação. Até o final do tutorial todos os testes devem passar.
Não é necessário que o leitor use pytest para verificar os resultados. Siga junto no tutorial, aplique as camadas e confie nos resultados descritos no tutorial. O leitor ainda pode explorar os recursos de VPC como VSIs, sub-redes e tabelas de rotas após serem criados.
Cada teste de pytest irá SSH para uma das instâncias e executará um tipo de teste de conectividade, como executar um comando curl
para uma das outras instâncias. O ambiente SSH padrão é usado para fazer login nas
instâncias. Se você ver resultados de teste inesperados tente a seção resolução de problemas pytest.
-
Execute os testes da zona 1
curl
na suíte usando a bandeira -m (marcadores). Escolha os testes marcados com curl, lz1 (zona esquerda 1) e rz1 (zona direita 1).Seus resultados esperados são: a Conectividade dentro de uma VPC, como corporativa <-> corporativa será APROVADA A conectividade entre o trânsito e os spokes será Passada A VPC cruzada de enterprise-> transit ou spokes será FAILED.
pytest -m "curl and lz1 and rz1"
Abaixo está um exemplo de saída:
root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1" ===================================================== test session starts ====================================================== platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python cachedir: .pytest_cache rootdir: /usr/src/app configfile: pytest.ini testpaths: py plugins: xdist-3.5.0 collected 36 items / 20 deselected / 16 selected py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED [ 6%] py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED [ 12%] py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED [ 18%] py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED [ 25%] py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED [ 31%] py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED [ 37%] py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED [ 43%] py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED [ 50%] py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED [ 56%] py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED [ 62%] py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED [ 68%] py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED [ 75%] py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED [ 81%] py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED [ 87%] py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED [ 93%] py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED [100%] =================================================== short test summary info ==================================================== FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
Uma mudança para a configuração da rede pode levar um par de corridas para que o sistema de rede VPC subjacente se torne consistente. Se você não ver os resultados esperados inicialmente esteja preparado para executar o teste novamente algumas vezes.
O stand r- e l- para o r ight e l eft. A parte média do nome identifica empresa, trânsito, spoke0, spoke1, ... O z1, z2, ... identificar a zona. O teste irá SSH para a instância da esquerda. Na instância da esquerda a conectividade com a instância certa é tentada. O test_curl executa uma conectividade de curl na instância da esquerda para a instância certa.
Em resumo, o teste test_curl[l-enterprise-z1 -> r-transit-z1]
irá:
- SSH a uma instância de teste na zona corporativa 1.
- Executar um curl para a zona de trânsito 1.
- Assert a string de retorno contém o ID da zona de trânsito 1 para marcar passe ou falha.
O README.md na companheira GitHub Repositório tem mais detalhes e o código fonte.
Conectar Enterprise ao Transit via Direct Link e Transit Gateway
Provisionar um IBM Cloud® Direct Link usando Transit Gateway.
IBM Cloud® Direct Link é um caminho de dados seguro de alta velocidade para conexão de uma empresa ao IBM Cloud. Neste tutorial Transit Gateway é usado para distribuição. O uso de Transit Gateway é opcional para uma conexão no local.
A empresa neste tutorial é simulada com outro VPCs. Conectando esta empresa simulada (na verdade outro VPC) via o Transit Gateway irá garantir uma experiência muito próxima do que você experimentaria com um Direct Link.
-
Aplique a camada enterprise_link_tf:
./apply.sh enterprise_link_tf
-
Execute os testes de curl da zona 1 na suíte minha usando a bandeira -m (marcadores). Escolha os testes marcados com curl, lz1 (zona esquerda 1) e rz1 (zona direita 1).
Os seus resultados esperados são: Conectividade dentro de um VPC, trânsito <-> falou (s), empresa <-> trânsito, falou (s) <-> falou (s) pass mas enterprise <-> falou (s) fail (s).
pytest -m "curl and lz1 and rz1"
Conectar Enterprise ao Spoke (s) via Transit NFV Firewall-Router
O incentivo para um VPC de trânsito para empreendimento <-> tráfego de nuvem é tipicamente rotear, inspecionar, monitorar e registrar o tráfego de rede. Nesta etapa um dispositivo de roteador de firewall será instalado em cada zona do VPC de trânsito.
Roteador NFV
Provisionar os aparelhos de roteador de firewall. Uma tabela de rotas de ingresso para Transit Gateway foi incluída no VPC de trânsito conforme indicado pelas linhas pontilhadas. Uma sub-rede foi criada em cada uma das zonas do VPC de trânsito para realizar o roteador de firewall.
A conectividade da empresa para um falado é obtida por meio de uma Virtualização de Function de Rede, NFV, instância de roteador de firewall no VPC de trânsito. Na produção você pode escolher uma a partir do catálogo ou trazer a sua. Esta demonstração usará uma imagem de estoque Ubuntu com iptables kernel configurados para encaminharão todos os pacotes da fonte para o destino. Neste tutorial, nenhuma inspeção de firewall é executada
A configuração Terraform configurará a instância do firewall-roteador com allow_ip_spoofing. Você deve ativar verificações de spoofing IP antes de continuar.
-
Aplique a camada firewall_tf:
./apply.sh firewall_tf
-
Execute a suíte de testes.
Os seus resultados esperados são: Conectividade dentro de um VPC, empresa-> trânsito, empresa <-> falou mesmo passagem de zona. Mas todo o trânsito-> falou, todo o trânsito-> empresa falha devido a problemas de roteamento assimétricos.
pytest -m "curl and lz1 and (rz1 or rz2)"
Parte dois deste tutorial roteará todo o tráfego de VPC <-> diferente por meio do roteador de firewall e resolverá esses problemas. Mas primeiro é importante aprender o que está acontecendo.
Roteamento de ingresso
O tráfego atinge o dispositivo de roteador de firewall através de tabelas de roteamento.
- Visite os VPCs no console IBM Cloud.
- Selecione o VPC de trânsito.
- Clique em Gerenciar tabelas de roteamento.
- Clique na tabela de roteamento tgw-ingress.
A zona é determinada pelo Transit Gateway que examinará o endereço IP de destino de cada pacote e o roteará para a zona correspondente com base nas rotas aprendidas. O Transit Gateway aprende as rotas anunciadas nas conexões. Cada VPC anunciará seus prefixos de endereço que permitem que as VPCs se comuniquem entre si após se conectarem a um Transit Gateway. Mas como os spokes aprenderiam as rotas para a empresa? Como a empresa aprende as rotas para os spokes? A empresa e os spokes não são conectados ao mesmo Transit Gateway.
Ambos os conjuntos de rotas estão na tabela de roteamento de entrada do trânsito (mostrada para Dallas/us-south). E a sinalização Anunciar é configurada como ON para passar essas rotas para todos os Transit Gateways.
Zona | Destino | Próximo salto | Anúncio |
---|---|---|---|
Dallas 1 | 10.1.0.0/16 | 10.1.15.197 | On |
Dallas 2 | 10.2.0.0/16 | 10.2.15.197 | On |
Dallas 3 | 10.3.0.0/16 | 10.3.15.197 | On |
Dallas 1 | 192.168.0.0/16 | 10.1.15.197 | On |
Dallas 2 | 192.168.0.0/16 | 10.2.15.197 | On |
Dallas 3 | 192.168.0.0/16 | 10.3.15.197 | On |
O next_hop identifica o roteador de firewall. Na tabela acima, 10.1.15.196 zona Dallas 1 e 10.2.15.196 zona Dallas 2, etc. Você pode observar isso usando o console IBM Cloud.
- Abra instâncias do servidor virtual para VPC para encontrar as instâncias fw e IP Reservado associado (clique no cabeçalho da coluna Nome para classificar).
- Combine-os com a tabela acima para verificar a próxima relação de salto.
Removendo o firewall para o tráfego de destino de trânsito
O IBM Cloud VPC usa o roteamento baseado em estado padrão de mercado para rastreamento de conexão TCP segura. Ele requer que as conexões TCP utilizem o mesmo caminho na forma de como sair. Uma exceção é o Direct Server Return usado por roteadores como Network Load Balancers. Ele permite que as conexões recebidas da empresa passem pelo firewall para a instância de teste de trânsito e depois retornam diretamente para o originador.
Isso não ajuda com o tráfego originado na instância de teste de trânsito que passa pelo Transit Gateway então de volta através de roteamento de ingresso para o roteador de firewall. Esta conexão fica presa no firewall-roteador (3) e não será encaminhada de volta para o trabalhador como mostrado em vermelho abaixo. Trânsito de tráfego-> empresa e trânsito-> falou estão falhando.
Uma solução possível é deixar de enviar tráfego destinado ao VPC de trânsito para o roteador de firewall. As amplas rotas de ingresso para o trânsito estão atualmente roteando o tráfego para o roteador de firewall. Rotas mais específicas podem ser adicionadas para o trânsito em Delegado para o comportamento padrão-enviar diretamente para o destino pretendido em vez do roteador de firewall.
Este diagrama mostra o fluxo de tráfego desejado para esta etapa. Apenas a empresa <-> falou está passando pelo firewall:
- empresa <-> trânsito
- falou <-> trânsito
- falou <-> falou
- empresa <--transit firewall-router--> spoke
Esse roteamento pode ser alcançado adicionando-se essas rotas para a tabela de rotas de ingresso de trânsito:
Zona | Destino | Próximo salto |
---|---|---|
Dallas 1 | 10.1.15.0/24 | Delegate |
Dallas 2 | 10.2.15.0/24 | Delegate |
Dallas 3 | 10.3.15.0/24 | Delegate |
-
Para observar o valor atual da tabela de rotas de ingresso visite as tabelas de roteamento para VPC no console IBM Cloud. Selecione o VPC de trânsito da queda para baixo e, em seguida, selecione a tabela de roteamento tgw-ingress.
-
Faça as alterações na tabela de roteamento, aplicando a camada transit_ingresso:
./apply.sh transit_ingress_tf
-
Atualize o display do navegador da tabela de roteamento para observar as novas rotas.
-
Execute a suíte de testes.
Os resultados esperados são: Todos os testes resultarão em APROVADO.
pytest -m "curl and lz1 and (rz1 or rz2)"
É interessante observar como o tráfego entre zonas flui entre a empresa e os spokes na configuração. A empresa envia o tráfego para a zona correta e por meio do roteador de firewall por meio do roteamento de ingresso na VPC de trânsito O Transit Gateway aprendeu que 192.168.0.0/16 está disponível em todas as zonas e roteará para o VPC de trânsito usando as rotas corporativas anunciadas na mesma zona que o spoke, conforme mostrado no diagrama abaixo:
Resumo de Ro
O roteamento básico está completo:
- empresa <-> trânsito
- trânsito <-> falou (s)
- empresa < -- (firewall de trânsito-roteador)--> falou
Notas de Produção e Conclusões
A arquitetura de referência do VPC para o IBM Cloud para Serviços Financeiros tem muito mais detalhes em garantir cargas de trabalho no IBM Cloud.
Algumas mudanças óbvias para fazer:
- Os blocos CIDR foram escolhidos para clareza e facilidade de explicação. As Zonas de Disponibilidade na Região da Zona Multi poderiam ser 10.0.0.0/10, 10.64.0.0/10, 10.128.0.0/10 para conservar o espaço de endereço. O espaço de endereço para nós do Trabalhador poderia ser expandido em detrimento do firewall, do DNS e do espaço VPE.
- Os Grupos de Segurança para cada uma das interfaces de rede para VSIs do trabalhador, Gateways de Terminal Privado Virtual, Locais DNS e firewalls devem ser cuidadosamente considerados.
- Listas De Controle De Acesso À Rede para cada sub-rede devem ser cuidadosamente consideradas.
Os IPs flutuantes foram anexados a todas as instâncias de teste para suportar testes de conectividade via SSH. Isso não é necessário ou desejável na produção.
Implementar restrições baseadas em contexto regras para controlar ainda mais o acesso a todos os recursos.
Neste tutorial você criou um VPC de hub e um conjunto de VPCs falados. Você identificou as zonas de Disponibilidade Necessárias para a arquitetura e criou um conjunto de sub-redes nos VPCs. Você criou um roteador de firewall de VPC de trânsito em cada zona para encaminhar o tráfego As instâncias de teste foram usadas para verificar a conectividade e identificar problemas potenciais. As rotas da tabela de roteamento foram usadas para identificar os caminhos de tráfego necessários.
Remover recursos
Não é necessário remover os recursos se você planeja continuar com a segunda parte deste tutorial
Execute terraform destroy
em todos os diretórios em ordem inversa usando o comando ./apply.sh
:
./apply.sh -d : spokes_egress_tf
Expandir o tutorial
Você é encorajado a continuar na parte dois deste tutorial em que todo o tráfego de VPC cruzado é roteado através do firewall-roteador, VPE for VPC e DNS são examinados.
A sua arquitetura provavelmente será diferente da apresentada mas provavelmente será construída a partir dos componentes fundamentais discutidos aqui. Ideias para expandir este tutorial:
- Integre o acesso à Internet pública recebida usando IBM Cloud® Internet Services.
- Adicionar captura de log de fluxo no trânsito.
- Coloque cada um dos spokes em uma conta separada em uma empresa.
- Force alguns dos falaram ao tráfego falado por meio do firewall e alguns não através do firewall.
- Substitua o VSIs do trabalhador por Red Hat OpenShift on IBM Cloud e balanceador de carga VPC.
- Force todo o tráfego ligado através do firewall no VPC de trânsito e através de gateways públicos.