BYOIP na AWS: traga os seus próprios endereços IPv4 para o EC2

Prova que controla o intervalo com um certificado no respetivo registo e um ROA que indica os ASN da AWS, aprovisiona-o num pool de endereços e atribui a partir dele endereços Elastic IP tal como faria com os da própria AWS. Os endereços que traz não pagam a cobrança horária do IPv4 público.

Este guia cobre o EC2 através da AWS CLI. O mesmo intervalo também pode ir para o AWS Global Accelerator, que tem o seu próprio processo, ou passar pelo VPC IP Address Manager (IPAM), que acrescenta uma forma baseada em DNS de provar o controlo e a opção de anunciar a partir do seu próprio ASN.

O que a AWS aceita

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

• Tamanho. O intervalo IPv4 mais específico que pode trazer é um /24.
• Registo. ARIN, RIPE NCC ou APNIC, e registado em nome de uma empresa ou instituição, nunca de uma pessoa.
• Historial. A AWS pode verificar a reputação do intervalo e rejeitar um com endereços de mau historial (manter um bloco limpo).
• Espaço legacy é aceite, mas continua a precisar de um ROA.
• Uma Região de cada vez por intervalo, e cinco intervalos por Região por defeito; o AWS Support pode aumentar esse limite.
• Onde. Todas as Regiões comerciais exceto as Regiões da China, e uma lista de Local Zones.
• Não mexa no registo de encaminhamento. A AWS atualiza ela própria o RADb, e uma alteração manual que inclua o ASN da AWS faz falhar o aprovisionamento.

Antes de começar

Um ROA para os ASN da AWS. Tem de autorizar AS16509 e AS14618, e qualquer ASN que anuncie hoje o intervalo, com o comprimento máximo igual ao tamanho do intervalo que traz. Nas regiões AWS GovCloud (US) o ROA indica antes AS8987, e na AWS European Sovereign Cloud AS16509 e AS214101; através do IPAM, defina-o como /24 para poder dividir o bloco. Se estiver a mudar o intervalo da sua própria rede, crie primeiro o ROA para o seu ASN atual, para que nada do que hoje funciona passe a inválido (RPKI e ROA). Um ROA pode demorar até 24 horas a chegar à AWS.

Um par de chaves e um certificado, gerados com o OpenSSL 1.0.2 ou posterior:

openssl genpkey -aes256 -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private-key.pem
openssl req -new -x509 -key private-key.pem -days 365 | tr -d "\n" > certificate.pem

O certificado no registo, numa só linha, incluindo os marcadores BEGIN e END. O sítio depende do registo, e o campo importa:

Pode retirar o certificado depois de o aprovisionamento terminar.

Passo a passo

01Assine a mensagem de autorização. A mensagem indica a sua conta, o intervalo e uma data de expiração:

text_message="1|aws|123456789012|203.0.113.0/24|20261231|SHA256|RSAPSS"
signed_message=$(echo -n $text_message | openssl dgst -sha256 -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -sign private-key.pem -keyform PEM | openssl base64 | tr -- '+=/' '-_~' | tr -d "\n")

02Aprovisione o intervalo na Região onde o vai usar:

aws ec2 provision-byoip-cidr --cidr 203.0.113.0/24 \
  --cidr-authorization-context Message="$text_message",Signature="$signed_message" \
  --region eu-central-1

03Aguarde. O estado passa de pending-provision para provisioned. A AWS diz que a maioria dos intervalos fica concluída em duas horas e que alguns demoram até uma semana; aws ec2 describe-byoip-cidrs --max-results 5 --region eu-central-1 mostra em que ponto está.

04Prepare e depois mude. Para reduzir o tempo de indisponibilidade, atribua endereços Elastic IP a partir do novo pool e associe-os antes de o intervalo ser anunciado. aws ec2 describe-public-ipv4-pools dá o ID do pool, e aws ec2 allocate-address --public-ipv4-pool <pool-id> retira dele um endereço.

05Anuncie. Deixe de anunciar o intervalo em qualquer outro lado e depois:

aws ec2 advertise-byoip-cidr --cidr 203.0.113.0/24 --region eu-central-1

A AWS recomenda retirar primeiro o intervalo dos outros locais; enquanto outra pessoa o anunciar, a AWS não pode garantir que o tráfego para ele chegue à sua rede. Tem de anunciar exatamente o intervalo que aprovisionou, nunca uma parte dele.

06Verifique do exterior. whois -r -h whois.ripe.net 203.0.113.0/24 | grep descr deve mostrar o certificado, e o validador do RIPEstat deve considerar o intervalo válido para AS16509: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=16509&prefix=203.0.113.0/24".

Erros que custam um dia

• O certificado no campo errado. No RIPE NCC, a AWS lê descr e explicitamente não remarks. O Azure quer o contrário, por isso um bloco que passa de uma cloud para a outra obriga a alterar o registo.
• Um ROA com o comprimento máximo errado. A AWS exige que seja igual ao tamanho do intervalo que traz, ou /24 através do IPAM. Um comprimento máximo mais específico do que o intervalo que traz convida a sequestros de subprefixos, e a AWS reserva-se o direito de deixar de anunciar um intervalo cujos ROA não sigam as suas regras.
• Anunciar parte do intervalo. A AWS anuncia exatamente o que aprovisionou. Para usar um intervalo mais pequeno, desaprovisione e aprovisione de novo.
• Duas redes a anunciar ao mesmo tempo. O tráfego divide-se entre elas, e a AWS não resolve o problema.

O seu próprio ASN

Através do VPC IPAM, a AWS pode anunciar o seu intervalo a partir do seu próprio ASN em vez do dela. Acrescenta o mesmo certificado ao registo do seu ASN (no RIPE NCC, como uma linha descr no aut-num), cria um segundo ROA que indica o seu ASN, e a AWS recomenda um objeto ASPA que liste AS16509 e AS14618 como os seus fornecedores; sem eles, as rotas que a AWS propaga por si falham a validação ASPA. Pode voltar a pôr a origem no ASN da AWS a qualquer momento, e no seu no máximo uma vez por hora.

Se alugar o bloco

O espaço alugado funciona, desde que o registo o mostre detido por uma organização. O titular trata do lado do registo: o certificado no registo inetnum, que só o maintainer do titular pode editar, e o ROA para AS16509 e AS14618. O resto faz a partir da sua conta AWS.

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, acrescentamos o seu certificado AWS ao registo e criamos o ROA para os ASN da AWS, pelo que o aprovisionamento é o único passo que lhe resta (alugar IPv4). Se precisar de menos de 256 endereços numa instância EC2, podemos entregá-los por um túnel (túneis GRE e WireGuard). Como soma a cobrança horária do IPv4, e quando compensa trazer o seu: o custo real do IPv4 na cloud. Outros fornecedores: guias BYOIP.