BYOIP su Google Cloud: porta i tuoi indirizzi IPv4 su Compute Engine

Dimostri il controllo del blocco con una ROA che indica l’ASN di Google e un record PTR che porta un nome che Google ti fornisce, poi ne ricavi prefissi delegati e da essi crei indirizzi esterni statici.

Questa guida tratta IPv4 nella configurazione che Google consiglia, un prefisso regionale (v2) sul Premium Tier, tramite la gcloud CLI. Gli indirizzi globali per i load balancer globali usano la vecchia configurazione v1, e il tuo progetto deve prima essere in una allowlist.

Cosa accetta Google Cloud

Dalla documentazione di Google Cloud, il giorno in cui l’abbiamo verificata:

• Dimensione. Un public advertised prefix da “/16 to /24” (traduzione: “da /16 a /24”) sul Premium Tier, quello predefinito, oppure da “/16 to /23” (traduzione: “da /16 a /23”) sullo Standard Tier, che è in Preview. Puoi dividerlo fino a blocchi /28.
• Registro. Google rimanda alle istruzioni per le ROA di ogni registro regionale, tra cui ARIN, il RIPE NCC e APNIC. Non pubblica nulla sullo stato PA, PI o legacy, né su a nome di chi deve essere il blocco.
• Chi lo origina. Google, da AS396982 sul Premium Tier o AS19527 sullo Standard Tier. Non documenta alcuna opzione per annunciare dal tuo ASN.
• Nessuna sovrapposizione. “Google does not support overlapping BYOIP route announcements” (traduzione: “Google Cloud non supporta annunci di route BYOIP sovrapposti”): né il prefisso né una sua parte possono essere annunciati altrove mentre Google lo annuncia.
• Regioni. Ogni prefisso delegato serve una regione, o l’ambito globale. Le pagine BYOIP di Google non indicano regioni escluse.
• Prezzo. “There are no charges for idle or in-use IP addresses.” (traduzione: “Non ci sono costi per gli indirizzi IP inattivi o in uso.”)
• Tempi. “Approximately 2 weeks” (traduzione: “circa 2 settimane”) per un prefisso v2 dopo la validazione, “approximately 4 weeks” (traduzione: “circa 4 settimane”) per quelli v1 e globali. Il provisioning “cannot be accelerated” (traduzione: “non può essere accelerato”).
• Risorse. La maggior parte di quelle che accettano un indirizzo esterno statico, ma non i nodi e i Pod di GKE né l’indirizzo esterno di un gateway Cloud VPN. Gli indirizzi non possono passare da un progetto all’altro.

Prima di iniziare

Una ROA per l’ASN di Google. Sul Premium Tier indica il prefisso, la sua lunghezza esatta e AS396982. Sullo Standard Tier indica AS19527, o in una ROA per ogni prefisso di cui farai il provisioning, come consiglia Google, o in una sola ROA con lunghezza massima /24 (RPKI e ROA).

Una seconda ROA per il tuo ASN. Google ne consiglia una con gli stessi dati e il tuo ASN come origin, così le reti che fanno route origin validation non trattano il prefisso come non valido se un giorno lo annunci tu.

Il controllo del DNS inverso. Google verifica la proprietà con un record PTR, non con un token nel record del registro. Scegli un indirizzo inutilizzato nel prefisso, Google restituisce un nome (il suo segreto condiviso), e pubblichi per quell’indirizzo un record PTR che punta a quel nome sotto il tuo dominio.

Nient’altro dal registro. Google non chiede certificati, Letter of Authorization né route object. Dal suo lato, ti serve il ruolo Compute Public IP Admin (roles/compute.publicIpAdmin) sul progetto.

Passo per passo

01Crea il public advertised prefix, indicando l’indirizzo che userai per la validazione 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

Per lo Standard Tier, usa gcloud beta e aggiungi --network-tier=STANDARD.

02Pubblica il record PTR. gcloud compute public-advertised-prefixes describe pap-203-0-113-0-24 --format='value(sharedSecret)' dà il nome. Se è 55kk88tt00 e il tuo dominio è example.net, allora dig +short -x 203.0.113.144 deve restituire 55kk88tt00.example.net.

03Avvia la validazione:

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

Lo stato diventa VALIDATED, oppure REVERSE_DNS_LOOKUP_FAILED se Google non trova il record. Il provisioning è terminato quando describe con --format='value(status)' mostra PREFIX_CONFIGURATION_COMPLETE.

04Delega un blocco a una regione. Si può fare mentre aspetti:

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

05Crea gli indirizzi. I prefissi delegati pubblici regionali creati dopo il 13 dicembre 2025 permettono singoli indirizzi:

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

I prefissi più vecchi e gli indirizzi globali accettano blocchi interi, tramite delegated-sub-prefixes create --create-addresses. Collega gli indirizzi a VM o forwarding rule. Non sono ancora raggiungibili.

06Annuncia. Assicurati che nessun’altra rete annunci il blocco. Annuncia prima il prefisso delegato, che Google porta all’interno della propria rete, poi il public advertised prefix, che va su internet da tutti i punti di presenza di 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

Dall’esterno, il validatore di RIPEstat dovrebbe dare il prefisso come valido per AS396982: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=396982&prefix=203.0.113.0/24".

Errori che costano una giornata

• Due reti che annunciano. La sovrapposizione include una route più specifica: un /24 annunciato altrove all’interno di un /23 che porti conta. Google avverte di “unexpected routing and packet loss” (traduzione: “routing inatteso e perdita di pacchetti”).
• La v1 si annuncia da sola. Un prefisso globale (v1) viene annunciato non appena viene fatto il provisioning del suo prefisso delegato. Google dice di non creare prefissi delegati finché qualcun altro annuncia il blocco.
• Una ROA scaduta. Se la ROA scade e non la rinnovi entro quattro settimane dalla notifica di rinnovo di Google, Google smette di annunciare il prefisso.
• Nomi e regioni sono fissi. Rinominare un prefisso significa eliminarlo e ricrearlo, e spostare un prefisso delegato in un’altra regione “can take approximately eight weeks” (traduzione: “può richiedere circa otto settimane”). Scegli nomi come pap-203-0-113-0-24 e delega solo ciò di cui sei sicuro.
• Rimuovere la ROA troppo presto. Dopo aver eliminato un public advertised prefix, attendi 14 giorni prima di rimuovere la ROA per l’ASN di Google.

Se il blocco è in affitto

Google non pubblica alcuna regola su a nome di chi deve essere registrato il blocco, e non chiede una Letter of Authorization. Le sue due verifiche, la ROA e il record PTR, spettano entrambe al titolare di un blocco in affitto. Il titolare crea la ROA per AS396982 o AS19527, e quella per il tuo ASN se la vuoi. Il titolare crea anche il record PTR con il nome di Google, oppure delega la zona inversa del blocco a name server che controlli tu. Concorda che la ROA venga rinnovata per tutto il tempo in cui Google annuncia il blocco, e mantenuta per 14 giorni dopo la tua uscita.

Dove entra RTM Networks

Affittiamo /24 e blocchi più grandi dal nostro spazio di indirizzi RIPE NCC, e vendiamo blocchi nelle regioni del RIPE NCC, dell’ARIN e dell’APNIC. Per lo spazio affittato da noi, creiamo la ROA per l’ASN di Google e il record PTR con il nome di Google (affitto di indirizzi IPv4). Se ti servono meno di 256 indirizzi su una VM Compute Engine, annunciamo noi un blocco e lo consegniamo via GRE o WireGuard, in qualsiasi dimensione fino a un solo indirizzo (tunnel GRE e WireGuard). Come si somma l’addebito orario per gli IPv4 presso i grandi cloud: il costo reale degli IPv4 nel cloud. Altri provider: guide BYOIP.