Implantar uma rede hub e spoke usando um balanceador de carga como próximo salto

Neste tutorial, descrevemos como usar o peering de rede VPC para implantar uma arquitetura hub e spoke.

Este tutorial é destinado a engenheiros de rede em nuvem e profissionais de operações que querem implementar uma arquitetura hub-and-spoke no ambiente do Google Cloud usando dispositivos centralizados que consistem em máquinas virtuais do Compute Engine. Neste tutorial, você implantará essas máquinas virtuais como gateways NAT, mas poderá usar a mesma abordagem para outras funções, como firewalls de última geração. Para seguir este tutorial, é necessário ter familiaridade com as redes VPC e o Compute Engine.

Arquitetura

Nesta arquitetura, um conjunto de redes VPC spoke se comunica com a parte externa por meio de uma rede VPC hub em que o tráfego é roteado por um conjunto centralizado de dispositivos, neste caso gateways de conversão de endereços de rede (NAT). As rotas relevantes são exportadas da rede VPC hub para as redes VPC spoke. Os gateways NAT são configurados como back-ends de um balanceador de carga interno com uma nova rota padrão, que tem o balanceador de carga de rede de passagem interno do Cloud Load Balancing como o próximo salto.

É possível alcançar o mesmo tipo de distribuição de carga e alta disponibilidade usando várias rotas com roteamento de vários caminhos iguais (ECMP, na sigla em inglês). No entanto, o uso do balanceador de carga de rede de passagem interna tem as seguintes vantagens:

• O tráfego só é encaminhado para instâncias íntegras quando você depende de verificações de integridade. Com o ECMP, o tráfego é encaminhado para todas as instâncias ativas para as quais a rota aponta. Usar um balanceador de carga de rede de passagem interno elimina a possibilidade de rotas não utilizadas. Além disso, não é necessário limpar rotas quando as instâncias são encerradas ou reiniciadas.
• Há um failover potencialmente mais rápido porque é possível ajustar os timers de verificação de integridade. Se você usar grupos de instâncias gerenciadas e recuperação automática, ainda poderá personalizar os timers de verificação de integridade, mas eles são usados para recriar a instância, não para rotear o tráfego.

O Google também oferece o Cloud NAT como um serviço gerenciado, fornecendo alta disponibilidade sem gerenciamento e intervenção de usuários. No entanto, o Cloud NAT não é compatível com esse caso de uso porque a configuração NAT não é importada para uma rede com peering.

O diagrama a seguir mostra a topologia criada neste tutorial.

A topologia consiste em uma rede VPC hub e duas redes VPC spoke com peering com a rede VPC hub usando peering de rede VPC. A rede VPC hub tem duas instâncias de gateway NAT por trás de um balanceador de carga de rede de passagem interna. Uma rota padrão estática (0/0 NAT-GW-ILB) aponta para o balanceador de carga de rede de passagem interna como o próximo salto. Essa rota padrão estática é exportada pelo peering de rede VPC usando rotas personalizadas.

Objetivos

• Criar várias redes VPC e fazer peering com elas usando uma arquitetura "hub-and-spoke".
• Criar e configurar gateways NAT na rede VPC hub.
• Configure o balanceador de carga de rede de passagem interna como o próximo salto.
• Verificar a conectividade das redes VPC spoke com a Internet pública.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

• Compute Engine

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. Enable the Compute Engine API.

   Enable the API

5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

6. Make sure that billing is enabled for your Google Cloud project.

7. Enable the Compute Engine API.

   Enable the API

8. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Neste tutorial, todos os comandos serão executados no Cloud Shell.

Como configurar o ambiente

1. No Cloud Shell, verifique se você está trabalhando no projeto do Google Cloud que criou ou selecionou. Substitua o project-id pelo projeto do Google Cloud.

   gcloud config set project project-id
   
   export PROJECT_ID=`gcloud config list --format="value(core.project)"`
   

2. Defina a região e a zona de computação padrão.

   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-c
   export REGION=us-central1
   export ZONE=us-central1-c
   

   Neste tutorial, a região é us-central1 e a zona é us-central1-c.

Como criar redes e sub-redes VPC

1. No Cloud Shell, crie a rede VPC hub e a sub-rede:

   gcloud compute networks create hub-vpc --subnet-mode custom
   
   gcloud compute networks subnets create hub-subnet1 \
       --network hub-vpc --range 10.0.0.0/24
   

2. Crie as redes VPC spoke chamadas spoke1-vpc e spoke2-vpc com uma sub-rede cada:

   gcloud compute networks create spoke1-vpc --subnet-mode custom
   
   gcloud compute networks create spoke2-vpc --subnet-mode custom
   
   gcloud compute networks subnets create spoke1-subnet1 \
       --network spoke1-vpc --range 192.168.1.0/24
   
   gcloud compute networks subnets create spoke2-subnet1 \
       --network spoke2-vpc --range 192.168.2.0/24
   

3. Crie regras de firewall na rede VPC hub e nas redes VPC spoke. Elas permitem tráfego interno (TCP/80 e 443, UDP/53 e ICMP) dos intervalos RFC 1918 especificados:

   gcloud compute firewall-rules create hub-vpc-web-ping-dns \
       --network hub-vpc --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,192.168.1.0/24,192.168.2.0/24
   
   gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \
       --network spoke1-vpc --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,192.168.1.0/24
   
   gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \
       --network spoke2-vpc --allow tcp:80,tcp:443,icmp,udp:53 \
       --source-ranges 10.0.0.0/24,192.168.2.0/24
   

4. Crie regras de firewall na rede VPC hub e nas redes VPC spoke para permitir que o IAP para SSH acesse todas as máquinas virtuais:

   gcloud compute firewall-rules create hub-vpc-iap \
       --network hub-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   
   gcloud compute firewall-rules create spoke1-vpc-iap \
       --network spoke1-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   
   gcloud compute firewall-rules create spoke2-vpc-iap \
       --network spoke2-vpc --allow tcp:22 \
       --source-ranges 35.235.240.0/20
   

   Neste tutorial, usamos o Identity-Aware Proxy (IAP) para SSH. Para mais informações, consulte Como se conectar a instâncias que não têm endereços IP externos.

5. Crie uma regra de firewall para permitir verificações de integridade para grupos de instâncias com recuperação automática na rede VPC hub:

   gcloud compute firewall-rules create hub-vpc-health-checks \
       --network hub-vpc --allow tcp:443 --target-tags nat-gw \
       --source-ranges 130.211.0.0/22,35.191.0.0/16
   

Como criar as instâncias e rotas necessárias

1. No Cloud Shell, crie o modelo de instância para o gateway NAT que tem um script de inicialização que configura o gateway NAT:

   gcloud compute instance-templates create \
     hub-nat-gw-ilbnhop-template \
     --network hub-vpc \
     --subnet hub-subnet1 \
     --machine-type n1-standard-2 --can-ip-forward \
     --tags nat-gw --scopes default,compute-rw \
     --metadata startup-script='#! /bin/bash
   apt-get update
   # Enable IP forwarding:
   echo 1 > /proc/sys/net/ipv4/ip_forward
   echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf
   # Read VM network configuration:
   md_vm="http://metadata.google.internal/computeMetadata/v1/instance/"
   md_net="$md_vm/network-interfaces"
   nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google")"
   nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
   nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
   nic0_id="$(ip addr show | grep $nic0_addr | tail -c 5)"
   # Use a web server to pass the health check for this example.
   # In production, use a more complete test.
   sudo apt-get update
   sudo apt-get install apache2 -y
   sudo a2ensite default-ssl
   sudo a2enmod ssl
   echo "Example web page to pass health check" | \
   tee /var/www/html/index.html
   sudo systemctl restart apache2
   # Enable IP masquerading
   iptables -t nat -A POSTROUTING -o $nic0_id -j MASQUERADE'
   

   Neste tutorial, usamos n1-standard-2 como o tipo de instância, mas é possível usar qualquer outro número ou tamanho de gateway que quiser. Considere fatores como a largura de banda máxima de saída por VM.

2. Crie uma verificação de integridade HTTP.

   gcloud compute health-checks create http nat-gw-ilbnhop-health-check \
       --region us-central1 \
       --port 80
   

3. Crie um grupo de instâncias regionais com duas instâncias distribuídas em uma única região:

   gcloud compute instance-groups managed create \
       hub-nat-gw-ilbnhop-mig \
       --region us-central1 --size=2 \
       --template=hub-nat-gw-ilbnhop-template \
       --health-check nat-gw-ilbnhop-health-check \
       --initial-delay 15
   

   Neste tutorial, o atraso inicial é definido como 15 segundos. Em uma implantação de produção, personalize essa configuração de acordo com seus requisitos. Neste tutorial, não usamos políticas de escalonamento automático.

4. Crie um serviço de back-end e adicione o grupo de instâncias:

   gcloud compute backend-services create hub-nat-gw-ilbnhop-backend \
       --load-balancing-scheme=internal \
       --protocol=tcp \
       --health-checks=nat-gw-ilbnhop-health-check
   
   gcloud compute backend-services add-backend \
       hub-nat-gw-ilbnhop-backend \
       --instance-group=hub-nat-gw-ilbnhop-mig \
       --instance-group-region=us-central1
   

5. Crie uma regra de encaminhamento:

   gcloud compute forwarding-rules create \
       hub-nat-gw-ilbnhop \
       --load-balancing-scheme=internal \
       --network=hub-vpc \
       --subnet=hub-subnet1 \
       --address=10.0.0.10 \
       --ip-protocol=TCP \
       --ports=all \
       --backend-service=hub-nat-gw-ilbnhop-backend \
       --backend-service-region=us-central1 \
       --service-label=hub-nat-gw-ilbnhop
   

   Mesmo que a regra de encaminhamento seja definida apenas com TCP, quando você usa o balanceador de carga de rede de passagem interna como o próximo salto, a regra de encaminhamento encaminha todo o tráfego para todas as portas. nas VMs de back-end. O balanceador de carga de rede de passagem interna é um balanceador de carga regional.

6. Crie uma nova rota com a regra de encaminhamento como o próximo salto:

   gcloud compute routes create hub-nat-gw-ilbnhop \
       --network=hub-vpc \
       --destination-range=0.0.0.0/0 \
       --next-hop-ilb=hub-nat-gw-ilbnhop \
       --next-hop-ilb-region=us-central1 \
       --priority=800
   

   É possível especificar tags de rede para que a rota do próximo salto se aplique apenas às instâncias de cliente que foram configuradas com a tag, mas as tags não serão exportadas ou importadas por meio do peering de rede VPC.

7. Exclua a rota padrão da VPC hub:

   export hub_default_route=$(gcloud compute routes list \
       --format="value(name)" --filter="network:hub-vpc AND \
       nextHopGateway:default-internet-gateway" | head -n 1)
   gcloud compute routes delete $hub_default_route -q
   

8. Crie uma nova rota com tag para permitir o tráfego apenas dos gateways NAT:

   gcloud compute routes create hub-default-tagged \
       --network hub-vpc --destination-range 0.0.0.0/0 \
       --next-hop-gateway default-internet-gateway \
       --priority 700 --tags nat-gw
   

9. Exclua as rotas padrão para a Internet da VPC de cada spoke:

   export spoke1_default_route=$(gcloud compute routes list \
       --format="value(name)" --filter="network:spoke1-vpc AND \
       nextHopGateway:default-internet-gateway")
   
   gcloud compute routes delete $spoke1_default_route -q
   
   export spoke2_default_route=$(gcloud compute routes list \
       --format="value(name)" \
       --filter="network:spoke2-vpc AND nextHopGateway:default-internet-gateway")
   
   gcloud compute routes delete $spoke2_default_route -q
   

   Quando há um conflito entre rotas locais e importadas, as rotas locais sempre têm precedência. Para mais informações, consulte Ordem de roteamento.

10. Criar VMs cliente:

    gcloud compute instances create spoke1-client \
        --subnet=spoke1-subnet1 --no-address \
        --metadata startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'
    
    gcloud compute instances create spoke2-client \
        --subnet=spoke2-subnet1 --no-address \
        --metadata startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'
    

Como criar as conexões de peering de rede VPC

O peering de rede VPC é bidirecional e, portanto, precisa ser definido nas duas extremidades. Uma rede VPC pode fazer peering com várias redes VPC, mas limites se aplicam. Para alcançar a rota padrão por meio do peering de rede VPC, use o recurso de importação e exportação de rotas personalizadas pelo peering de rede VPC.

Para este tutorial, crie todas as redes VPC no mesmo projeto do Google Cloud.

1. No Cloud Shell, crie as conexões de peering de rede VPC da rede VPC hub para as redes VPC spoke com o flag de exportação de rota ativado:

   gcloud compute networks peerings create hub-to-spoke1 \
       --network hub-vpc --peer-network spoke1-vpc \
       --peer-project $PROJECT_ID \
       --export-custom-routes
   
   gcloud compute networks peerings create hub-to-spoke2 \
       --network hub-vpc --peer-network spoke2-vpc \
       --peer-project $PROJECT_ID \
       --export-custom-routes
   

2. Crie uma conexão de peering de rede VPC da rede VPC spoke1 para a rede VPC hub com o flag de importação de rota ativado:

   gcloud compute networks peerings create spoke1-to-hub \
       --network spoke1-vpc --peer-network hub-vpc \
       --peer-project $PROJECT_ID \
       --import-custom-routes
   

3. Crie uma conexão de peering de rede VPC da rede VPC spoke2 para a rede VPC hub com o flag de importação de rota ativado:

   gcloud compute networks peerings create spoke2-to-hub \
       --network spoke2-vpc --peer-network hub-vpc \
       --peer-project $PROJECT_ID \
       --import-custom-routes
   

Como verificar a propagação e a conectividade da rota

1. No Cloud Shell, verifique se as rotas estáticas foram criadas corretamente como parte dos scripts de inicialização:

   gcloud compute routes list --filter="network:hub-vpc"
   

   Verifique se as rotas hub-default-tagged e hub-nat-gw-ilbanhop estão presentes na saída:

   NAME                            NETWORK  DEST_RANGE      NEXT_HOP                  PRIORITY
   default-route-13a4b635b5eab48c  hub-vpc  10.0.0.0/24     hub-vpc                   1000
   hub-default-tagged              hub-vpc  0.0.0.0/0       default-internet-gateway  700
   hub-nat-gw-ilbanhop             hub-vpc  0.0.0.0/0       10.0.0.10                 800
   peering-route-3274f1257a9842a0  hub-vpc  192.168.2.0/24  hub-to-spoke2             1000
   peering-route-798c5777f13094bc  hub-vpc  192.168.1.0/24  hub-to-spoke1             1000
   

2. Verifique a tabela de roteamento spoke1-vpc para garantir que a rota padrão foi importada corretamente:

   gcloud compute routes list --filter="network:spoke1-vpc"
   

   Verifique se há uma rota começando com peering-route com 0.0.0.0/0 como o valor DEST_RANGE na saída:

   NAME                            NETWORK     DEST_RANGE      NEXT_HOP       PRIORITY
   default-route-75f6ea8f5fc54813  spoke1-vpc  192.168.1.0/24  spoke1-vpc     1000
   peering-route-6c7f130b860bfd39  spoke1-vpc  10.0.0.0/24     spoke1-to-hub  1000
   peering-route-9d44d362f98afbd8  spoke1-vpc  0.0.0.0/0       spoke1-to-hub  800
   

3. Conecte-se a um dos clientes usando SSH por meio do IAP:

   gcloud compute ssh spoke1-client --tunnel-through-iap
   

4. Verifique a conectividade testando o DNS público do Google por meio do gateway NAT:

   sudo hping3 -S -p 80 -c 3 dns.google
   

   Como o balanceador de carga interno é compatível com TCP e UDP, não é possível verificar a conexão de Internet usando um ping baseado em ICMP. Portanto, você precisa usar uma ferramenta como hping3.

   O resultado será assim:

   HPING dns.google (eth0 8.8.4.4): S set, 40 headers + 0 data bytes
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=4.6 ms
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=4.4 ms
   len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=4.3 ms
   
   --- dns.google hping statistic ---
   3 packets transmitted, 3 packets received, 0% packet loss
   round-trip min/avg/max = 4.3/4.4/4.6 ms
   

5. Verifique o endereço IP público que você usa para se comunicar com a Internet:

   curl ifconfig.co
   

   A resposta exibe um endereço IP público de uma das instâncias do gateway NAT. Se você executar o comando novamente, a saída poderá exibir um endereço IP público diferente porque as conexões serão distribuídas usando a afinidade da sessão de balanceamento de carga interno configurada (por padrão, IP do cliente, protocolo e porta).

   O peering de rede VPC não é transitivo, o que não garante conectividade entre as redes VPC spoke por meio do peering de rede VPC.

Considerações para um ambiente de produção

A configuração que você cria neste tutorial fornece dois gateways NAT em uma única região. No entanto, o balanceamento de carga ECMP não é perfeito, e um fluxo individual não é distribuído entre vários links, que é o que você quer ao usar dispositivos com estado, como firewalls de última geração (em inglês).

Para implantar essa configuração no ambiente de produção, considere os seguintes pontos:

• Essa configuração é melhor para links de saída temporários ou sem estado. Se o tamanho do pool de gateway NAT for alterado, as conexões TCP poderão ser reescalonadas, o que pode resultar na redefinição de uma conexão estabelecida.
• Os nós não são atualizados automaticamente. Se uma instalação padrão do Debian tiver uma vulnerabilidade de segurança, você precisará atualizar a imagem manualmente.
• Se você tiver VMs em várias regiões, precisará configurar gateways NAT em cada região.
• A largura de banda por gateway pode variar de acordo com o tipo de hardware. Considere fatores como a largura de banda máxima de saída por VM. Durante uma falha de gateway, o tráfego é distribuído para os gateways restantes. Como os fluxos em execução não são reprogramados, o tráfego não é reiniciado imediatamente quando o gateway fica on-line novamente. Portanto, permita uma sobrecarga suficiente ao dimensionar.
• Para ser alertado sobre resultados inesperados, use o Cloud Monitoring para monitorar os grupos de instâncias gerenciadas e o tráfego de rede.

Limpar

A maneira mais fácil de eliminar o faturamento é excluir o projeto do Google Cloud criado para o tutorial. A outra opção é excluir os recursos individuais.

Excluir o projeto

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Excluir recursos individuais

Se você quiser manter o projeto do Google Cloud, poderá excluir os recursos criados para este tutorial.

1. Exclua as conexões de peering de rede VPC:

   gcloud compute networks peerings delete spoke2-to-hub \
       --network spoke2-vpc -q
   
   gcloud compute networks peerings delete spoke1-to-hub \
       --network spoke1-vpc -q
   
   gcloud compute networks peerings delete hub-to-spoke1 \
       --network hub-vpc -q
   
   gcloud compute networks peerings delete hub-to-spoke2 \
       --network hub-vpc -q
   

2. Exclua as instâncias, os recursos do balanceador de carga, os modelos e as rotas:

   gcloud compute instances delete spoke1-client \
     --zone=us-central1-c -q
   
   gcloud compute instances delete spoke2-client \
     --zone=us-central1-c -q
   
   gcloud compute routes delete hub-nat-gw-ilbnhop -q
   
   gcloud compute forwarding-rules delete hub-nat-gw-ilbnhop -q
   
   gcloud compute backend-services delete -q hub-nat-gw-ilbnhop-backend -q
   
   gcloud compute instance-groups managed delete hub-nat-gw-ilbnhop-mig \
     --region us-central1 -q
   
   gcloud compute health-checks delete nat-gw-ilbnhop-health-check -q
   
   gcloud compute instance-templates delete hub-nat-gw-ilbnhop-template -q
   
   gcloud compute routes delete hub-default-tagged -q
   

3. Exclua as regras de firewall, as sub-redes e as redes VPC:

   gcloud compute firewall-rules delete spoke2-vpc-iap -q
   
   gcloud compute firewall-rules delete spoke2-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete spoke1-vpc-iap -q
   
   gcloud compute firewall-rules delete spoke1-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete hub-vpc-iap -q
   
   gcloud compute firewall-rules delete hub-vpc-web-ping-dns -q
   
   gcloud compute firewall-rules delete hub-vpc-health-checks -q
   
   gcloud compute networks subnets delete spoke1-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks subnets delete spoke2-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks subnets delete hub-subnet1 \
       --region us-central1 -q
   
   gcloud compute networks delete spoke1-vpc -q
   
   gcloud compute networks delete spoke2-vpc -q
   
   gcloud compute networks delete hub-vpc -q
   

A seguir

• Leia sobre Práticas recomendadas e arquiteturas de referência para o design da VPC.
• Analise a documentação de peering de rede VPC e balanceadores de carga de rede de passagem interna como próximos saltos.
• Leia sobre configurações especiais para instâncias de VM.