Como usar a instância de próximo salto (sem tag e com tag), o endereço de próximo salto e o gateway de próximo salto das rotas estáticas IPv6

Sobre este codelab
schedule60 minutos
subjectÚltimo 21 de março de 2025 atualizado
account_circleEscrito por Ghaleb Al-Habian

As rotas personalizadas estáticas influenciam o comportamento de roteamento padrão em uma VPC. As rotas personalizadas IPv6 agora oferecem suporte a novos atributos de próximo salto: next-hop-gateway, next-hop-instance e next-hop-address. Este codelab descreve como usar rotas personalizadas IPv6 com essas novas opções de próximo salto usando duas VPCs conectadas por uma instância de VM multi-NIC. Você também vai demonstrar como misturar o endereço ULA e o endereço GUA e fornecer acessibilidade à VPC ULA para a Internet pública usando o novo recurso de rota personalizada.

  • Como criar uma rota IPv6 personalizada com um próximo salto next-hop-ilb especificando o nome do ILB
  • Como criar uma rota personalizada IPv6 com um próximo salto next-hop-ilb especificando o endereço IPv6 do ILB

O que é necessário

  • Projeto do Google Cloud

2. Antes de começar

Atualizar o projeto para oferecer suporte ao codelab

Este codelab usa $variables para ajudar na implementação da configuração do gcloud no Cloud Shell.

No Cloud Shell, faça o seguinte:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
export projectname=$(gcloud config list --format="value(core.project)")

Arquitetura geral do laboratório

5fc56288b4f8ae05.png

Para demonstrar os dois tipos de próximos saltos de rota personalizados, você vai criar duas VPCs: uma VPC de cliente e outra de servidor que usam o endereçamento ULA.

Para que a VPC do cliente acesse o servidor, você vai usar uma rota personalizada com next-hop-ilb apontando para um ILB (usando o nome do ILB) na frente de um grupo de instâncias de gateway com vários NICs que estão entre dois ILBs. Para fornecer o roteamento de volta à instância do cliente (após excluir a rota padrão ::/0), use uma rota personalizada com next-hop-ilb (usando o endereço do ILB) apontando para o ILB.

3. Configuração da VPC do cliente

Criar a VPC do cliente

No Cloud Shell, faça o seguinte:

gcloud compute networks create client-vpc \
    --project=$projectname \
    --subnet-mode=custom --mtu=1500 \
    --bgp-routing-mode=regional \
    --enable-ula-internal-ipv6

Criar a sub-rede do cliente

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create client-subnet  \
    --network=client-vpc \
    --project=$projectname \
    --range=192.168.1.0/24 \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=internal \
    --region=us-central1

Registre a sub-rede IPv6 atribuída em uma variável de ambiente usando este comando

export client_subnet=$(gcloud compute networks subnets \
    describe client-subnet \
    --project $projectname \
    --format="value(internalIpv6Prefix)" \
    --region us-central1)

Iniciar a instância do cliente

No Cloud Shell, faça o seguinte:

gcloud compute instances create client-instance \
    --subnet client-subnet \
    --stack-type IPV4_IPV6 \
    --zone us-central1-a \
    --project=$projectname

Adicionar uma regra de firewall para o tráfego de VPC do cliente

No Cloud Shell, faça o seguinte:

gcloud compute firewall-rules create allow-gateway-client \
    --direction=INGRESS --priority=1000 \
    --network=client-vpc --action=ALLOW \
    --rules=tcp --source-ranges=$client_subnet \
    --project=$projectname 

Adicionar uma regra de firewall para permitir o IAP na instância do cliente

No Cloud Shell, faça o seguinte:

gcloud compute firewall-rules create allow-iap-client \
    --direction=INGRESS --priority=1000 \
    --network=client-vpc --action=ALLOW \
    --rules=tcp:22 --source-ranges=35.235.240.0/20 \
    --project=$projectname 

Confirmar o acesso SSH à instância do cliente

No Cloud Shell, faça login na instância do cliente:

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Se for bem-sucedido, uma janela de terminal vai aparecer na instância do cliente. Saia da sessão SSH para continuar com o codelab.

4. Configuração da VPC do servidor

Criar a VPC do servidor

No Cloud Shell, faça o seguinte:

gcloud compute networks create server-vpc \
    --project=$projectname \
    --subnet-mode=custom --mtu=1500 \
    --bgp-routing-mode=regional \
    --enable-ula-internal-ipv6

Criar as sub-redes do servidor

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets create server-subnet \
    --network=server-vpc \
    --project=$projectname \
    --range=192.168.0.0/24 \
    --stack-type=IPV4_IPV6 \
    --ipv6-access-type=internal \
    --region=us-central1

Registre a sub-rede atribuída em uma variável de ambiente usando este comando

export server_subnet=$(gcloud compute networks subnets \
    describe server-subnet \
    --project $projectname \
    --format="value(internalIpv6Prefix)" \
    --region us-central1)

Iniciar a VM do servidor

No Cloud Shell, faça o seguinte:

gcloud compute instances create server-instance \
    --subnet server-subnet \
    --stack-type IPV4_IPV6 \
    --zone us-central1-a \
    --project=$projectname

Adicionar uma regra de firewall para permitir o acesso ao servidor pelo cliente

No Cloud Shell, faça o seguinte:

gcloud compute firewall-rules create allow-client-server \
    --direction=INGRESS --priority=1000 \
    --network=server-vpc --action=ALLOW \
    --rules=tcp --source-ranges=$client_subnet \
    --project=$projectname 

Adicionar regra de firewall para permitir o IAP

No Cloud Shell, faça o seguinte:

gcloud compute firewall-rules create allow-iap-server \
    --direction=INGRESS --priority=1000 \
    --network=server-vpc --action=ALLOW \
    --rules=tcp:22 \
    --source-ranges=35.235.240.0/20 \
    --project=$projectname 

Instalar o Apache na instância do servidor ULA

No Cloud Shell, faça login na instância do cliente:

gcloud compute ssh server-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

No shell da VM do servidor, execute o seguinte comando:

sudo apt update && sudo apt -y install apache2

Verificar se o Apache está em execução

sudo systemctl status apache2

Substituir a página da Web padrão

echo '<!doctype html><html><body><h1>Hello World! From Server Instance!</h1></body></html>' | sudo tee /var/www/html/index.html

Saia da sessão SSH para continuar com o codelab.

5. Criar instâncias de gateway

Criar um modelo de instância de gateway multi-NIC

No Cloud Shell, faça o seguinte:

gcloud compute instance-templates create gateway-instance-template \
    --project=$projectname \
    --instance-template-region=us-central1 \
    --region=us-central1 \
--network-interface=stack-type=IPV4_IPV6,subnet=client-subnet,no-address \
--network-interface=stack-type=IPV4_IPV6,subnet=server-subnet,no-address \
    --can-ip-forward \
    --metadata=startup-script='#! /bin/bash 
sudo sysctl -w net.ipv6.conf.ens4.accept_ra=2
sudo sysctl -w net.ipv6.conf.ens5.accept_ra=2
sudo sysctl -w net.ipv6.conf.ens4.accept_ra_defrtr=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1'

Criar um grupo de instâncias de gateway multi-NIC

No Cloud Shell, faça o seguinte:

gcloud compute instance-groups managed create gateway-instance-group \
    --project=$projectname \
    --base-instance-name=gateway-instance \
      --template=projects/$projectname/regions/us-central1/instanceTemplates/gateway-instance-template \
    --size=2 \
    --zone=us-central1-a

Verificar instâncias de gateway

Para garantir que o script de inicialização foi transmitido corretamente e que a tabela de roteamento v6 está correta. SSH para uma das instâncias do gateway

No Cloud Shell, liste as instâncias do gateway executando o seguinte:

gcloud compute instances list \
    --project=$projectname \
    --zones=us-central1-a \
    --filter name~gateway \
    --format 'csv(name)'

Anote um dos nomes de instância e use no próximo comando para fazer SSH na instância.

No Cloud Shell, faça login em uma das instâncias do gateway

gcloud compute ssh gateway-instance-<suffix> \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

No shell da VM do gateway, execute o seguinte comando para verificar o encaminhamento IPv6:

sudo sysctl net.ipv6.conf.all.forwarding

O comando precisa retornar o valor "1", indicando que o encaminhamento IPv6 está ativado.

Verifique a tabela de roteamento IPv6 na instância

ip -6 route show

Exemplo de saída mostrando as rotas de sub-rede ULA e GUA, com a rota padrão apontando para a interface GUA.

::1 dev lo proto kernel metric 256 pref medium
2600:1900:4000:7a7f:0:1:: dev ens4 proto kernel metric 256 expires 83903sec pref medium
2600:1900:4000:7a7f::/65 via fe80::4001:c0ff:fea8:101 dev ens4 proto ra metric 1024 expires 88sec pref medium
fd20:3df:8d5c::1:0:0 dev ens5 proto kernel metric 256 expires 83904sec pref medium
fd20:3df:8d5c::/64 via fe80::4001:c0ff:fea8:1 dev ens5 proto ra metric 1024 expires 84sec pref medium
fe80::/64 dev ens5 proto kernel metric 256 pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
default via fe80::4001:c0ff:fea8:101 dev ens4 proto ra metric 1024 expires 88sec pref medium

Saia da sessão SSH para continuar com o codelab.

6. Criar componentes do balanceador de carga

Antes de criar rotas nas duas VPCs, precisamos criar balanceadores de carga de passagem interna em ambos os lados das instâncias do gateway para encaminhar o tráfego.

Os balanceadores de carga criados neste codelab são compostos por:

  • Verificação de integridade: neste codelab, vamos criar verificações de integridade simples que usam a porta 22. As verificações de integridade não vão funcionar como implantadas. Isso envolve adicionar regras de firewall para permitir verificações de integridade e criar rotas especiais nas instâncias do gateway. Como este codelab se concentra no encaminhamento de IPv6, vamos usar o comportamento padrão de distribuição de tráfego dos balanceadores de carga de passagem interna quando todos os back-ends estiverem inativos, ou seja, encaminhando para todos os back-ends como último recurso.
  • Serviço de back-end: vamos usar o protocolo TCP para o serviço de back-end. No entanto, como os balanceadores de carga são criados para fins de roteamento, todos os protocolos são encaminhados, independentemente do protocolo do serviço de back-end.
  • Regra de encaminhamento: criamos uma regra de encaminhamento por VPC .
  • Endereço IPv6 interno: neste codelab, vamos permitir que a regra de encaminhamento aloque endereços IPv6 automaticamente da sub-rede

Criar verificação de integridade

No Cloud Shell, faça o seguinte:

gcloud compute health-checks create tcp tcp-hc-22 \
    --project=$projectname \
    --region=us-central1 \
    --port=22

Criar serviços de back-end

No Cloud Shell, faça o seguinte:

gcloud compute backend-services create bes-ilb-clientvpc \
    --project=$projectname \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --network=client-vpc \
    --region=us-central1 \
    --health-checks=tcp-hc-22 \
    --health-checks-region=us-central1

gcloud compute backend-services create bes-ilb-servervpc \
    --project=$projectname \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --network=server-vpc \
    --region=us-central1 \
    --health-checks=tcp-hc-22 \
    --health-checks-region=us-central1

Adicionar um grupo de instâncias ao serviço de back-end

No Cloud Shell, faça o seguinte:

gcloud compute backend-services add-backend bes-ilb-clientvpc \
    --project=$projectname \
    --region=us-central1 \
    --instance-group=gateway-instance-group \
    --instance-group-zone=us-central1-a
gcloud compute backend-services add-backend bes-ilb-servervpc \
    --project=$projectname \
    --region=us-central1 \
    --instance-group=gateway-instance-group \
    --instance-group-zone=us-central1-a

Criar regras de encaminhamento

No Cloud Shell, faça o seguinte:

gcloud compute forwarding-rules create fr-ilb-clientvpc \
    --project=$projectname \
    --region=us-central1 \
    --load-balancing-scheme=internal \
    --network=client-vpc \
    --subnet=client-subnet \
    --ip-protocol=TCP \
    --ip-version=IPV6 \
    --ports=ALL \
    --backend-service=bes-ilb-clientvpc \
    --backend-service-region=us-central1

gcloud compute forwarding-rules create fr-ilb-servervpc \
    --project=$projectname \
    --region=us-central1 \
    --load-balancing-scheme=internal \
    --network=server-vpc \
    --subnet=server-subnet \
    --ip-protocol=TCP \
    --ip-version=IPV6 \
    --ports=ALL \
    --backend-service=bes-ilb-servervpc \
    --backend-service-region=us-central1

Registre os endereços IPv6 das duas regras de encaminhamento emitindo os seguintes comandos no Cloud Shell:

export fraddress_client=$(gcloud compute forwarding-rules \
    describe fr-ilb-clientvpc \
    --project $projectname \
    --format="value(IPAddress)" \
    --region us-central1)

export fraddress_server=$(gcloud compute forwarding-rules \
    describe fr-ilb-servervpc \
    --project $projectname \
    --format="value(IPAddress)" \
    --region us-central1)

7. Criar e testar rotas para balanceadores de carga (usando o endereço do balanceador de carga)

Nesta seção, você vai adicionar rotas às VPCs do cliente e do servidor usando os endereços IPv6 dos balanceadores de carga como os próximos saltos.

Anote os endereços do servidor

No Cloud Shell, faça o seguinte:

gcloud compute instances list \
   --project $projectname \
   --zones us-central1-a \
   --filter="name~server-instance" \
--format='value[separator=","](name,networkInterfaces[0].ipv6Address)'

Isso vai mostrar os nomes das instâncias do servidor e os prefixos IPv6. Exemplo de saída

server-instance,fd20:3df:8d5c:0:0:0:0:0

Anote o endereço do servidor, porque você vai usá-lo mais tarde em comandos curl da instância do cliente. Infelizmente, as variáveis de ambiente não podem ser usadas com facilidade para armazenar esses dados, porque elas não são transferidas por sessões SSH.

Executar o comando curl do cliente para a instância do servidor ULA

Para conferir o comportamento antes de adicionar novas rotas. Execute um comando curl da instância do cliente para a instância do servidor 1.

No Cloud Shell, faça login na instância do cliente:

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Na instância do cliente, execute um curl usando o endereço ULA IPV6 da instância server1. O comando define um tempo limite curto de 5 segundos para evitar que o curl aguarde por muito tempo.

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Esse comando curl vai expirar porque a VPC do cliente ainda não tem uma rota para a VPC do servidor.

Vamos tentar corrigir isso. Saia da sessão SSH por enquanto.

Adicionar rota personalizada na VPC do cliente

Como a VPC do cliente não tem uma rota para o prefixo ULA. Vamos adicionar agora criando uma rota que aponte para o ILB do lado do cliente por endereço.

Observação: os balanceadores de carga de passagem interna IPv6 recebem endereços /96. É necessário remover a máscara /96 do endereço antes de transmiti-lo para o próximo comando. (abaixo, a substituição no local do bash é usada)

No Cloud Shell, faça o seguinte:

gcloud compute routes create client-to-server-route \
   --project=$projectname \
   --destination-range=$server_subnet \
   --network=client-vpc \
   --next-hop-ilb=${fraddress_client//\/96}

SSH de volta para a instância do cliente:

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Na instância do cliente, tente fazer o curl na instância do servidor novamente. O comando define um tempo limite curto de 5 segundos para evitar que o curl aguarde por muito tempo.

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Esse comando curl ainda tem um tempo limite porque a VPC do servidor ainda não tem uma rota de volta para a VPC do cliente pela instância do gateway.

Saia da sessão SSH para continuar com o codelab.

Adicionar uma rota personalizada na VPC do servidor

No Cloud Shell, faça o seguinte:

gcloud compute routes create server-to-client-route \
   --project=$projectname \
   --destination-range=$client_subnet \
   --network=server-vpc \
  --next-hop-ilb=${fraddress_server//\/96}

SSH de volta para a instância do cliente:

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Na instância do cliente, tente o curl para a instância do servidor mais uma vez.

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Esse comando curl agora mostra que você tem acessibilidade de ponta a ponta da instância do cliente para a instância do servidor ULA. Essa conectividade só é possível agora com o uso de rotas personalizadas IPv6 com next-hop-ilb como próximo salto.

Exemplo de saída

<user id>@client-instance:~$ curl -m 5.0 -g -6 'http://[fd20:3df:8d5c:0:0:0:0:0]:80/'
<!doctype html><html><body><h1>Hello World! From Server Instance!</h1></body></html>

Saia da sessão SSH para continuar com o codelab.

8. Criar e testar rotas para balanceadores de carga (usando o nome do balanceador de carga)

Como alternativa, o next-hop-ilb também pode fazer referência ao nome do balanceador de carga em vez do endereço IPv6. Nesta seção, vamos explicar o procedimento para fazer isso e testar se a conectividade ainda está estabelecida entre o cliente e o servidor.

Excluir rotas anteriores

Vamos restaurar o ambiente para antes de adicionar rotas personalizadas excluindo as rotas personalizadas que usam o nome da instância.

No Cloud Shell, faça o seguinte:

gcloud compute routes delete client-to-server-route  --quiet --project=$projectname
gcloud compute routes delete server-to-client-route  --quiet --project=$projectname

Executar o comando curl do cliente para a instância do servidor ULA

Para confirmar se as rotas anteriores foram excluídas, execute um comando curl da instância do cliente para a instância do servidor 1.

No Cloud Shell, faça login na instância do cliente:

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Na instância do cliente, execute um curl usando o endereço ULA IPV6 da instância server1. O comando define um tempo limite curto de 5 segundos para evitar que o curl aguarde por muito tempo.

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Esse comando curl vai expirar porque a VPC do cliente não tem mais uma rota para a VPC do servidor.

Adicionar rotas personalizadas em VPCs de cliente e servidor

Vamos adicionar novamente as rotas personalizadas nas VPCs de cliente e servidor, mas, em vez de usar o endereço do ILB, vamos usar o nome e a região do ILB no comando.

No Cloud Shell, faça o seguinte:

gcloud compute routes create client-to-server-route \
   --project=$projectname \
   --destination-range=$server_subnet \
   --network=client-vpc \
   --next-hop-ilb=fr-ilb-clientvpc \
   --next-hop-ilb-region=us-central1

gcloud compute routes create server-to-client-route \
   --project=$projectname \
   --destination-range=$client_subnet \
   --network=server-vpc \
   --next-hop-ilb=fr-ilb-servervpc \
   --next-hop-ilb-region=us-central1

SSH de volta para a instância do cliente:

gcloud compute ssh client-instance \
    --project=$projectname \
    --zone=us-central1-a \
    --tunnel-through-iap

Na instância do cliente, tente fazer o curl na instância do servidor novamente. O comando define um tempo limite curto de 5 segundos para evitar que o curl aguarde por muito tempo.

curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'

Esse comando curl agora mostra que você tem acessibilidade de ponta a ponta da instância do cliente para a instância do servidor ULA.

9. Limpar

Limpar rotas personalizadas

No Cloud Shell, faça o seguinte:

gcloud compute routes delete client-to-server-route  --quiet --project=$projectname
gcloud compute routes delete server-to-client-route  --quiet --project=$projectname

Limpar componentes de LB

No Cloud Shell, faça o seguinte:

gcloud compute forwarding-rules delete fr-ilb-clientvpc --region us-central1 --quiet --project=$projectname
gcloud compute forwarding-rules delete fr-ilb-servervpc --region us-central1 --quiet --project=$projectname

gcloud compute backend-services delete bes-ilb-clientvpc --region us-central1 --quiet --project=$projectname
gcloud compute backend-services delete bes-ilb-servervpc --region us-central1 --quiet --project=$projectname

gcloud compute health-checks delete tcp-hc-22 --region us-central1 --quiet --project=$projectname

Limpar instâncias e o modelo de instância

No Cloud Shell, faça o seguinte:

gcloud compute instances delete client-instance --zone us-central1-a --quiet --project=$projectname

gcloud compute instances delete server-instance --zone us-central1-a --quiet --project=$projectname


gcloud compute instance-groups managed delete gateway-instance-group --zone us-central1-a --quiet --project=$projectname

gcloud compute instance-templates delete gateway-instance-template --region us-central1 --quiet --project=$projectname

Limpar sub-redes

No Cloud Shell, faça o seguinte:

gcloud compute networks subnets delete client-subnet --region=us-central1 --quiet --project=$projectname

gcloud compute networks subnets delete server-subnet --region=us-central1 --quiet --project=$projectname

Limpar regras de firewall

No Cloud Shell, faça o seguinte:

gcloud compute firewall-rules delete allow-iap-client  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-iap-server  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-gateway-client  --quiet --project=$projectname
gcloud compute firewall-rules delete allow-client-server  --quiet --project=$projectname

Limpar VPCs

No Cloud Shell, faça o seguinte:

gcloud compute networks delete client-vpc --quiet --project=$projectname
gcloud compute networks delete server-vpc --quiet --project=$projectname

10. Parabéns

Você usou rotas IPv6 personalizadas estáticas com próximos saltos definidos como next-hop-ilb. Você também validou a comunicação IPv6 de ponta a ponta usando essas rotas.

A seguir

Confira alguns destes codelabs:

Leitura complementar e vídeos

Documentos de referência