BYOIP w Azure: własne adresy IPv4 jako custom IP prefix

Dowodzisz, że zakres jest Twój, za pomocą ROA wskazującej ASN Microsoftu i certyfikatu w jego rekordzie WHOIS/RDAP, a potem udostępniasz go i wyprowadzasz z niego public IP prefixes i adresy.

Ten przewodnik opisuje model ujednolicony (unified), dla zakresu używanego w jednym regionie, przez Azure CLI. Zakres nie może przejść na model globalny/regionalny, czyli prefiks nadrzędny z regionalnymi prefiksami podrzędnymi, bez ponownego wdrożenia.

Co przyjmuje Azure

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

• Rozmiar. Prefiks ujednolicony „must be between /21 and /24” (tłumaczenie: „musi mieć od /21 do /24”). Globalny prefiks nadrzędny to także /21 do /24, z regionalnymi podrzędnymi od /22 do /26.
• Rejestr i nazwa. Zakres „must be owned by you and registered under your name” (tłumaczenie: „musi należeć do Ciebie i być zarejestrowany na Ciebie”) w regionalnym rejestrze internetowym, w tym w ARIN, RIPE NCC i APNIC. Nic o statusie PA, PI ani legacy.
• Kto ogłasza. Microsoft, z AS8075, albo AS8070 dla US Gov Cloud. Strony BYOIP Microsoftu nie opisują opcji z własnym ASN. Polecenie CLI z kroku 1, az network custom-ip prefix create, wymienia wprawdzie parametr --asn, opisany jedynie jako „The ASN for CIDR advertising” (tłumaczenie: „ASN do ogłaszania CIDR”), więc zapytaj Microsoft, zanim na nim polegasz.
• Regiony. Jeden region na prefiks i domyślnie pięć prefiksów na region, więcej na życzenie.
• Cena. „There's no charge to provision or use custom IP prefixes” (tłumaczenie: „Udostępnianie i używanie custom IP prefixes jest bezpłatne”), podobnie jak wyprowadzonych z nich public IP prefixes i adresów. Ruch jest rozliczany według stawek za ruch wychodzący do internetu.
• Czas. Około 30 minut na udostępnienie i trzy do czterech godzin na globalne uruchomienie.
• Ograniczenia. Bez Internet Routing Preference, Global Tier, ExpressRoute Microsoft peering i publicznych IP Standard v2. Reverse DNS działa z Twoich własnych stref w Azure DNS, aktywacja Windows Server może trwać do tygodnia, a udostępniony zakres nie może zmienić subskrypcji.

Zanim zaczniesz

ROA dla AS8075, z długością prefiksu dokładnie taką, jaką ogłosi Microsoft, i datą wygaśnięcia obejmującą czas, przez który chcesz, aby był ogłaszany (RPKI i ROA). Daj Microsoftowi co najmniej 24 godziny, aby je zobaczył. Microsoft zaleca też ROA dla każdego ASN, który ogłasza zakres dziś.

Para kluczy i certyfikat z podpisem własnym, utworzone w OpenSSL:

openssl genrsa -out byoipprivate.key 2048
openssl req -new -x509 -key byoipprivate.key -days 180 | tr -d "\n" > byoippublickey.cer

Certyfikat w rekordzie WHOIS/RDAP prefiksu, ze znacznikami BEGIN i END, bez spacji i podziałów linii:

Podpisany komunikat autoryzacyjny: identyfikator subskrypcji, prefiks i data wygaśnięcia ROA, w tej kolejności:

byoipauth="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|203.0.113.0/24|20270430"
byoipauthsigned=$(echo $byoipauth | tr -d "\n" | openssl dgst -sha256 -sign byoipprivate.key -keyform PEM | openssl base64 | tr -d "\n")

Microsoft nie prosi o Letter of Authorization ani o obiekt route.

Krok po kroku

01Udostępnij zakres w istniejącej grupie zasobów. W regionie ze strefami dostępności ustaw go jako strefowo redundantny albo przypnij do jednej strefy:

az network custom-ip prefix create --name byoip-203-0-113-0-24 \
  --resource-group byoip-rg --location westeurope --cidr 203.0.113.0/24 --zone 1 2 3 \
  --authorization-message "$byoipauth" --signed-message "$byoipauthsigned"

02Poczekaj na Provisioned. Pole commissionedState zwracane przez az network custom-ip prefix show zmienia się z Provisioning na Provisioned. Wczesny ValidationFailed oznacza, że ROA, certyfikat lub komunikat nie przeszły weryfikacji; pole FailedReason mówi, które.

03Wyprowadź adresy. Utwórz public IP prefix z zakresu, potem z niego adresy Standard SKU, i podłącz je do maszyn wirtualnych lub load balancerów; nie są jeszcze ogłaszane.

az network public-ip prefix create --name pip-203-0-113-0-28 --resource-group byoip-rg \
  --location westeurope --length 28 --custom-ip-prefix-name byoip-203-0-113-0-24 --zone 1 2 3

04Uruchom (commission). Jeśli zakres działa gdzie indziej, dwa ogłoszenia naraz „could potentially create BGP routing instability or traffic loss” (tłumaczenie: „mogą spowodować niestabilność routingu BGP lub utratę ruchu”). Najpierw uruchom go wewnątrz regionu (w portalu Commission, a potem opcja tylko dla regionu, albo -NoInternetAdvertise w PowerShell), przetestuj, wycofaj stare ogłoszenie, a potem uruchom go globalnie:

az network custom-ip prefix update --name byoip-203-0-113-0-24 --resource-group byoip-rg --state commission

W stanie Commissioning zakres jest ogłaszany częściowo, najpierw z regionu, potem z sieci Microsoftu z AS8075, aż osiągnie stan Commissioned.

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

• Certyfikat w descr. Dla RIPE NCC Microsoft wskazuje remarks, a AWS czyta descr i wyraźnie nie remarks, więc blok przenoszony między tymi dwiema chmurami wymaga zmiany rekordu.
• Niezgodna data. Data w podpisanym komunikacie to data wygaśnięcia ROA w formacie yyyymmdd; jeśli ROA jej nie ma, Microsoft każe wybrać datę, do której zakres ma być ogłaszany.
• ROA ze złą długością. Niezgodność z udostępnianym prefiksem kończy się błędem InvalidPrefixLengthInROA.
• Wyjście w złej kolejności. Usuń każdy wyprowadzony public IP prefix, potem wycofaj zakres (decommission) (trzy do czterech godzin), zanim zmienisz lub usuniesz ROA. W przeciwnym razie Microsoft dalej ogłasza zakres, do którego ogłaszania nie ma już upoważnienia.

Jeśli dzierżawisz blok

Przeszkodą jest zasada Microsoftu: zakres „must be owned by you and registered under your name” (tłumaczenie: „musi należeć do Ciebie i być zarejestrowany na Ciebie”). Blok zarejestrowany wyłącznie na wydzierżawiającego nie spełnia jej w tym brzmieniu, a Microsoft nie mówi, czy liczy się przydział (assignment) na Ciebie w ramach alokacji posiadacza, więc zapytaj posiadacza i Microsoft, zanim podpiszesz. Posiadacz tworzy wtedy ROA dla AS8075 i dodaje Twój certyfikat do remarks rekordu. Reverse DNS też wymaga posiadacza: Azure obsługuje go tylko ze strefy odwrotnej hostowanej przez Ciebie w Azure DNS, którą posiadacz Ci deleguje. Letter of Authorization nie jest potrzebny.

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 rejestrujemy przydział na Twoją organizację, tworzymy ROA dla AS8075 i dodajemy Twój certyfikat do rekordu rejestru (dzierżawa IPv4). Jeśli Microsoft oczekuje czegoś więcej niż przydziału na Ciebie, sprawę rozwiązuje zakup bloku (zakup IPv4). Jeśli nie prowadzisz własnego LIR, sponsorujemy przestrzeń PI i legacy oraz numery AS (sponsoring). Przy mniej niż 256 adresach na maszynie wirtualnej w Azure ogłaszamy blok i dostarczamy go przez WireGuard, bo Azure blokuje GRE, w dowolnym rozmiarze aż do jednego adresu (tunele WireGuard). Inni dostawcy: przewodniki BYOIP.