BYOIP w Google Cloud: własne adresy IPv4 w Compute Engine

Dowodzisz kontroli nad blokiem za pomocą ROA wskazującej ASN Google i rekordu PTR z nazwą, którą podaje Ci Google, a potem wydzielasz z niego prefiksy delegowane i tworzysz z nich statyczne adresy zewnętrzne.

Ten przewodnik opisuje IPv4 w konfiguracji zalecanej przez Google, czyli prefiks regionalny (v2) w Premium Tier, przez gcloud CLI. Adresy globalne dla globalnych load balancerów używają starszej konfiguracji v1, a Twój projekt musi najpierw trafić na listę dozwolonych (allowlist).

Co przyjmuje Google Cloud

Według dokumentacji Google Cloud w dniu, w którym sprawdzaliśmy:

• Rozmiar. Public advertised prefix od „/16 to /24” (tłumaczenie: „od /16 do /24”) w Premium Tier, domyślnym, albo „/16 to /23” (tłumaczenie: „od /16 do /23”) w Standard Tier, który jest w fazie Preview. Możesz go podzielić aż do bloków /28.
• Rejestr. Google podaje linki do instrukcji ROA dla każdego rejestru regionalnego, w tym ARIN, RIPE NCC i APNIC. Nie publikuje nic o statusie PA, PI ani legacy, ani o tym, na kogo blok ma być zarejestrowany.
• Kto ogłasza. Google, z AS396982 w Premium Tier lub AS19527 w Standard Tier. Nie opisuje opcji ogłaszania z własnego ASN.
• Bez nakładania się. „Google does not support overlapping BYOIP route announcements” (tłumaczenie: „Google Cloud nie obsługuje nakładających się ogłoszeń tras BYOIP”): ani prefiks, ani żadna jego część nie może być ogłaszana gdzie indziej, gdy ogłasza go Google.
• Regiony. Każdy prefiks delegowany obsługuje jeden region albo zakres globalny. Strony BYOIP Google nie wymieniają wykluczonych regionów.
• Cena. „There are no charges for idle or in-use IP addresses.” (tłumaczenie: „Za nieużywane i używane adresy IP nie pobiera się opłat.”)
• Czas. „Approximately 2 weeks” (tłumaczenie: „około 2 tygodni”) dla prefiksu v2 po walidacji, „approximately 4 weeks” (tłumaczenie: „około 4 tygodni”) dla v1 i globalnych. Udostępnienia „cannot be accelerated” (tłumaczenie: „nie da się przyspieszyć”).
• Zasoby. Większość tych, które przyjmują statyczny adres zewnętrzny, ale nie węzły i Pody GKE ani zewnętrzny adres bramy Cloud VPN. Adresów nie można przenosić między projektami.

Zanim zaczniesz

ROA dla ASN Google. W Premium Tier wskazuje prefiks, jego dokładną długość i AS396982. W Standard Tier wskazuje AS19527, albo w jednej ROA na każdy udostępniany prefiks, co zaleca Google, albo w jednej ROA z maksymalną długością /24 (RPKI i ROA).

Drugie ROA dla Twojego własnego ASN. Google zaleca takie z tymi samymi danymi i Twoim ASN jako źródłem, aby sieci stosujące walidację źródła trasy nie uznały prefiksu za nieważny, jeśli kiedyś sam go ogłosisz.

Kontrola nad reverse DNS. Google sprawdza własność rekordem PTR, a nie tokenem w rekordzie rejestru. Wybierasz nieużywany adres w prefiksie, Google zwraca nazwę (swój wspólny sekret), a Ty publikujesz dla tego adresu rekord PTR wskazujący tę nazwę w Twojej domenie.

Nic więcej z rejestru. Google nie prosi o certyfikat, Letter of Authorization ani obiekt route. Po jego stronie potrzebujesz roli Compute Public IP Admin (roles/compute.publicIpAdmin) w projekcie.

Krok po kroku

01Utwórz public advertised prefix, wskazując adres, którego użyjesz do walidacji 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

Dla Standard Tier użyj gcloud beta i dodaj --network-tier=STANDARD.

02Opublikuj rekord PTR. gcloud compute public-advertised-prefixes describe pap-203-0-113-0-24 --format='value(sharedSecret)' podaje nazwę. Jeśli to 55kk88tt00, a Twoja domena to example.net, to dig +short -x 203.0.113.144 musi zwrócić 55kk88tt00.example.net.

03Uruchom walidację:

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

Status zmienia się na VALIDATED albo na REVERSE_DNS_LOOKUP_FAILED, jeśli Google nie znajdzie rekordu. Udostępnienie jest zakończone, gdy describe z --format='value(status)' pokazuje PREFIX_CONFIGURATION_COMPLETE.

04Deleguj blok do regionu. Można to zrobić w trakcie oczekiwania:

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

05Utwórz adresy. Regionalne publiczne prefiksy delegowane utworzone po 13 grudnia 2025 pozwalają na pojedyncze adresy:

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

Starsze prefiksy i adresy globalne przyjmują całe bloki, przez delegated-sub-prefixes create --create-addresses. Podłącz adresy do maszyn wirtualnych lub reguł przekazywania (forwarding rules). Nie są jeszcze osiągalne.

06Ogłoś. Upewnij się, że żadna inna sieć nie ogłasza bloku. Najpierw ogłoś prefiks delegowany, który Google przenosi wewnątrz swojej sieci, a potem prefiks ogłaszany, który trafia do internetu ze wszystkich punktów obecności 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

Z zewnątrz walidator RIPEstat powinien uznać prefiks za ważny dla AS396982: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=396982&prefix=203.0.113.0/24".

Błędy, które kosztują dzień

• Dwie sieci ogłaszające. Nakładanie się obejmuje trasę bardziej szczegółową: liczy się /24 ogłaszany gdzie indziej wewnątrz wnoszonego przez Ciebie /23. Google ostrzega przed „unexpected routing and packet loss” (tłumaczenie: „nieoczekiwanym routingiem i utratą pakietów”).
• v1 ogłasza się sam. Prefiks globalny (v1) jest ogłaszany, gdy tylko zostanie udostępniony jego prefiks delegowany. Google każe nie tworzyć prefiksów delegowanych, dopóki ktoś inny ogłasza blok.
• Wygasłe ROA. Jeśli ROA wygaśnie, a nie odnowisz go w ciągu czterech tygodni od powiadomienia Google o odnowieniu, Google przestaje ogłaszać prefiks.
• Nazwy i regiony są stałe. Zmiana nazwy prefiksu oznacza jego usunięcie i ponowne utworzenie, a przeniesienie prefiksu delegowanego do innego regionu „can take approximately eight weeks” (tłumaczenie: „może zająć około ośmiu tygodni”). Wybieraj nazwy takie jak pap-203-0-113-0-24 i deleguj tylko to, czego jesteś pewien.
• Zbyt wczesne usunięcie ROA. Po usunięciu public advertised prefix odczekaj 14 dni, zanim usuniesz ROA dla ASN Google.

Jeśli dzierżawisz blok

Google nie publikuje żadnej zasady co do tego, na kogo blok jest zarejestrowany, i nie prosi o Letter of Authorization. Obie jego kontrole, ROA i rekord PTR, leżą po stronie posiadacza dzierżawionego bloku. Posiadacz tworzy ROA dla AS396982 lub AS19527 oraz, jeśli chcesz, ROA dla Twojego ASN. Posiadacz tworzy też rekord PTR z nazwą od Google albo deleguje strefę odwrotną bloku na serwery nazw, które kontrolujesz. Ustal, że ROA będzie odnawiane tak długo, jak Google ogłasza blok, i utrzymywane przez 14 dni po Twoim odejściu.

Gdzie pasuje RTM Networks

Dzierżawimy /24 i większe z naszej własnej przestrzeni adresowej RIPE NCC i sprzedajemy bloki w regionach RIPE NCC, ARIN i APNIC. Dla przestrzeni dzierżawionej od nas tworzymy ROA dla ASN Google i rekord PTR z nazwą od Google (dzierżawa IPv4). Jeśli potrzebujesz mniej niż 256 adresów na maszynie wirtualnej Compute Engine, sami ogłaszamy blok i dostarczamy go przez GRE lub WireGuard, w dowolnym rozmiarze aż do jednego adresu (tunele GRE i WireGuard). Jak sumuje się godzinowa opłata za IPv4 w dużych chmurach: rzeczywisty koszt IPv4 w chmurze. Inni dostawcy: przewodniki BYOIP.