BYOIP hos Azure: tag dine egne IPv4-adresser med som custom IP prefix

Du beviser, at intervallet er dit, med en ROA, der nævner Microsofts ASN, og et certifikat i dets WHOIS/RDAP-post, klargør det og afleder public IP prefixes og adresser fra det.

Denne guide følger den samlede model (unified) for et interval, der bruges i én region, via Azure CLI. Et interval kan ikke skifte til den globale/regionale model, en forælder med regionale børn, uden at blive taget ind igen.

Hvad Azure accepterer

Fra Microsofts dokumentation, den dag vi tjekkede:

• Størrelse. Et unified præfiks “must be between /21 and /24” (oversættelse: “skal være mellem /21 og /24”). En global forælder er også /21 til /24, med regionale børn på /22 til /26.
• Register og navn. Intervallet “must be owned by you and registered under your name” (oversættelse: “skal ejes af dig og være registreret i dit navn”) hos et regionalt internetregister, blandt dem ARIN, RIPE NCC og APNIC. Intet om PA-, PI- eller legacy-status.
• Hvem der er origin. Microsoft, under AS8075, eller AS8070 for US Gov Cloud. Microsofts BYOIP-sider dokumenterer ingen mulighed for dit eget ASN. CLI-kommandoen i trin 1, az network custom-ip prefix create, angiver ganske vist en --asn-parameter, kun beskrevet som “The ASN for CIDR advertising” (oversættelse: “ASN'et til annoncering af CIDR”), så spørg Microsoft, før du regner med den.
• Regioner. Én region pr. præfiks og fem præfikser pr. region som standard, flere på anmodning.
• Pris. “There's no charge to provision or use custom IP prefixes” (oversættelse: “Det koster intet at klargøre eller bruge custom IP prefixes”), heller ikke for de public IP prefixes og adresser, der afledes af dem. Trafik faktureres til priserne for internet-egress.
• Tid. Cirka 30 minutter til klargøring og tre til fire timer til global idriftsættelse.
• Begrænsninger. Ingen Internet Routing Preference, Global Tier, ExpressRoute Microsoft peering eller Standard v2 public IPs. Reverse DNS kører fra dine egne zoner i Azure DNS, Windows Server Activation kan tage op til en uge, og et klargjort interval kan ikke skifte subscription.

Før du går i gang

En ROA for AS8075, med præfikslængden præcis som Microsoft vil annoncere den og en udløbsdato, der dækker den tid, du vil have den annonceret (RPKI og ROA'er). Regn med mindst 24 timer, før Microsoft ser den. Microsoft anbefaler også en ROA for ethvert ASN, der annoncerer intervallet i dag.

Et nøglepar og et selvsigneret certifikat, lavet med OpenSSL:

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

Certifikatet i WHOIS/RDAP-posten for præfikset, inklusive BEGIN- og END-markeringerne, uden mellemrum eller linjeskift:

En signeret autorisationsbesked: dit subscription-ID, præfikset og ROA'ens udløbsdato, i den rækkefølge:

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 beder hverken om en Letter of Authorization eller et route-objekt.

Trin for trin

01Klargør intervallet i en eksisterende resource group. I en region med availability zones gør du det zoneredundant eller fastlåser det til én 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"

02Vent på Provisioned. Den commissionedState, som az network custom-ip prefix show returnerer, går fra Provisioning til Provisioned. En tidlig ValidationFailed betyder, at ROA'en, certifikatet eller beskeden ikke kunne godkendes; feltet FailedReason siger hvilken.

03Aflede adresser. Opret et public IP prefix fra intervallet, derefter Standard SKU-adresser fra det, og tilknyt dem til VM'er eller load balancere; de annonceres endnu ikke.

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

04Idriftsæt. Er intervallet aktivt andetsteds, “could potentially create BGP routing instability or traffic loss” (oversættelse: “kan to annonceringer på samme tid potentielt skabe ustabil BGP-routing eller tab af trafik”). Idriftsæt det først inden for regionen (Commission og så muligheden kun for regionen i portalen, eller -NoInternetAdvertise i PowerShell), test, træk den gamle annoncering tilbage, og idriftsæt det så globalt:

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

Intervallet er delvist annonceret, mens det står på Commissioning, først fra regionen, så fra Microsofts netværk under AS8075, indtil det er Commissioned.

Fejl, der koster en dag

• Certifikatet i descr. For RIPE NCC siger Microsoft remarks, mens AWS læser descr og udtrykkeligt ikke remarks, så en blok, der flytter mellem de to clouds, kræver, at posten ændres.
• En dato, der ikke passer. Datoen i den signerede besked er ROA'ens udløbsdato, som yyyymmdd; har den ingen, siger Microsoft, at du skal vælge den dato, indtil hvilken du vil have intervallet annonceret.
• En ROA med den forkerte længde. Passer den ikke til det præfiks, du klargør, fejler det som InvalidPrefixLengthInROA.
• At gå i den forkerte rækkefølge. Slet alle afledte public IP prefixes, og tag så intervallet ud af drift (tre til fire timer), før du ændrer eller sletter ROA'en. Ellers bliver Microsoft ved med at annoncere et interval, som Microsoft ikke længere har tilladelse til at annoncere.

Hvis du lejer blokken

Microsofts regel er forhindringen: intervallet “must be owned by you and registered under your name” (oversættelse: “skal ejes af dig og være registreret i dit navn”). En blok, der kun er registreret til udlejeren, opfylder ikke det, som det står, og Microsoft siger ikke, om en assignment til dig inden for indehaverens allokering tæller, så spørg indehaveren og Microsoft, før du skriver under. Indehaveren opretter så ROA'en for AS8075 og tilføjer dit certifikat i postens remarks. Reverse DNS kræver også indehaveren: Azure leverer det kun fra en reverse zone, du hoster i Azure DNS, og som indehaveren delegerer til dig. Der kræves ingen Letter of Authorization.

Hvor RTM Networks passer ind

Vi lejer /24'er og større ud fra vores egne RIPE NCC-adresser og sælger blokke i RIPE NCC-, ARIN- og APNIC-regionerne. For adresser, du lejer af os, registrerer vi assignmenten til din organisation, opretter ROA'en for AS8075 og tilføjer dit certifikat i registerposten (lej IPv4). Vil Microsoft have mere end en assignment i dit navn, løser et køb af blokken det (køb IPv4). Driver du ikke din egen LIR, sponsorerer vi PI- og legacy-adresser og AS-numre (sponsorat). Til færre end 256 adresser på en Azure-VM annoncerer vi en blok og leverer den over WireGuard, da Azure blokerer GRE, i enhver størrelse ned til en enkelt adresse (WireGuard-tunneler). Andre udbydere: BYOIP-guider.