BYOIP en Azure: trae tus propias direcciones IPv4 como custom IP prefix

Demuestras que el rango es tuyo con un ROA que nombra el ASN de Microsoft y un certificado en su registro WHOIS/RDAP, y luego lo aprovisionas y derivas de él public IP prefixes y direcciones.

Esta guía sigue el modelo unificado, para un rango usado en una sola región, mediante la Azure CLI. Un rango no puede pasar al modelo global/regional, un padre con hijos regionales, sin volver a incorporarlo.

Qué acepta Azure

Según la documentación de Microsoft, el día que la consultamos:

• Tamaño. Un prefijo unificado «must be between /21 and /24» (traducción: «debe estar entre /21 y /24»). Un padre global también va de /21 a /24, con hijos regionales de /22 a /26.
• Registro y titular. El rango «must be owned by you and registered under your name» (traducción: «debe ser tuyo y estar registrado a tu nombre») en un Registro Regional de Internet, entre ellos ARIN, el RIPE NCC y APNIC. Nada sobre el estado PA, PI o legacy.
• Quién lo origina. Microsoft, con AS8075, o AS8070 para el US Gov Cloud. Las páginas de BYOIP de Microsoft no documentan ninguna opción para tu propio ASN. El comando de la CLI del paso 1, az network custom-ip prefix create, sí incluye un parámetro --asn, descrito solo como «The ASN for CIDR advertising» (traducción: «El ASN para anunciar el CIDR»), así que pregunta a Microsoft antes de contar con él.
• Regiones. Una región por prefijo, y cinco prefijos por región por defecto, más bajo petición.
• Precio. «There's no charge to provision or use custom IP prefixes» (traducción: «No se cobra por aprovisionar ni usar custom IP prefixes»), ni por los public IP prefixes y direcciones derivados de ellos. El tráfico se factura a las tarifas de salida a internet.
• Plazo. Unos 30 minutos para aprovisionar y de tres a cuatro horas para ponerlo en servicio a nivel global.
• Límites. Sin Internet Routing Preference, Global Tier, ExpressRoute Microsoft peering ni IP públicas Standard v2. El DNS inverso se sirve desde tus propias zonas en Azure DNS, la activación de Windows Server puede tardar hasta una semana, y un rango aprovisionado no puede cambiar de suscripción.

Antes de empezar

Un ROA para AS8075, con la longitud de prefijo exactamente como la anunciará Microsoft y una fecha de caducidad que cubra el tiempo que quieras tenerlo anunciado (RPKI y ROA). Cuenta con al menos 24 horas para que Microsoft lo vea. Microsoft también recomienda un ROA para cualquier ASN que anuncie hoy el rango.

Un par de claves y un certificado autofirmado, generados con OpenSSL:

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

El certificado en el registro WHOIS/RDAP del prefijo, con los marcadores BEGIN y END, sin espacios ni saltos de línea:

Un mensaje de autorización firmado: el ID de tu suscripción, el prefijo y la fecha de caducidad del ROA, en ese orden:

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 no pide Letter of Authorization ni objeto route.

Paso a paso

01Aprovisiona el rango, en un grupo de recursos existente. En una región con zonas de disponibilidad, hazlo redundante entre zonas o fíjalo 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"

02Espera a Provisioned. El commissionedState que devuelve az network custom-ip prefix show pasa de Provisioning a Provisioned. Un ValidationFailed temprano significa que el ROA, el certificado o el mensaje no superaron la comprobación; el campo FailedReason dice cuál.

03Deriva direcciones. Crea un public IP prefix a partir del rango, luego direcciones Standard SKU de él, y asócialas a VM o balanceadores de carga; todavía no se anuncian.

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

04Ponlo en servicio. Si el rango está activo en otro sitio, dos anuncios a la vez «could potentially create BGP routing instability or traffic loss» (traducción: «podrían provocar inestabilidad del enrutamiento BGP o pérdida de tráfico»). Ponlo primero en servicio dentro de la región (Commission y luego la opción solo para la región, en el portal, o -NoInternetAdvertise en PowerShell), prueba, retira el anuncio antiguo y luego ponlo en servicio a nivel global:

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

El rango se anuncia en parte mientras está en Commissioning, primero desde la región y luego desde la red de Microsoft con AS8075, hasta que queda Commissioned.

Errores que cuestan un día

• El certificado en descr. Para el RIPE NCC, Microsoft dice remarks, mientras que AWS lee descr y expresamente no remarks, así que un bloque que pasa de una nube a otra necesita cambiar su registro.
• Una fecha que no coincide. La fecha del mensaje firmado es la fecha de caducidad del ROA, como yyyymmdd; si no tiene, Microsoft dice que elijas la fecha hasta la que quieres que se anuncie el rango.
• Un ROA con la longitud equivocada. Si no coincide con el prefijo que aprovisionas, falla como InvalidPrefixLengthInROA.
• Salir en el orden equivocado. Elimina todos los public IP prefixes derivados y luego retira el rango del servicio (de tres a cuatro horas) antes de cambiar o eliminar el ROA. Si no, Microsoft sigue anunciando un rango que ya no está autorizado a anunciar.

Si alquilas el bloque

El obstáculo es la regla de Microsoft: el rango «must be owned by you and registered under your name» (traducción: «debe ser tuyo y estar registrado a tu nombre»). Un bloque registrado solo a nombre del arrendador no lo cumple tal como está escrito, y Microsoft no dice si cuenta una asignación a tu nombre dentro de la asignación del titular, así que pregunta al titular y a Microsoft antes de firmar. Después, el titular crea el ROA para AS8075 y añade tu certificado a los remarks del registro. El DNS inverso también necesita al titular: Azure solo lo sirve desde una zona inversa que alojas en Azure DNS, y que el titular te delega. No hace falta Letter of Authorization.

Dónde encaja RTM Networks

Alquilamos /24 y mayores de nuestro propio espacio de direcciones del RIPE NCC, y vendemos bloques en las regiones RIPE NCC, ARIN y APNIC. Para el espacio que nos alquilas, registramos la asignación a tu organización, creamos el ROA para AS8075 y añadimos tu certificado al registro (alquilar IPv4). Si Microsoft quiere algo más que una asignación a tu nombre, comprar el bloque lo resuelve (comprar IPv4). Si no tienes tu propio LIR, patrocinamos espacio PI y legacy y números AS (patrocinio de PI y ASN). Para menos de 256 direcciones en una VM de Azure, anunciamos un bloque y lo entregamos por WireGuard, ya que Azure bloquea GRE, en cualquier tamaño hasta una sola dirección (túneles WireGuard). Otros proveedores: guías BYOIP.