BYOIP su Azure: porta i tuoi indirizzi IPv4 come custom IP prefix

Dimostri che il range è tuo con una ROA che indica l’ASN di Microsoft e un certificato nel suo record WHOIS/RDAP, poi ne fai il provisioning e ne derivi public IP prefix e indirizzi.

Questa guida segue il modello unificato, per un range usato in una sola regione, tramite la Azure CLI. Un range non può passare al modello globale/regionale, un parent con figli regionali, senza essere caricato di nuovo.

Cosa accetta Azure

Dalla documentazione di Microsoft, il giorno in cui l’abbiamo verificata:

• Dimensione. Un prefisso unificato “must be between /21 and /24” (traduzione: “deve essere tra /21 e /24”). Anche un parent globale va da /21 a /24, con figli regionali da /22 a /26.
• Registro e nome. Il range “must be owned by you and registered under your name” (traduzione: “deve essere di tua proprietà e registrato a tuo nome”) presso un Regional Internet Registry, tra cui ARIN, il RIPE NCC e APNIC. Nulla sullo stato PA, PI o legacy.
• Chi lo origina. Microsoft, con AS8075, o AS8070 per US Gov Cloud. Le pagine BYOIP di Microsoft non documentano alcuna opzione per il tuo ASN. Il comando CLI del passo 1, az network custom-ip prefix create, elenca però un parametro --asn, descritto solo come “The ASN for CIDR advertising” (traduzione: “L’ASN per l’annuncio del CIDR”), quindi chiedi a Microsoft prima di contarci.
• Regioni. Una regione per prefisso, e cinque prefissi per regione per impostazione predefinita, di più su richiesta.
• Prezzo. “There's no charge to provision or use custom IP prefixes” (traduzione: “Non c’è alcun costo per il provisioning o l’uso dei custom IP prefix”), né per i public IP prefix e gli indirizzi derivati. Il traffico è fatturato alle tariffe di uscita verso internet.
• Tempi. Circa 30 minuti per il provisioning e tre o quattro ore per il commissioning globale.
• Limiti. Niente Internet Routing Preference, Global Tier, ExpressRoute Microsoft peering né IP pubblici Standard v2. Il DNS inverso funziona dalle tue zone in Azure DNS, la Windows Server Activation può richiedere fino a una settimana, e un range di cui è stato fatto il provisioning non può cambiare sottoscrizione.

Prima di iniziare

Una ROA per AS8075, con la lunghezza del prefisso esattamente come Microsoft lo annuncerà e una data di scadenza che copra il periodo in cui vuoi che sia annunciato (RPKI e ROA). Calcola almeno 24 ore perché Microsoft la veda. Microsoft consiglia anche una ROA per qualsiasi ASN che oggi annuncia il range.

Una coppia di chiavi e un certificato autofirmato, creati con OpenSSL:

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

Il certificato nel record WHOIS/RDAP del prefisso, compresi i marcatori BEGIN ed END, senza spazi né a capo:

Un messaggio di autorizzazione firmato: l’ID della tua sottoscrizione, il prefisso e la data di scadenza della ROA, in quest’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 non chiede una Letter of Authorization né un route object.

Passo per passo

01Esegui il provisioning del range, in un resource group esistente. In una regione con availability zone, rendilo ridondante tra zone o fissalo a una zona:

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"

02Attendi Provisioned. Il commissionedState restituito da az network custom-ip prefix show passa da Provisioning a Provisioned. Un ValidationFailed iniziale significa che la ROA, il certificato o il messaggio non hanno superato la verifica; il campo FailedReason dice quale.

03Deriva gli indirizzi. Crea un public IP prefix dal range, poi indirizzi Standard SKU da esso, e collegali a VM o load balancer; non sono ancora annunciati.

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

04Commissioning. Se il range è attivo altrove, due annunci contemporanei “could potentially create BGP routing instability or traffic loss” (traduzione: “potrebbero creare instabilità di routing BGP o perdita di traffico”). Esegui prima il commissioning all’interno della regione (Commission, poi l’opzione solo regionale, nel portale, oppure -NoInternetAdvertise in PowerShell), testa, ritira il vecchio annuncio, poi esegui il commissioning globale:

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

Il range è annunciato in parte mentre è Commissioning, prima dalla regione, poi dalla rete di Microsoft con AS8075, finché non è Commissioned.

Errori che costano una giornata

• Il certificato in descr. Per il RIPE NCC, Microsoft dice remarks, mentre AWS legge descr ed esplicitamente non remarks, quindi un blocco che passa tra i due cloud richiede di modificare il record.
• Una data che non corrisponde. La data nel messaggio firmato è la data di scadenza della ROA, come yyyymmdd; se non ne ha una, Microsoft dice di scegliere la data fino alla quale vuoi che il range sia annunciato.
• Una ROA con la lunghezza sbagliata. Una discrepanza con il prefisso di cui fai il provisioning fallisce come InvalidPrefixLengthInROA.
• Uscire nell’ordine sbagliato. Elimina ogni public IP prefix derivato, poi esegui il decommissioning del range (tre o quattro ore) prima di modificare o eliminare la ROA. Altrimenti Microsoft continua ad annunciare un range che non è più autorizzata ad annunciare.

Se il blocco è in affitto

L’ostacolo è la regola di Microsoft: il range “must be owned by you and registered under your name” (traduzione: “deve essere di tua proprietà e registrato a tuo nome”). Un blocco registrato solo al locatore non la soddisfa così come è scritta, e Microsoft non dice se un’assegnazione a te all’interno dell’allocazione del titolare vale, quindi chiedi al titolare e a Microsoft prima di firmare. Il titolare crea poi la ROA per AS8075 e aggiunge il tuo certificato ai remarks del record. Anche il DNS inverso richiede il titolare: Azure lo serve solo da una zona inversa che ospiti in Azure DNS, che il titolare ti delega. Non serve una Letter of Authorization.

Dove entra RTM Networks

Affittiamo /24 e blocchi più grandi dal nostro spazio di indirizzi RIPE NCC, e vendiamo blocchi nelle regioni del RIPE NCC, dell’ARIN e dell’APNIC. Per lo spazio affittato da noi, registriamo l’assegnazione alla tua organizzazione, creiamo la ROA per AS8075 e aggiungiamo il tuo certificato al record del registro (affitto di indirizzi IPv4). Se Microsoft vuole più di un’assegnazione a tuo nome, acquistare il blocco risolve la questione (acquisto di IPv4). Se non gestisci un tuo LIR, sponsorizziamo spazio PI e legacy e numeri AS (sponsorizzazione). Per meno di 256 indirizzi su una VM Azure, annunciamo un blocco e lo consegniamo via WireGuard, dato che Azure blocca GRE, in qualsiasi dimensione fino a un solo indirizzo (tunnel WireGuard). Altri provider: guide BYOIP.