BYOIP la Azure: propriile adrese IPv4 ca prefix IP personalizat

Dovediți că plaja este a dvs. cu un ROA care numește ASN-ul Microsoft și un certificat în înregistrarea ei WHOIS/RDAP, apoi o configurați și derivați din ea public IP prefixes și adrese.

Acest ghid urmează modelul unificat, pentru o plajă folosită într-o singură regiune, prin Azure CLI. O plajă nu poate trece la modelul global/regional, un părinte cu copii regionali, fără să fie preluată din nou.

Ce acceptă Azure

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

• Mărime. Un prefix unificat „must be between /21 and /24” (traducere: „trebuie să fie între /21 și /24”). Un părinte global este tot de la /21 la /24, cu copii regionali de la /22 la /26.
• Registru și nume. Plaja „must be owned by you and registered under your name” (traducere: „trebuie să fie deținută de dvs. și înregistrată pe numele dvs.”) la un Regional Internet Registry, printre care ARIN, RIPE NCC și APNIC. Nimic despre statutul PA, PI sau legacy.
• Cine este originea. Microsoft, sub AS8075, sau AS8070 pentru US Gov Cloud. Paginile BYOIP ale Microsoft nu documentează nicio opțiune pentru propriul ASN. Comanda CLI de la pasul 1, az network custom-ip prefix create, are totuși un parametru --asn, descris doar ca „The ASN for CIDR advertising” (traducere: „ASN-ul pentru anunțarea CIDR”), așa că întrebați Microsoft înainte să contați pe el.
• Regiuni. O regiune per prefix și cinci prefixe per regiune implicit, mai multe la cerere.
• Preț. „There's no charge to provision or use custom IP prefixes” (traducere: „Nu există niciun cost pentru configurarea sau folosirea custom IP prefixes”), nici pentru public IP prefixes și adresele derivate din ele. Traficul se facturează la tarifele de ieșire spre internet.
• Termen. Circa 30 de minute pentru configurare și trei-patru ore pentru punerea în funcțiune globală.
• Limite. Fără Internet Routing Preference, Global Tier, ExpressRoute Microsoft peering sau public IP-uri Standard v2. DNS-ul invers rulează din propriile zone în Azure DNS, Windows Server Activation poate dura până la o săptămână, iar o plajă configurată nu își poate schimba subscripția.

Înainte să începeți

Un ROA pentru AS8075, cu lungimea prefixului exact așa cum o va anunța Microsoft și o dată de expirare care acoperă perioada în care vreți să fie anunțată (RPKI și ROA). Lăsați cel puțin 24 de ore ca Microsoft să îl vadă. Microsoft recomandă și un ROA pentru orice ASN care anunță azi plaja.

O pereche de chei și un certificat autosemnat, făcute cu OpenSSL:

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

Certificatul în înregistrarea WHOIS/RDAP a prefixului, inclusiv marcajele BEGIN și END, fără spații sau rânduri noi:

Un mesaj de autorizare semnat: ID-ul subscripției dvs., prefixul și data de expirare a ROA-ului, în această ordine:

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 nu cere nicio Letter of Authorization și niciun obiect route.

Pas cu pas

01Configurați plaja, într-un resource group existent. Într-o regiune cu availability zones, faceți-o zone-redundant sau fixați-o într-o singură zonă:

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"

02Așteptați Provisioned. commissionedState returnat de az network custom-ip prefix show trece de la Provisioning la Provisioned. Un ValidationFailed timpuriu înseamnă că ROA-ul, certificatul sau mesajul nu au trecut verificarea; câmpul FailedReason spune care.

03Derivați adrese. Creați un public IP prefix din plajă, apoi adrese Standard SKU din el, și atașați-le la VM-uri sau load balancere; încă nu sunt anunțate.

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

04Puneți în funcțiune. Dacă plaja este activă în altă parte, două anunțuri simultane „could potentially create BGP routing instability or traffic loss” (traducere: „ar putea crea instabilitate de rutare BGP sau pierdere de trafic”). Puneți-o întâi în funcțiune în interiorul regiunii (Commission, apoi opțiunea doar pentru regiune, în portal, sau -NoInternetAdvertise în PowerShell), testați, retrageți vechiul anunț, apoi puneți-o în funcțiune global:

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

Plaja este anunțată parțial cât timp este Commissioning, întâi din regiune, apoi din rețeaua Microsoft sub AS8075, până devine Commissioned.

Greșeli care costă o zi

• Certificatul în descr. Pentru RIPE NCC, Microsoft spune remarks, în timp ce AWS citește descr și explicit nu remarks, așa că un bloc care se mută între cele două cloud-uri are nevoie de modificarea înregistrării.
• O dată care nu se potrivește. Data din mesajul semnat este data de expirare a ROA-ului, ca yyyymmdd; dacă nu există una, Microsoft spune să alegeți data până la care vreți să fie anunțată plaja.
• Un ROA cu lungimea greșită. O nepotrivire cu prefixul configurat eșuează ca InvalidPrefixLengthInROA.
• Plecarea în ordinea greșită. Ștergeți fiecare public IP prefix derivat, apoi scoateți plaja din funcțiune (trei-patru ore) înainte să modificați sau să ștergeți ROA-ul. Altfel Microsoft continuă să anunțe o plajă pe care nu mai este autorizat să o anunțe.

Dacă închiriați blocul

Regula Microsoft este obstacolul: plaja trebuie să fie deținută de dvs. și înregistrată pe numele dvs. Un bloc înregistrat doar pe locator nu îndeplinește asta așa cum este scrisă, iar Microsoft nu spune dacă o atribuire pe numele dvs. în alocarea deținătorului contează, așa că întrebați deținătorul și Microsoft înainte să semnați. Deținătorul creează apoi ROA-ul pentru AS8075 și adaugă certificatul dvs. în remarks al înregistrării. Și DNS-ul invers are nevoie de deținător: Azure îl servește doar dintr-o zonă inversă găzduită de dvs. în Azure DNS, pe care deținătorul v-o delegă. Nu este nevoie de nicio Letter of Authorization.

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, înregistrăm atribuirea pe organizația dvs., creăm ROA-ul pentru AS8075 și adăugăm certificatul dvs. în înregistrarea din registru (închiriere IPv4). Dacă Microsoft vrea mai mult decât o atribuire pe numele dvs., cumpărarea blocului rezolvă problema (cumpărare IPv4). Dacă nu aveți propriul LIR, sponsorizăm spațiu PI și legacy și numere AS (sponsorizare). Pentru mai puțin de 256 de adrese pe un VM Azure, anunțăm un bloc și îl livrăm prin WireGuard, pentru că Azure blochează GRE, în orice mărime, până la o singură adresă (tuneluri WireGuard). Alți furnizori: ghiduri BYOIP.