Objetivos

• Entenda os conceitos por trás de um hub baseado em VPC e falou modelo para gerenciamento de todo o tráfego VPC para VPC.
• Entenda o ingresso VPC e o roteamento de egressos.
• Identificar e resolver opcionalmente problemas de roteamento assimétrico.
• Entenda o uso de um Balanceador de Carga de Rede para um roteador de firewall altamente disponível e escalável.
• Utilize o roteamento de serviço DNS e as regras de encaminhamento para construção de um sistema de resolução de nomes de som arquitetônico.

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,

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:
  • permissões necessárias para VPC.
  • permissões necessárias para criação de Transit Gateway.
  • permissões necessárias para verificações de spoofing IP.
  • permissões necessárias para gerenciar autorizações..

Resumo da Parte um

Em parte um deste tutorial planejamos cuidadosamente o espaço de endereço do trânsito e falamos VPCs. A arquitetura baseada na zona é mostrada abaixo:

Este diagrama mostra o fluxo de tráfego. Apenas a empresa <-> falou está passando pelo firewall:

Isso foi alcançado com Direct Link, Transit Gateway e roteamento VPC. Todas as zonas são configuradas similarmente e o diagrama abaixo mostra os detalhes da zona 1:

O CIDR 10.1.0.0/16 cobre o trânsito e os spokes e é passado por meio de Direct Link para a empresa como uma rota anunciada. Da mesma forma o CIDR 192.168.0.0/24 cobre a empresa e é passado através do Transit Gateway para os spokes como rota anunciada.

Rotas de egresso no tráfego de rotas de spokes para o roteador de firewall. Ingresso em rotas na empresa de rota de trânsito <-> falou o tráfego através do roteador de firewall.

Provisionar recursos de VPC iniciais roteirizando todo o tráfego intra VPC através do firewall-roteador

Muitas vezes uma empresa usa um VPC de trânsito para monitorar o tráfego com o roteador de firewall. Em parte uma única empresa <-> o tráfego falado estava fluindo através do firewall de trânsito-roteador. Esta seção trata-se de rotear todo o VPC para o tráfego VPC através de roteador de firewall.

Este diagrama mostra o fluxo de tráfego implementado nesta etapa:

Todo o tráfego entre VPCs fluirá através do firewall-roteador:

• empresa <-> falou.
• empresa <-> trânsito.
• trânsito <-> falou.
• falou <-> falou em VPC diferente.

O tráfego dentro de um VPC não fluirá através do firewall.

Se continuar a partir de parte uma faça nota especial da configuração no terraform.tfvars: all_firewall = true.

Roteamento da zona de correção

Como mencionado anteriormente para que um sistema seja resiliente através de falhas zonais é melhor eliminar o tráfego de cross zone. Se o suporte de zona cruzada for necessário rotas de egresso adicionais podem ser adicionadas. O problema para o tráfego de spoke 0 para spoke 1 é mostrado neste diagrama:

O caminho verde é um exemplo do roteamento do spoke 0 zona 2 10.2.0.4 para o spoke 1 zona 1 10.1.1.4. A rota de egresso correspondente é:

Zona	Destino	Próximo salto
Dallas10.0.0.0/810.2.15.196

Movimentação esquerda para direita o roteador de firewall na zona do meio, zona 2, do diagrama é selecionado. Na zona de caminho de retorno 1 é selecionado.

Para fixar isso algumas rotas mais específicas precisam ser adicionadas para forçar as zonas de número superior a traçar para a zona inferior número de firewalls quando um destino de número de zona inferior é especificado. Quando referenciar uma zona numerada igual ou superior continuar a rotear para o firewall na mesma zona.

Rotas na tabela de roteamento de saída padrão de cada spoke (mostrada para Dallas/us-south):

Zona	Destino	Próximo salto
Dallas10.1.0.0/1610.1.15.196
Dallas10.1.0.0/1610.1.15.196
Dallas10.2.0.0/1610.2.15.196

Essas rotas também vão corrigir um trânsito similar < --> falou problema de roteamento assimétrico de zona cruzada. Considere o trabalhador de trânsito 10.1.15.4-> trabalhador spoke 10.2.0.4. O tráfego do trabalhador de trânsito na zona 1 escolherá o roteador de firewall na zona 1 (mesma zona). Na viagem de retorno em vez de firewall-roteador na zona 2 (mesma zona) agora firewall-roteador na zona 1 será usado.

1. Aplique a camada all_firewall_asym:

   ./apply.sh all_firewall_asym_tf
   

2. Execute a suíte de testes.

   Seus resultados esperados são: todos os testes PASSADOS, execute-os em paralelo (-n 10):

   pytest -n 10 -m curl
   

Todo o tráfego entre VPCs agora é roteado por meio dos roteadores de firewall.

High Performance High Availability (HA) Firewall-Router

Para evitar que um firewall-roteador se torne o bottleneck de desempenho ou um único ponto de falha é possível adicionar um balanceador de Carga da Rede VPC para distribuir o tráfego para os roteadores zonais-roteadores para criar um Highly Disponível, HA, roteador de firewall. Verifique sua documentação do roteador de firewall para verificá-lo suporta esta arquitetura.

Este diagrama mostra uma única zona com um Network Load Balancer (NLB) configurado no modo de rota à frente de dois roteadores de firewall. Para ver isso construído é necessário alterar a configuração e se candidar novamente.

1. Altere essas duas variáveis em config_tf/terraform.tfvars:

   firewall_nlb                 = true
   number_of_firewalls_per_zone = 2
   

   Esta alteração resulta no endereço IP do firewall-roteador mudando da instância de roteador de firewall usada anteriormente para o endereço IP do NLB. A mudança de endereço IP precisa ser aplicada a uma série de rotas de tabela de rotas de VPC no trânsito e falou VPCs. É melhor aplicar todas as camadas aplicadas anteriormente:

2. Aplique todas as camadas através da camada all_firewall_asym_tf:

   ./apply.sh : all_firewall_asym_tf
   

Observe as alterações que foram feitas:

1. Abra o Carregar balanceadores para VPC.
2. Selecione o balanceador de carga na zona 1 (Dallas 1/us-south-1), que tem o sufixo fw-z1-s3.
3. Observe os IPs Privados.

Compare os IPs Privados com aqueles na tabela de rotas de ingresso de VPC de trânsito:

1. Abra o Virtual Private Clouds.
2. Selecione o VPC de trânsito.
3. Clique em Gerenciar tabelas de roteamento.
4. Clique na tabela de roteamento tgw-ingress. Percebem o endereço IP Next hop corresponde a um dos NLB Private IPs

Verificar resiliência:

1. Execute o falado 0 testes de zona 1:

   pytest -k r-spoke0-z1 -m curl
   

2. Abra as instâncias do servidor virtual para VPC
3. Pare o tráfego para a instância de firewall 0 especificando um grupo de segurança que não permitirá a porta de entrada 80. Localize a instância com o sufixo fw-z1-s3-0 e abra a visualização de detalhes:
   1. Role para baixo e acerte a edição do lápis ao lado da Interface de Rede
   2. Desmarque o x-fw-inall-outall
   3. Confira o x-fw-in22-outall
   4. Clique em Salvar
4. Execute o pytest novamente. Ele indicará falhas. Levará alguns minutos para que o NLB pare de rotear o tráfego para a instância não responsiva, nesse ponto todos os testes serão aprovados. Continue esperando e executando pytest até que todos os testes passem.

O firewall NLB não é mais necessário. Remova o firewall NLB:

1. Altere essas duas variáveis em config_tf/terraform.tfvars:

   firewall_nlb                 = false
   number_of_firewalls_per_zone = 1
   

2. Aplique todas as camadas através da camada all_firewall_asym_tf:

   ./apply.sh : all_firewall_asym_tf
   

Nota sobre NLB configurado no modo de roteamento

O modo de rota do NLB regravará entradas da tabela de rotas-sempre mantendo o endereço IP do dispositivo NLB ativo na tabela de rotas durante um failover. Mas isso é feito apenas para rotas no VPC de trânsito que contém o NLB O spoke possui rotas de egresso que foram inicializadas com um dos IPs do dispositivo NLB O próximo hop spoke não será atualizado no failover do dispositivo NLB!...

Será necessário manter uma rota de ingresso na VPC de trânsito que será regravada pelo NLB para refletir o dispositivo ativo.. A rota de saída spoke entregará pacotes para a zona correta da VPC de trânsito. O roteamento dentro da zona de VPC de trânsito localizará a regra de ingresso correspondente que conterá o dispositivo ativo

Abaixo está a tabela de rotas de ingresso da VPC de trânsito discutida anteriormente: O próximo hop será mantido atualizado com o dispositivo NLB ativo.. Observe que o Dallas 3 tem uma alteração gravada pelo serviço de modo de rota NLB para refletir o dispositivo ativo.

O NLB requer que uma autorização do IAM seja criada que permita que o NLB grave na VPC Essa autorização foi criada pelo script apply.sh. Consulte criando um balanceador de carga de rede com o modo de roteamento para obter mais detalhes sobre a configuração que foi executada pelo script

O conjunto NLB do modo de rota deve ser configurado com Tipo de persistência de sessão configurado como nulo.

DNS

O serviço IBM Cloud DNS Services é usado para converter nomes em endereços IP. Neste exemplo um serviço DNS é criado na nuvem. A zona de DNS do cloud.example.com é criada e a VPC de trânsito é incluída como uma rede permitida Registros DNS para as instâncias de nuvem são incluídos no cloud.example.com. Por exemplo, é criado um registro A para o trabalhador spoke 0 na zona 1 que teria o nome completo spoke0-z1-worker.cloud.example.com.

Revise sobre o compartilhamento DNS para gateways VPE. A VPC de trânsito é ativada como um hub de DNS Cada VPC spoke é configurado com a ligação de resolução de DNS para o hub de VPC de trânsito Isso definirá as configurações do DHCP do VPC spoke para que os servidores DNS sejam os resolvedores customizados do VPC de trânsito

./apply.sh dns_tf

pytest -n 10 -m dns

gateways de terminal privado virtual

O VPC permite o acesso privado aos Serviços IBM Cloud através do Virtual Private Endpoint (VPE) for VPC. Os gateways VPE permitem o controle de acesso à rede de baixa granularidade por meio de controles padrão do IBM Cloud VPC:

• Security Groups.
• Listas de Controle de Acesso à Rede VPC.
• Roteirização de tabelas e rotas.

Uma zona de DNS é criada para cada gateway VPC VPE. A zona DNS é incluída automaticamente no serviço DNS privado associado ao VPC. Cada VPC spoke tem uma configuração de DNS do bound para o VPC de trânsito Isso permite que a zona de DNS do VPE spoke seja compartilhada com o VPC de trânsito

1. Crie uma instância do IBM Cloud Databases for PostgreSQL e VPEs para o trânsito e cada uma das VPCs spoke, aplicando as camadas vpe_transit_tf e vpe_porta_tf:

   ./apply.sh vpe_transit_tf vpe_spokes_tf
   

2. Há um conjunto de testes vpe e vpedns que estão disponíveis no script pytest. O teste vpedns verificará se o nome DNS de uma instância do Databases for PostgreSQL está dentro do bloco CIDR privado da VPC de fechamento. O teste vpe executará um comando psql para acessar a instância Databases for PostgreSQL remotamente. Teste vpe e vpedns da fala 0 zona 1:

   • Resultados esperados todos os testes aprovados

   pytest -m 'vpe or vpedns' -k spoke0-z1
   

Todos os testes neste tutorial agora devem ser aprovados Há muito poucos. Execute-os em paralelo:

pytest -n 10

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.1.0.0/10, 10.64.0.0/10, 10.128.0.0/10 para conservar o espaço de endereço. Da mesma forma o espaço de endereço para nós do Trabalhador poderá ser expandido à custa do espaço de firewall, DNS e 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ê roteou todo o tráfego de VPC cruzado através de um firewall VPC de trânsito-roteador. Um serviço DNS foi criado para o hub de VPC de trânsito e cada VPC spoke foi ligado pelo DNS ao VPC de trânsito.

Remover recursos

Execute terraform destroy em todos os diretórios em ordem inversa usando o comando ./apply.sh :

./apply.sh -d : :

Expandir o tutorial

Sua arquitetura pode não ser a mesma que a 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 Flow Logs for VPC capturar 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.

Conteúdo relacionado

• IBM Cloud for Financial Services
• Como implementar cargas de trabalho isoladas em vários locais e regiões
• fim de frente público e backend privado em uma Nuvem Privada Virtual,
• Virtualização da Função de Rede
• Hub privado e conversou com VNF transparente e conversou-a-falou o tráfego