Azure PowerShell を使用してカスタム IPv4 アドレス プレフィックスを作成する

カスタム IPv4 アドレス プレフィックスを使用すると、独自の IPv4 範囲を Microsoft に持ち込み、Azure サブスクリプションに関連付けることができます。 その範囲の所有権は引き続きユーザーが保持しますが、Microsoft はそれをインターネットにアドバタイズすることを許可されます。 カスタム IP アドレス プレフィックスは、顧客所有 IP アドレスの連続したブロックを表す、リージョンのリソースとして機能します。

この記事の手順では、次の手順について詳しく説明します。

  • プロビジョニングする範囲を準備する

  • IP 割り当ての範囲をプロビジョニングする

  • Microsoft によってアドバタイズされる範囲を有効にする

前提条件

  • アクティブなサブスクリプションが含まれる Azure アカウント。 無料でアカウントを作成できます
  • ローカルにインストールされた Azure PowerShell または Azure Cloud Shell。
  • Azure PowerShell にサインインし、この機能を使用するサブスクリプションが選択されていることを確認します。 詳細については、「Azure PowerShell を使用してサインインする」を参照してください。
  • Az.Network モジュールが 5.1.1 以降であることを確認します。 インストールされているモジュールを確認するには、コマンドGet-InstalledModule -Name "Az.Network"を使用します。 モジュールの更新が必要な場合は、必要に応じて Update-Module -Name "Az.Network" コマンドを使用します。
  • Azure でプロビジョニングする顧客所有の IPv4 範囲。
    • この例では、サンプルの顧客範囲 (1.2.3.0/24) が使用されています。 この範囲は Azure では検証されません。 例の範囲を実際の範囲で置き換えてください。

PowerShell をインストールしてローカルで使用する場合、この記事では Azure PowerShell モジュール バージョン 5.4.1 以降が必要になります。 インストールされているバージョンを確認するには、Get-Module -ListAvailable Az を実行します。 アップグレードする必要がある場合は、Azure PowerShell モジュールのインストールに関するページを参照してください。 PowerShell をローカルで実行している場合、Connect-AzAccount を実行して Azure との接続を作成することも必要です。

Note

プロビジョニング プロセス中に発生した問題については、カスタム IP プレフィックスのトラブルシューティングに関するページを参照してください。

プロビジョニング前の手順

Azure BYOIP 機能を利用するには、IPv4 アドレス範囲をプロビジョニングする前に次の手順を実行する必要があります。

要件とプレフィックスの準備

  • アドレス範囲は、ユーザーが所有し、5 つの主要な地域インターネット レジストリのいずれかとともにユーザー自身の名前で登録する必要があります:

  • インターネット サービス プロバイダーによって受け入れられるためには、アドレス範囲が /24 より小さくないことが必要です。

  • お客様は、Microsoft によるアドレス範囲のアドバタイズを承認する Route Origin Authorization (ROA) ドキュメントに、適切なルーティング インターネット レジストリ (RIR) の Web サイトまたはその API を使って入力する必要があります。 RIR では、RIR のリソース公開キー基盤 (RPKI) による ROA のデジタル署名が求められます。

    この ROA について:

    • パブリック クラウドの場合、オリジン AS は 8075 と示されている必要があります。 (範囲が US Gov クラウドに組み込まれる場合、オリジン AS は 8070 と示されている必要があります。)

    • 有効期間の終了日 (有効期限) は、プレフィックスが Microsoft によってアドバタイズされる日時を考慮したものである必要があります。 一部の RIR では、有効期間の終了日がオプションとして表示されないか、日付が自動的に選択されます。

    • プレフィックスの長さは、Microsoft がアドバタイズできるプレフィックスと正確に一致する必要があります。 たとえば、1.2.3.0/24 と 2.3.4.0/23 を Microsoft に持ち込むことを予定している場合は、両方とも名前を示す必要があります。

    • ROA が完了して提出された後、Microsoft で利用できるようになるまでに少なくとも 24 時間みておいてください。そこで、プロビジョニング プロセスの一部としてその信頼性と正確性を判別するために検証されます。

注意

また、移行中の問題を回避するために、範囲をアドバタイズする既存の ASN に対して ROA を作成することもお勧めします。

重要

Microsoft は、指定した日付以降にその範囲の広告を停止しませんが、外部の通信事業者が広告を受け入れないように、元の有効期限が過ぎた場合は個別にフォローアップ ROA を作成することを強くお勧めします。

証明書の準備

Microsoft がプレフィックスを顧客サブスクリプションに関連付けることを承認するには、パブリック証明書を署名付きメッセージと比較することが必要です。

次の手順では、サンプルの顧客範囲 (1.2.3.0/24) をパブリック クラウドへのプロビジョニングのために準備するときに必要な手順を示します。

Note

OpenSSL がインストールされている PowerShell で次のコマンドを実行します。

  1. プレフィックスの Whois/RDAP レコードに追加する自己署名 X509 証明書を作成する必要があります。 RDAP の詳細については、ARINRIPEAPNICAFRINIC のサイトを参照してください。

    OpenSSL ツールキットを使用する例を次に示します。 次のコマンドでは、RSA キー ペアを生成し、6 か月で期限切れになるキー ペアを使用して X509 証明書を作成します。

    ./openssl genrsa -out byoipprivate.key 2048
    Set-Content -Path byoippublickey.cer (./openssl req -new -x509 -key byoipprivate.key -days 180) -NoNewline
    
  2. 証明書が作成されたら、プレフィックスの Whois/RDAP レコードのパブリック コメント セクションを更新します。 コピーするために BEGIN と END のヘッダーおよびフッターとダッシュを含めて表示するには、コマンド cat byoippublickey.cer を使用します。この手順は、ルーティング インターネット レジストリを介して実行できます。

    各レジストリでの手順は次のとおりです。

    • ARIN - プレフィックス レコードの "Comments" を編集します。

    • RIPE - inetnum レコードの "Remarks" を編集します。

    • APNIC - MyAPNIC を使用して inetnum レコードの "Remarks" を編集します。

    • AFRINIC - MyAFRINIC を使って inetnum レコードの "Remarks" を編集します。

    • LACNIC レジストリの範囲については、Microsoft に対してサポート チケットを作成してください。

    パブリック コメントを入力すると、Whois/RDAP レコードは次の例のようになります。 スペースやキャリッジ リターンがないことを確認します。 すべてのダッシュを含めます。

    Screenshot of example certificate comment

  3. Microsoft に渡されるメッセージを作成するには、プレフィックスとサブスクリプションに関する関連情報を含む文字列を作成します。 上記の手順で生成されたキー ペアを使用して、このメッセージに署名します。 次に示す形式を使用し、お使いのサブスクリプション ID、プロビジョニングするプレフィックス、ROA の有効期間と一致する有効期限に置き換えます。 形式がその順序になっていることを確認します。

    検証のために Microsoft に渡される署名付きメッセージを作成するには、次のコマンドを使用します。

    Note

    有効期間の終了日が元の ROA に含まれていない場合は、プレフィックスが Azure によってアドバタイズされる日時に対応する日付を選択します。

    $byoipauth="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|1.2.3.0/24|yyyymmdd"
    Set-Content -Path byoipauth.txt -Value $byoipauth -NoNewline
    ./openssl dgst -sha256 -sign byoipprivate.key -keyform PEM -out byoipauthsigned.txt byoipauth.txt
    $byoipauthsigned=(./openssl enc -base64 -in byoipauthsigned.txt) -join ''
    
  4. 署名済みメッセージの内容を表示するには、先ほど作成した署名済みメッセージから作成した変数を PowerShell プロンプトで入力し、Enter キーを押します。

    $byoipauthsigned
    dIlwFQmbo9ar2GaiWRlSEtDSZoH00I9BAPb2ZzdAV2A/XwzrUdz/85rNkXybXw457//gHNNB977CQvqtFxqqtDaiZd9bngZKYfjd203pLYRZ4GFJnQFsMPFSeePa8jIFwGJk6JV4reFqq0bglJ3955dVz0v09aDVqjj5UJx2l3gmyJEeU7PXv4wF2Fnk64T13NESMeQk0V+IaEOt1zXgA+0dTdTLr+ab56pR0RZIvDD+UKJ7rVE7nMlergLQdpCx1FoCTm/quY3aiSxndEw7aQDW15+rSpy+yxV1iCFIrUa/4WHQqP4LtNs3FATvLKbT4dBcBLpDhiMR+j9MgiJymA==
    

プロビジョニングの手順

次の手順では、米国西部 2 リージョンにサンプルの顧客範囲 (1.2.3.0/24) をプロビジョニングする方法を示します。

Note

クリーンアップまたは削除の手順は、リソースの性質上、このページには示されていません。 プロビジョニングしたカスタム IP プレフィックスの削除については、「カスタム IP プレフィックスの管理」を参照してください。

リソース グループを作成し、プレフィックスと承認メッセージを指定する

BYOIP 範囲をプロビジョニングするために、任意の場所にリソース グループを作成します。

$rg =@{
    Name = 'myResourceGroup'
    Location = 'WestUS2'
}
New-AzResourceGroup @rg

カスタム IP アドレスのプレフィックスをプロビジョニングする

次のコマンドは、指定したリージョンとリソース グループにカスタム IP プレフィックスを作成します。 構文エラーにならないように、CIDR 表記の正確なプレフィックスを文字列として指定します。 -AuthorizationMessage パラメーターについては、お使いのサブスクリプション ID、プロビジョニングするプレフィックス、ROA の有効期間と一致する有効期限に置き換えます。 形式がその順序になっていることを確認します。 証明書の準備のセクションで作成した変数 $byoipauthsigned-SignedMessage パラメーターに使用します。

$prefix =@{
    Name = 'myCustomIPPrefix'
    ResourceGroupName = 'myResourceGroup'
    Location = 'WestUS2'
    CIDR = '1.2.3.0/24'
    AuthorizationMessage = 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|1.2.3.0/24|yyyymmdd'
    SignedMessage = $byoipauthsigned
}
$myCustomIpPrefix = New-AzCustomIPPrefix @prefix -Zone 1,2,3

範囲が Azure IP デプロイ パイプラインにプッシュされます。 デプロイ プロセスは非同期です。 状態を確認するには、次のコマンドを実行します。

Get-AzCustomIpPrefix -ResourceId $myCustomIpPrefix.Id

サンプル出力を次に示します。わかりやすくするために一部のフィールドが削除されています。

Name              : myCustomIpPrefix
ResourceGroupName : myResourceGroup
Location          : westus2
Id                : /subscriptions/xxxx/resourceGroups/myResourceGroup/providers/Microsoft.Network/customIPPrefixes/MyCustomIPPrefix
Cidr              : 1.2.3.0/24
Zones             : {1, 2, 3}
CommissionedState : Provisioning

CommissionedState フィールドには、最初は範囲が Provisioning として表示され、その後 Provisioned になります。

Note

このプロビジョニング プロセスの推定所要時間は 30 分です。

重要

カスタム IP プレフィックスが Provisioned 状態になった後、子パブリック IP プレフィックスを作成できます。 これらのパブリック IP プレフィックスとパブリック IP アドレスは、ネットワーク リソースにアタッチできます。 例として、仮想マシンのネットワーク インターフェイスやロード バランサーのフロントエンドがあります。 IP はアドバタイズされないため、到達できません。 アクティブなプレフィックスの移行の詳細については、「カスタム IP プレフィックスの管理」を参照してください。

カスタム IP アドレス プレフィックスを委任する

カスタム IP プレフィックスが Provisioned 状態のときに次のコマンドでプレフィックスを更新し、Azure から範囲をアドバタイズするプロセスを開始します。

Update-AzCustomIpPrefix -ResourceId $myCustomIPPrefix.Id -Commission

前と同様に、操作は非同期です。 Get-AzCustomIpPrefix を使用して状態を取得します。 CommissionedState フィールドには、最初はプレフィックスが Commissioning として表示され、その後 Commissioned になります。 アドバタイズのロールアウトは二元的ではなく、範囲はまだ Commissioning のときにも部分的にアドバタイズされます。

Note

委任プロセスを完全に完了するための推定所要時間は 3 - 4 時間です。

重要

カスタム IP プレフィックスが Commissioned 状態に移行すると、範囲はローカル Azure リージョンから Microsoft にアドバタイズされ、自律システム番号 (ASN) 8075 の下にある Microsoft のワイド エリア ネットワークによってインターネットにグローバルにアドバタイズされます。 この同じ範囲を Microsoft 以外の場所からインターネットに同時にアドバタイズすると、BGP ルーティングが不安定になり、トラフィックが失われる可能性があります。 例として、お客様のオンプレミスの建物があります。 影響を回避するために、アクティブな範囲の移行はメンテナンス期間中に行うことを計画します。 さらに、リージョンの委任機能を利用して、カスタム IP プレフィックスをデプロイされている Azure リージョン内でのみアドバタイズされる状態にすることもできます。詳細については、「カスタム IP アドレス プレフィックス (BYOIP) を管理する」を参照してください。

次のステップ