BYOIP chez Azure : apportez vos propres adresses IPv4 en custom IP prefix

Vous prouvez que la plage est à vous avec un ROA qui nomme l'ASN de Microsoft et un certificat dans son objet WHOIS/RDAP, puis vous la provisionnez et en tirez des public IP prefixes et des adresses.

Ce guide suit le modèle unifié, pour une plage utilisée dans une seule région, avec l'Azure CLI. Une plage ne peut pas passer au modèle global/régional, un parent avec des enfants régionaux, sans être intégrée de nouveau.

Ce qu'Azure accepte

D'après la documentation de Microsoft, le jour de notre vérification :

• Taille. Un préfixe unifié « must be between /21 and /24 » (traduction : « doit être compris entre /21 et /24 »). Un parent global va aussi de /21 à /24, avec des enfants régionaux de /22 à /26.
• Registre et nom. La plage « must be owned by you and registered under your name » (traduction : « doit vous appartenir et être enregistrée à votre nom ») auprès d'un registre Internet régional, dont l'ARIN, le RIPE NCC et l'APNIC. Rien sur le statut PA, PI ou legacy.
• Qui annonce. Microsoft, sous AS8075, ou AS8070 pour le US Gov Cloud. Les pages BYOIP de Microsoft ne documentent aucune option pour votre propre ASN. La commande CLI de l'étape 1, az network custom-ip prefix create, liste bien un paramètre --asn, décrit seulement comme « The ASN for CIDR advertising » (traduction : « L'ASN pour l'annonce du CIDR ») : demandez à Microsoft avant de compter dessus.
• Régions. Une région par préfixe, et cinq préfixes par région par défaut, davantage sur demande.
• Prix. « There's no charge to provision or use custom IP prefixes » (traduction : « Le provisionnement et l'utilisation des custom IP prefixes ne sont pas facturés »), ni les public IP prefixes et adresses qui en sont tirés. Le trafic est facturé aux tarifs de sortie vers Internet.
• Délai. Environ 30 minutes pour provisionner et 3 à 4 heures pour la mise en service mondiale.
• Limites. Pas d'Internet Routing Preference, de Global Tier, de peering Microsoft ExpressRoute ni d'IP publiques Standard v2. Le DNS inverse fonctionne depuis vos propres zones dans Azure DNS, l'activation de Windows Server peut prendre jusqu'à une semaine, et une plage provisionnée ne peut pas changer d'abonnement.

Avant de commencer

Un ROA pour AS8075, avec une longueur de préfixe exactement telle que Microsoft l'annoncera et une date d'expiration couvrant la période pendant laquelle vous voulez qu'elle soit annoncée (RPKI et ROA). Comptez au moins 24 heures pour que Microsoft le voie. Microsoft recommande aussi un ROA pour tout ASN qui annonce la plage aujourd'hui.

Une paire de clés et un certificat autosigné, créés avec OpenSSL :

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

Le certificat dans l'objet WHOIS/RDAP du préfixe, marqueurs BEGIN et END compris, sans espaces ni sauts de ligne :

Un message d'autorisation signé : votre ID d'abonnement, le préfixe et la date d'expiration du ROA, dans cet ordre :

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 ne demande ni lettre d'autorisation ni objet route.

Étape par étape

01Provisionnez la plage, dans un groupe de ressources existant. Dans une région dotée de zones de disponibilité, rendez-la redondante entre zones ou attachez-la à une seule zone :

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"

02Attendez Provisioned. Le commissionedState que renvoie az network custom-ip prefix show passe de Provisioning à Provisioned. Un ValidationFailed précoce signifie que le ROA, le certificat ou le message n'a pas été validé ; le champ FailedReason dit lequel.

03Tirez-en des adresses. Créez un public IP prefix depuis la plage, puis des adresses de SKU Standard depuis celui-ci, et attachez-les à des VM ou à des load balancers ; elles ne sont pas encore annoncées.

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

04Mettez en service. Si la plage est active ailleurs, deux annonces simultanées « could potentially create BGP routing instability or traffic loss » (traduction : « pourraient créer une instabilité du routage BGP ou une perte de trafic »). Mettez-la d'abord en service dans la région (Commission, puis l'option limitée à la région, dans le portail, ou -NoInternetAdvertise dans PowerShell), testez, retirez l'ancienne annonce, puis mettez-la en service à l'échelle mondiale :

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

La plage est partiellement annoncée pendant l'état Commissioning, d'abord depuis la région, puis depuis le réseau de Microsoft sous AS8075, jusqu'à ce qu'elle soit Commissioned.

Les erreurs qui coûtent une journée

• Le certificat dans descr. Pour le RIPE NCC, Microsoft dit remarks, alors qu'AWS lit descr et explicitement pas remarks : un bloc qui passe d'un cloud à l'autre demande donc de modifier son objet.
• Une date qui ne correspond pas. La date du message signé est la date d'expiration du ROA, au format yyyymmdd ; à défaut, Microsoft dit de choisir la date jusqu'à laquelle vous voulez que la plage soit annoncée.
• Un ROA avec la mauvaise longueur. Un écart avec le préfixe que vous provisionnez échoue en InvalidPrefixLengthInROA.
• Partir dans le mauvais ordre. Supprimez chaque public IP prefix dérivé, puis retirez la plage du service (3 à 4 heures) avant de modifier ou de supprimer le ROA. Sinon, Microsoft continue d'annoncer une plage qu'il n'est plus autorisé à annoncer.

Si vous louez le bloc

L'obstacle est la règle de Microsoft : la plage « must be owned by you and registered under your name » (traduction : « doit vous appartenir et être enregistrée à votre nom »). Un bloc enregistré seulement au nom du bailleur ne la remplit pas telle qu'elle est écrite, et Microsoft ne dit pas si une attribution à votre nom dans l'allocation du titulaire compte : interrogez le titulaire et Microsoft avant de signer. Le titulaire crée ensuite le ROA pour AS8075 et ajoute votre certificat aux remarks de l'objet. Le DNS inverse dépend aussi du titulaire : Azure ne le sert que depuis une zone inverse que vous hébergez dans Azure DNS, et que le titulaire vous délègue. Aucune lettre d'autorisation n'est nécessaire.

La place de RTM Networks

Nous louons des /24 et plus grands depuis notre propre espace d'adresses RIPE NCC, et vendons des blocs dans les régions du RIPE NCC, de l'ARIN et de l'APNIC. Pour un espace loué chez nous, nous enregistrons l'attribution à votre organisation, créons le ROA pour AS8075 et ajoutons votre certificat à l'objet du registre (louer de l'IPv4). Si Microsoft veut plus qu'une attribution à votre nom, acheter le bloc règle la question (acheter de l'IPv4). Si vous n'êtes pas vous-même LIR, nous parrainons de l'espace PI et legacy et des numéros d'AS (parrainage). Pour moins de 256 adresses sur une VM Azure, nous annonçons un bloc et le livrons par WireGuard, puisqu'Azure bloque GRE, dans toute taille jusqu'à une seule adresse (tunnels WireGuard). Autres fournisseurs : guides BYOIP.