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:
Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.
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
- Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
Enable the Compute Engine API.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Verifique se a cobrança está ativada para o seu projeto do Google Cloud.
-
Enable the Compute Engine API.
-
In the Google Cloud console, 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
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)"`
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
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
Crie as redes VPC spoke chamadas
spoke1-vpc
espoke2-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
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
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.
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
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.Crie uma verificação de integridade HTTP.
gcloud compute health-checks create http nat-gw-ilbnhop-health-check \ --region us-central1 \ --port 80
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.
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
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.
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.
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
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
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.
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.
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
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
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
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
ehub-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
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
com0.0.0.0/0
como o valorDEST_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
Conecte-se a um dos clientes usando SSH por meio do IAP:
gcloud compute ssh spoke1-client --tunnel-through-iap
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
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
- No Console do Google Cloud, acesse a página Gerenciar recursos.
- Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
- Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.
Excluir recursos individuais
Se você quiser manter o projeto do Google Cloud, poderá excluir os recursos criados para este tutorial.
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
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
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.