BYOIP w Cloudflare: własne prefiksy IP w sieci Cloudflare

Opisany proces w API sprawdza prefiks w IRR, RPKI i za pomocą tokenu własności, a potem wiążesz go z usługami, które będą używać jego adresów.

Co przyjmuje Cloudflare

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

• Kto. Konta Enterprise, których umowa obejmuje BYOIP. Potwierdza to zespół opiekunów konta, podobnie jak konfigurację usług konta, zanim zaczniesz wdrożenie.
• Rozmiar. /24 lub większy dla IPv4; dla IPv6 od /48 do /32.
• Rejestr. ARIN, RIPE NCC, APNIC lub jeden z pozostałych rejestrów regionalnych. Nic o przestrzeni PA, PI ani legacy.
• Kto ogłasza. AS13335 w opisanym procesie; w sprawie własnego ASN zapytaj zespół opiekunów konta. Klienci, którzy już korzystają z AS209242 Cloudflare, mogą go zachować, ale nowe wdrożenia używają AS13335.
• Gdzie. Wszystkie lokalizacje Cloudflare.
• Usługi. Magic Transit, Spectrum, CDN oraz lokalizacje DNS i dedykowane adresy wychodzące Gateway. Magic Transit ma własne wdrożenie, jest „not a self-serve product” (tłumaczenie: „produktem, którego nie skonfigurujesz samodzielnie”) i może być jedynie domyślnym powiązaniem całego prefiksu. Prefiks obsługuje ruch przychodzący CDN albo wychodzący CDN, nie oba.
• Cena. Nieopublikowana. Warunki mówią, że adresów wolno używać „solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services” (tłumaczenie: „wyłącznie w związku z domenami Klienta objętymi usługami Enterprise Cloudflare”).
• Czas. Co najmniej pięć godzin udostępniania BGP przed ogłoszeniem i od czterech do sześciu godzin na propagację każdego powiązania z usługą. Konfiguracja Magic Transit „takes around one day to roll out” (tłumaczenie: „wdraża się około jednego dnia”).

Zanim zaczniesz

Cloudflare nie wdroży prefiksu, jeśli nie przejdzie którakolwiek kontrola rejestracji, IRR, RPKI lub własności. Przygotuj:

Obiekt route, który dokładnie pasuje. Jeden obiekt route na każdy wdrażany prefiks, dokładnie dla tego prefiksu, ze źródłem, którego użyje Cloudflare: AS13335 w standardowym procesie. Do sprawdzenia Cloudflare proponuje IRR Explorer lub whois -h rr.ntt.net 203.0.113.0/24.

Poprawne ROA dla tego samego źródła. Cloudflare prosi o sprawdzenie go w swoim RPKI Portal i w drugim źródle, np. Routinator (RPKI i ROA).

Letter of agency (LOA), czyli nazwa, jaką Cloudflare nadaje Letter of Authorization, wymaganemu przez jego dostawców tranzytu. Cloudflare generuje je za Ciebie, gdy ustawisz delegate_loa_creation na true, co opiera się na ROA i kontroli własności. Ręczny LOA musi być w PDF i powinno być na papierze firmowym z odręcznym podpisem, choć Cloudflare przyjmuje podpis cyfrowy, jeśli jasno widać, kto podpisał. Dostawcy tranzytu mogą odrzucić JPG lub PNG, a ręczne przetwarzanie może spowolnić wdrożenie.

Miejsce na token walidacyjny: opis (descr) lub remarks pasującego obiektu route albo rekord TXT cf-validation w każdej strefie odwrotnego DNS prefiksu.

Identyfikator konta i token API z uprawnieniami IP Prefixes.

Krok po kroku

To opisany przez Cloudflare proces dla prefiksów nieużywanych z Magic Transit, który ma własne wdrożenie przez zespół opiekunów konta.

01Dodaj prefiks do konta, które będzie jego właścicielem:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes" \
  --request POST --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"cidr":"203.0.113.0/24","asn":13335,"delegate_loa_creation":true}'

Zapisz id i ownership_validation_token z odpowiedzi.

02Opublikuj token. Dodaj cf-validation: <token> do obiektu route albo rekord TXT do stref odwrotnych.

03Zwaliduj. Wyślij POST na .../prefixes/$PREFIX_ID/validate. Gdy kontrole IRR, RPKI i własności przejdą, pole approved prefiksu pokazuje "V" i możesz usunąć token. Jeśli kontrola nie przejdzie, szczegóły prefiksu pokazują stany takie jak missing, invalid czy mismatch_asn.

04Powiąż prefiks z usługą. Każdy prefiks potrzebuje domyślnego powiązania z usługą dla całego prefiksu; bardziej szczegółowe powiązania mogą kierować jego części do CDN lub Spectrum. Cloudflare tworzy prefiks BGP w stanie wycofanym. Daj na to co najmniej pięć godzin i poczekaj, aż każde powiązanie będzie aktywne.

05Ogłoś:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
  --request PATCH --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"on_demand":{"advertised":true}}'

Cloudflare podaje, że ogłoszenie trwa zwykle od dwóch do siedmiu minut, a wycofanie około 15.

06Dla CDN utwórz address map, gdy prefiks jest już ogłaszany, aby rekordy DNS przechodzące przez proxy odpowiadały Twoimi adresami.

Pułapki

• Obiekt route obejmujący szerszy zakres nie wystarczy. Cloudflare chce obiektu route dokładnie pasującego do każdego wdrażanego prefiksu, z właściwym źródłem.
• Powiązania trwają godzinami, a ruch w tym czasie cierpi. Cloudflare podaje, że usługi dla danych adresów prawdopodobnie będą zakłócone podczas propagacji powiązania. Skonfiguruj powiązania przed ogłoszeniem, a zmieniaj je poza godzinami szczytu.
• Dwie sieci ogłaszające. Gdy przenosisz działający prefiks, pozwól Cloudflare ogłosić go najpierw, sprawdź go w looking glass pod AS13335, a dopiero potem wycofaj własne ogłoszenie. Jeśli zostawisz swoje, część ruchu może omijać Cloudflare.
• Zasada 15 minut. Po zmianie ogłoszenia prefiksu odczekaj co najmniej 15 minut przed kolejną zmianą; API odrzuca wcześniejsze wywołania błędem 1004 (HTTP 429, rate_limit_exceeded).

Jeśli dzierżawisz blok

Warunki dla poszczególnych usług Cloudflare, ostatnio zaktualizowane 28 września 2026, mówią o tym wprost. Jeśli nie jesteś prawnym właścicielem adresów, „must obtain written authorization from the legal owner” (tłumaczenie: „musisz uzyskać pisemne upoważnienie od prawnego właściciela”), aby Cloudflare mógł je ogłaszać, a jeśli właściciel je cofnie, Cloudflare może przestać je ogłaszać. Posiadacz robi też stronę rejestrową: ROA dla AS13335, obiekt route z AS13335 jako źródłem i token walidacyjny w tym obiekcie, który może edytować tylko maintainer posiadacza. Warunki wymagają przez cały czas dokładnych danych WHOIS oraz ważnych wpisów IRR i RPKI, więc zakończenie dzierżawy lub zmiana ROA mogą zdjąć prefiks z Cloudflare.

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 i dokładny obiekt route dla AS13335, dodajemy do niego token walidacyjny Cloudflare i podpisujemy Letter of Authorization, więc po Twojej stronie zostają kroki w API (dzierżawa IPv4). Jeśli BYOIP nie jest objęte Twoją umową z Cloudflare albo potrzebujesz mniej niż 256 adresów, ogłaszamy blok i dostarczamy go do Twojego serwera przez GRE lub WireGuard, aż do jednego adresu (tunele GRE i WireGuard). Inni dostawcy: przewodniki BYOIP.