BYOIP na Google Cloud: traga os seus próprios endereços IPv4 para o Compute Engine

Prova o controlo do bloco com um ROA que indica o ASN da Google e um registo PTR com um nome que a Google lhe dá, depois recorta dele prefixos delegados e cria a partir destes endereços externos estáticos.

Este guia cobre o IPv4 na configuração que a Google recomenda, um prefixo regional (v2) na Premium Tier, através da gcloud CLI. Os endereços globais para load balancers globais usam a configuração v1, mais antiga, e o seu projeto tem primeiro de estar numa allowlist.

O que a Google Cloud aceita

Segundo a documentação da Google Cloud, no dia em que a consultámos:

• Tamanho. Um public advertised prefix de "/16 to /24" (tradução: «/16 a /24») na Premium Tier, a predefinida, ou de "/16 to /23" (tradução: «/16 a /23») na Standard Tier, que está em Preview. Pode dividi-lo até blocos /28.
• Registo. A Google indica instruções de ROA para cada registo regional, entre eles a ARIN, o RIPE NCC e a APNIC. Nada publica sobre o estatuto PA, PI ou legacy, nem sobre em nome de quem o bloco tem de estar.
• Quem origina. A Google, a partir de AS396982 na Premium Tier ou AS19527 na Standard Tier. Não documenta nenhuma opção para anunciar a partir do seu próprio ASN.
• Sem sobreposição. "Google does not support overlapping BYOIP route announcements" (tradução: «A Google Cloud não suporta anúncios de rotas BYOIP sobrepostos»): nem o prefixo nem nenhuma parte dele pode ser anunciado noutro lado enquanto a Google o anuncia.
• Regiões. Cada prefixo delegado serve uma região, ou o âmbito global. As páginas de BYOIP da Google não indicam nenhuma região excluída.
• Preço. "There are no charges for idle or in-use IP addresses." (tradução: «Não há cobranças por endereços IP inativos ou em uso.»)
• Prazo. "Approximately 2 weeks" (tradução: «cerca de 2 semanas») para um prefixo v2 após a validação, "approximately 4 weeks" (tradução: «cerca de 4 semanas») para os v1 e globais. O aprovisionamento "cannot be accelerated" (tradução: «não pode ser acelerado»).
• Recursos. A maioria dos que aceitam um endereço externo estático, mas não os nós e Pods do GKE nem o endereço externo de um gateway Cloud VPN. Os endereços não podem passar de um projeto para outro.

Antes de começar

Um ROA para o ASN da Google. Na Premium Tier, indica o prefixo, o seu comprimento exato e AS396982. Na Standard Tier, indica AS19527, num ROA para cada prefixo que vai aprovisionar, como a Google recomenda, ou num ROA com um comprimento máximo de /24 (RPKI e ROA).

Um segundo ROA para o seu próprio ASN. A Google recomenda um com os mesmos dados e o seu ASN como origem, para que as redes que fazem validação da origem das rotas não tratem o prefixo como inválido se algum dia o anunciar o próprio cliente.

Controlo do DNS inverso. A Google verifica a propriedade com um registo PTR, não com um token no registo. Escolhe um endereço não usado no prefixo, a Google devolve um nome (o seu segredo partilhado), e publica um registo PTR para esse endereço que aponta para esse nome no seu domínio.

Nada mais do registo. A Google não pede certificado, Letter of Authorization nem objeto route. Do lado dela, precisa da função Compute Public IP Admin (roles/compute.publicIpAdmin) no projeto.

Passo a passo

01Crie o public advertised prefix, indicando o endereço que vai usar para a validação DNS:

gcloud compute public-advertised-prefixes create pap-203-0-113-0-24 \
    --range=203.0.113.0/24 \
    --pdp-scope=REGIONAL \
    --dns-verification-ip=203.0.113.144

Para a Standard Tier, use gcloud beta e acrescente --network-tier=STANDARD.

02Publique o registo PTR. gcloud compute public-advertised-prefixes describe pap-203-0-113-0-24 --format='value(sharedSecret)' dá o nome. Se for 55kk88tt00 e o seu domínio for example.net, então dig +short -x 203.0.113.144 tem de devolver 55kk88tt00.example.net.

03Desencadeie a validação:

gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --status=PTR-CONFIGURED

O estado passa a VALIDATED, ou a REVERSE_DNS_LOOKUP_FAILED se a Google não encontrar o registo. O aprovisionamento está concluído quando describe com --format='value(status)' mostra PREFIX_CONFIGURATION_COMPLETE.

04Delegue um bloco a uma região. Isto pode correr enquanto espera:

gcloud compute public-delegated-prefixes create pdp-203-0-113-0-25 \
    --public-advertised-prefix=pap-203-0-113-0-24 \
    --range=203.0.113.0/25 \
    --region=europe-west4

05Crie endereços. Os prefixos delegados públicos regionais criados depois de 13 de dezembro de 2025 permitem endereços individuais:

gcloud compute addresses create web-1 --network-tier=PREMIUM \
    --ip-collection=pdp-203-0-113-0-25 --addresses=203.0.113.10 --region=europe-west4

Os prefixos mais antigos e os endereços globais aceitam blocos inteiros, através de delegated-sub-prefixes create --create-addresses. Associe os endereços a VM ou forwarding rules. Ainda não estão acessíveis.

06Anuncie. Garanta que nenhuma outra rede anuncia o bloco. Anuncie primeiro o prefixo delegado, que a Google transporta dentro da sua própria rede, e depois o advertised prefix, que vai para a Internet a partir de todos os pontos de presença da Google:

gcloud compute public-delegated-prefixes update pdp-203-0-113-0-25 --region=europe-west4 --announce-prefix
gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --announce-prefix

Do exterior, o validador do RIPEstat deve considerar o prefixo válido para AS396982: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=396982&prefix=203.0.113.0/24".

Erros que custam um dia

• Duas redes a anunciar. A sobreposição inclui uma rota mais específica: um /24 anunciado noutro lado dentro de um /23 que traz conta. A Google avisa de "unexpected routing and packet loss" (tradução: «encaminhamento inesperado e perda de pacotes»).
• O v1 anuncia-se sozinho. Um prefixo global (v1) é anunciado assim que o seu prefixo delegado é aprovisionado. A Google diz para não criar prefixos delegados enquanto alguém anunciar o bloco.
• Um ROA caducado. Se o ROA expirar e não o renovar no prazo de quatro semanas após a notificação de renovação da Google, a Google deixa de anunciar o prefixo.
• Nomes e regiões são fixos. Mudar o nome de um prefixo obriga a eliminá-lo e a criá-lo de novo, e mudar um prefixo delegado para outra região "can take approximately eight weeks" (tradução: «pode demorar cerca de oito semanas»). Escolha nomes como pap-203-0-113-0-24 e delegue apenas aquilo de que tem a certeza.
• Retirar o ROA cedo demais. Depois de eliminar um public advertised prefix, aguarde 14 dias antes de retirar o ROA para o ASN da Google.

Se alugar o bloco

A Google não publica nenhuma regra sobre em nome de quem o bloco está registado, e não pede nenhuma Letter of Authorization. As suas duas verificações, o ROA e o registo PTR, dependem ambas do titular de um bloco alugado. O titular cria o ROA para AS396982 ou AS19527, e o do seu ASN se o quiser. O titular cria também o registo PTR com o nome da Google, ou delega a zona inversa do bloco a servidores de nomes que o cliente controla. Combine que o ROA é renovado enquanto a Google anunciar o bloco, e mantido durante 14 dias depois de sair.

Onde entra a RTM Networks

Alugamos /24 e maiores a partir do nosso próprio espaço de endereçamento do RIPE NCC, e vendemos blocos nas regiões RIPE NCC, ARIN e APNIC. No espaço que lhe alugamos, criamos o ROA para o ASN da Google e o registo PTR com o nome da Google (alugar IPv4). Se precisar de menos de 256 endereços numa VM do Compute Engine, anunciamos nós próprios um bloco e entregamo-lo por GRE ou WireGuard, em qualquer tamanho até um único endereço (túneis GRE e WireGuard). Como soma a cobrança horária do IPv4 nas grandes clouds: o custo real do IPv4 na cloud. Outros fornecedores: guias BYOIP.