BYOIP no Azure: traga os seus próprios endereços IPv4 como custom IP prefix

Prova que o intervalo é seu com um ROA que indica o ASN da Microsoft e um certificado no seu registo WHOIS/RDAP, depois aprovisiona-o e deriva dele public IP prefixes e endereços.

Este guia segue o modelo unificado, para um intervalo usado numa só região, através da Azure CLI. Um intervalo não pode passar para o modelo global/regional, um pai com filhos regionais, sem ser integrado de novo.

O que o Azure aceita

Segundo a documentação da Microsoft, no dia em que a consultámos:

• Tamanho. Um prefixo unificado "must be between /21 and /24" (tradução: «tem de estar entre /21 e /24»). Um pai global também vai de /21 a /24, com filhos regionais de /22 a /26.
• Registo e nome. O intervalo "must be owned by you and registered under your name" (tradução: «tem de lhe pertencer e estar registado em seu nome») num Registo Regional da Internet, entre eles a ARIN, o RIPE NCC e a APNIC. Nada sobre o estatuto PA, PI ou legacy.
• Quem origina. A Microsoft, sob AS8075, ou AS8070 para a US Gov Cloud. As páginas de BYOIP da Microsoft não documentam nenhuma opção para o seu próprio ASN. O comando CLI do passo 1, az network custom-ip prefix create, lista de facto um parâmetro --asn, descrito apenas como "The ASN for CIDR advertising" (tradução: «O ASN para o anúncio do CIDR»), por isso pergunte à Microsoft antes de contar com ele.
• Regiões. Uma região por prefixo, e cinco prefixos por região por defeito, mais a pedido.
• Preço. "There's no charge to provision or use custom IP prefixes" (tradução: «Não há qualquer cobrança pelo aprovisionamento ou pela utilização de custom IP prefixes»), nem pelos public IP prefixes e endereços deles derivados. O tráfego é faturado às tarifas de saída para a Internet.
• Prazo. Cerca de 30 minutos para aprovisionar e três a quatro horas para comissionar globalmente.
• Limites. Sem Internet Routing Preference, Global Tier, ExpressRoute Microsoft peering nem IP públicos Standard v2. O DNS inverso funciona a partir das suas próprias zonas no Azure DNS, a Windows Server Activation pode demorar até uma semana, e um intervalo aprovisionado não pode mudar de subscrição.

Antes de começar

Um ROA para AS8075, com o comprimento do prefixo exatamente como a Microsoft o vai anunciar e uma data de expiração que cubra o tempo durante o qual o quer anunciado (RPKI e ROA). Conte com pelo menos 24 horas para que a Microsoft o veja. A Microsoft recomenda também um ROA para qualquer ASN que anuncie hoje o intervalo.

Um par de chaves e um certificado autoassinado, gerados com o OpenSSL:

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

O certificado no registo WHOIS/RDAP do prefixo, incluindo os marcadores BEGIN e END, sem espaços nem quebras de linha:

Uma mensagem de autorização assinada: o ID da sua subscrição, o prefixo e a data de expiração do ROA, por esta ordem:

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")

A Microsoft não pede nenhuma Letter of Authorization nem nenhum objeto route.

Passo a passo

01Aprovisione o intervalo, num resource group existente. Numa região com availability zones, torne-o redundante entre zonas ou fixe-o numa 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"

02Aguarde o estado Provisioned. O commissionedState devolvido por az network custom-ip prefix show passa de Provisioning para Provisioned. Um ValidationFailed logo no início significa que o ROA, o certificado ou a mensagem não passaram na verificação; o campo FailedReason diz qual.

03Derive endereços. Crie um public IP prefix a partir do intervalo, depois endereços Standard SKU a partir dele, e associe-os a VM ou load balancers; ainda não são anunciados.

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

04Comissione. Se o intervalo estiver ativo noutro lado, dois anúncios em simultâneo "could potentially create BGP routing instability or traffic loss" (tradução: «poderiam criar instabilidade no encaminhamento BGP ou perda de tráfego»). Comissione-o primeiro dentro da região (Commission e depois a opção só da região, no portal, ou -NoInternetAdvertise no PowerShell), teste, retire o anúncio antigo e depois comissione-o globalmente:

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

O intervalo fica parcialmente anunciado enquanto está em Commissioning, primeiro a partir da região, depois a partir da rede da Microsoft sob AS8075, até ficar Commissioned.

Erros que custam um dia

• O certificado em descr. No RIPE NCC, a Microsoft diz remarks, enquanto a AWS lê descr e explicitamente não remarks, por isso um bloco que passa de uma cloud para a outra obriga a alterar o registo.
• Uma data que não coincide. A data na mensagem assinada é a data de expiração do ROA, no formato yyyymmdd; se não houver nenhuma, a Microsoft diz para escolher a data até à qual quer o intervalo anunciado.
• Um ROA com o comprimento errado. Uma diferença em relação ao prefixo que aprovisiona falha como InvalidPrefixLengthInROA.
• Sair pela ordem errada. Elimine todos os public IP prefixes derivados e depois descomissione o intervalo (três a quatro horas) antes de alterar ou eliminar o ROA. Caso contrário, a Microsoft continua a anunciar um intervalo que já não está autorizada a anunciar.

Se alugar o bloco

O obstáculo é a regra da Microsoft: o intervalo "must be owned by you and registered under your name" (tradução: «tem de lhe pertencer e estar registado em seu nome»). Um bloco registado apenas em nome do locador não cumpre isso tal como está escrito, e a Microsoft não diz se uma atribuição a si dentro da alocação do titular conta, por isso pergunte ao titular e à Microsoft antes de assinar. O titular cria então o ROA para AS8075 e acrescenta o seu certificado aos remarks do registo. O DNS inverso também precisa do titular: o Azure só o serve a partir de uma zona inversa alojada por si no Azure DNS, que o titular lhe delega. Não é necessária nenhuma Letter of Authorization.

Onde entra a RTM Networks

Alugamos /24 e maiores a partir do nosso próprio espaço de endereçamento do RIPE NCC, e vendemos blocos nas regiões RIPE NCC, ARIN e APNIC. No espaço que lhe alugamos, registamos a atribuição à sua organização, criamos o ROA para AS8075 e acrescentamos o seu certificado ao registo (alugar IPv4). Se a Microsoft quiser mais do que uma atribuição em seu nome, comprar o bloco resolve a questão (comprar IPv4). Se não tiver o seu próprio LIR, patrocinamos espaço PI e legacy e números AS (patrocínio). Para menos de 256 endereços numa VM no Azure, anunciamos um bloco e entregamo-lo por WireGuard, já que o Azure bloqueia o GRE, em qualquer tamanho até um único endereço (túneis WireGuard). Outros fornecedores: guias BYOIP.