BYOIP la Google Cloud: propriile adrese IPv4 în Compute Engine

Dovediți controlul asupra blocului cu un ROA care numește ASN-ul Google și o înregistrare PTR care poartă un nume dat de Google, apoi decupați din el prefixe delegate și creați din acestea adrese externe statice.

Acest ghid acoperă IPv4 în configurația recomandată de Google, un prefix regional (v2) pe Premium Tier, prin gcloud CLI. Adresele globale pentru load balancerele globale folosesc configurația v1 mai veche, iar proiectul dvs. trebuie întâi să fie pe un allowlist.

Ce acceptă Google Cloud

Din documentația Google Cloud, în ziua în care am verificat:

• Mărime. Un public advertised prefix de „/16 to /24” (traducere: „de la /16 la /24”) pe Premium Tier, cel implicit, sau „/16 to /23” (traducere: „de la /16 la /23”) pe Standard Tier, aflat în Preview. Îl puteți împărți până la blocuri /28.
• Registru. Google dă linkuri către instrucțiunile ROA ale fiecărui registru regional, printre care ARIN, RIPE NCC și APNIC. Nu publică nimic despre statutul PA, PI sau legacy ori despre numele pe care trebuie să fie blocul.
• Cine este originea. Google, din AS396982 pe Premium Tier sau AS19527 pe Standard Tier. Nu documentează nicio opțiune de anunț din propriul ASN.
• Fără suprapunere. „Google does not support overlapping BYOIP route announcements” (traducere: „Google Cloud nu acceptă anunțuri de rute BYOIP suprapuse”): nici prefixul, nici vreo parte din el nu pot fi anunțate în altă parte cât timp le anunță Google.
• Regiuni. Fiecare prefix delegat servește o regiune sau domeniul global. Paginile BYOIP ale Google nu numesc nicio regiune exclusă.
• Preț. „There are no charges for idle or in-use IP addresses.” (traducere: „Nu există costuri pentru adresele IP nefolosite sau folosite.”)
• Termen. „Approximately 2 weeks” (traducere: „circa 2 săptămâni”) pentru un prefix v2 după validare, „approximately 4 weeks” (traducere: „circa 4 săptămâni”) pentru cele v1 și globale. Configurarea „cannot be accelerated” (traducere: „nu poate fi accelerată”).
• Resurse. Majoritatea celor care primesc o adresă externă statică, dar nu nodurile și Pod-urile GKE sau adresa externă a unui gateway Cloud VPN. Adresele nu se pot muta între proiecte.

Înainte să începeți

Un ROA pentru ASN-ul Google. Pe Premium Tier numește prefixul, lungimea lui exactă și AS396982. Pe Standard Tier numește AS19527, fie într-un ROA pentru fiecare prefix pe care îl veți configura, cum recomandă Google, fie într-un singur ROA cu lungimea maximă /24 (RPKI și ROA).

Un al doilea ROA pentru propriul dvs. ASN. Google recomandă unul cu aceleași detalii și ASN-ul dvs. ca origine, ca rețelele care fac route origin validation să nu trateze prefixul ca invalid dacă îl veți anunța vreodată singuri.

Controlul asupra DNS-ului invers. Google verifică proprietatea cu o înregistrare PTR, nu cu un token în înregistrarea din registru. Alegeți o adresă nefolosită din prefix, Google întoarce un nume (secretul său partajat), iar dvs. publicați pentru acea adresă o înregistrare PTR care indică acel nume sub domeniul dvs.

Nimic altceva din registru. Google nu cere niciun certificat, nicio Letter of Authorization și niciun obiect route. De partea sa, aveți nevoie de rolul Compute Public IP Admin (roles/compute.publicIpAdmin) pe proiect.

Pas cu pas

01Creați public advertised prefix, numind adresa pe care o veți folosi pentru validarea 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

Pentru Standard Tier, folosiți gcloud beta și adăugați --network-tier=STANDARD.

02Publicați înregistrarea PTR. gcloud compute public-advertised-prefixes describe pap-203-0-113-0-24 --format='value(sharedSecret)' dă numele. Dacă este 55kk88tt00 și domeniul dvs. este example.net, atunci dig +short -x 203.0.113.144 trebuie să întoarcă 55kk88tt00.example.net.

03Porniți validarea:

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

Starea devine VALIDATED sau REVERSE_DNS_LOOKUP_FAILED dacă Google nu găsește înregistrarea. Configurarea s-a încheiat când describe cu --format='value(status)' arată PREFIX_CONFIGURATION_COMPLETE.

04Delegați un bloc către o regiune. Asta poate rula cât așteptați:

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ți adrese. Prefixele delegate publice regionale create după 13 decembrie 2025 permit adrese individuale:

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

Prefixele mai vechi și adresele globale primesc blocuri întregi, prin delegated-sub-prefixes create --create-addresses. Atașați adresele la VM-uri sau forwarding rules. Încă nu sunt accesibile.

06Anunțați. Asigurați-vă că nicio altă rețea nu anunță blocul. Anunțați întâi prefixul delegat, pe care Google îl poartă în propria rețea, apoi prefixul anunțat, care merge pe internet din toate punctele de prezență 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

Din exterior, validatorul RIPEstat ar trebui să numească prefixul valid pentru AS396982: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=396982&prefix=203.0.113.0/24".

Greșeli care costă o zi

• Două rețele care anunță. Suprapunerea include o rută mai specifică: un /24 anunțat în altă parte în interiorul unui /23 adus de dvs. contează. Google avertizează despre „unexpected routing and packet loss” (traducere: „rutare neașteptată și pierdere de pachete”).
• v1 se anunță singur. Un prefix global (v1) este anunțat de îndată ce prefixul său delegat este configurat. Google spune să nu creați prefixe delegate până când nimeni altcineva nu mai anunță blocul.
• Un ROA expirat. Dacă ROA-ul expiră și nu îl reînnoiți în patru săptămâni de la notificarea de reînnoire a Google, Google încetează să anunțe prefixul.
• Numele și regiunile sunt fixe. Redenumirea unui prefix înseamnă ștergerea și recrearea lui, iar mutarea unui prefix delegat în altă regiune „can take approximately eight weeks” (traducere: „poate dura circa opt săptămâni”). Alegeți nume ca pap-203-0-113-0-24 și delegați doar ce știți sigur.
• Ștergerea ROA-ului prea devreme. După ce ștergeți un public advertised prefix, așteptați 14 zile înainte să ștergeți ROA-ul pentru ASN-ul Google.

Dacă închiriați blocul

Google nu publică nicio regulă despre numele pe care este înregistrat blocul și nu cere nicio Letter of Authorization. Cele două verificări ale sale, ROA-ul și înregistrarea PTR, stau amândouă la deținătorul unui bloc închiriat. Deținătorul creează ROA-ul pentru AS396982 sau AS19527 și pe cel pentru ASN-ul dvs., dacă îl vreți. Deținătorul creează și înregistrarea PTR cu numele dat de Google sau deleagă zona inversă a blocului către servere de nume controlate de dvs. Stabiliți ca ROA-ul să fie reînnoit cât timp Google anunță blocul și păstrat 14 zile după ce plecați.

Unde se încadrează RTM Networks

Închiriem /24 și mai mari din propriul spațiu de adrese RIPE NCC și vindem blocuri în regiunile RIPE NCC, ARIN și APNIC. Pentru spațiul închiriat de la noi, creăm ROA-ul pentru ASN-ul Google și înregistrarea PTR cu numele dat de Google (închiriere IPv4). Dacă aveți nevoie de mai puțin de 256 de adrese pe un VM Compute Engine, anunțăm noi înșine un bloc și îl livrăm prin GRE sau WireGuard, în orice mărime, până la o singură adresă (tuneluri GRE și WireGuard). Cum se adună tariful orar pentru IPv4 la marile cloud-uri: costul real al IPv4 în cloud. Alți furnizori: ghiduri BYOIP.