User-Defined ルート (UDR) の計画と実装
Azure でカスタム またはユーザー定義 (静的) ルートを作成して、Azure の既定のシステム ルートをオーバーライドしたり、サブネットのルート テーブルにルートを追加したりすることができます。 Azure では、ルート テーブルを作成し、ルート テーブルを 0 個以上の仮想ネットワーク サブネットに関連付けます。 各サブネットには、0 個または 1 つのルート テーブルを関連付けることができます。 ルート テーブルに追加できるルートの最大数と、Azure サブスクリプションごとに作成できるユーザー定義ルート テーブルの最大数については、azure の制限 を参照してください。 ルート テーブルを作成してサブネットに関連付けると、テーブルのルートがサブネットの既定のルートと組み合わされます。 競合するルート割り当てがある場合、ユーザー定義ルートは既定のルートをオーバーライドします。
ユーザー定義ルートを作成するときは、次のネクストホップの種類を指定できます。
仮想アプライアンス: 仮想アプライアンスは、通常、ファイアウォールなどのネットワーク アプリケーションを実行する仮想マシンです。 仮想ネットワークにデプロイできる構成済みネットワーク仮想アプライアンスの詳細については、Azure Marketplace を参照してください。 仮想アプライアンスのホップの種類でルートを作成するときは、次ホップのIPアドレスも指定します。 IP アドレスは次のようになります。
- 仮想マシンに接続されているネットワーク インターフェイスのプライベート IP アドレス。 独自のアドレス以外のアドレスにネットワーク トラフィックを転送する仮想マシンに接続されているネットワーク インターフェイスでは、Azure の [IP 転送を有効にする] オプションが有効になっている必要があります。 この設定により、ネットワーク インターフェイスのソースと宛先の Azure のチェックが無効になります。 ネットワーク インターフェイス の IP 転送有効にする方法について説明します。 IP 転送の有効化は Azure の設定ですが、アプライアンスが Azure ネットワーク インターフェイスに割り当てられているプライベート IP アドレス間でトラフィックを転送するために、仮想マシンのオペレーティング システム内で IP 転送を有効にする必要がある場合もあります。 アプライアンスがトラフィックをパブリック IP アドレスにルーティングする必要がある場合は、トラフィックをプロキシするか、ソースのプライベート IP アドレスから独自のプライベート IP アドレスへのネットワーク アドレス変換 (NAT) を実行する必要があります。 Azure は、トラフィックをインターネットに送信する前に、パブリック IP アドレスへの NAT を実行します。 仮想マシン内で必要な設定を確認するには、オペレーティング システムまたはネットワーク アプリケーションのドキュメントを参照してください。 Azure の送信接続を理解するには、「送信接続について」を参照してください。
- Azure 内部ロード バランサーのプライベート IP アドレス。 ロード バランサーは、多くの場合、ネットワーク仮想アプライアンスの高可用性戦略の一部として使用されます。
- 仮想マシンに接続されているネットワーク インターフェイスのプライベート IP アドレス。 独自のアドレス以外のアドレスにネットワーク トラフィックを転送する仮想マシンに接続されているネットワーク インターフェイスでは、Azure の [IP 転送を有効にする] オプションが有効になっている必要があります。 この設定により、ネットワーク インターフェイスのソースと宛先の Azure のチェックが無効になります。 ネットワーク インターフェイス の IP 転送有効にする方法について説明します。 IP 転送の有効化は Azure の設定ですが、アプライアンスが Azure ネットワーク インターフェイスに割り当てられているプライベート IP アドレス間でトラフィックを転送するために、仮想マシンのオペレーティング システム内で IP 転送を有効にする必要がある場合もあります。 アプライアンスがトラフィックをパブリック IP アドレスにルーティングする必要がある場合は、トラフィックをプロキシするか、ソースのプライベート IP アドレスから独自のプライベート IP アドレスへのネットワーク アドレス変換 (NAT) を実行する必要があります。 Azure は、トラフィックをインターネットに送信する前に、パブリック IP アドレスへの NAT を実行します。 仮想マシン内で必要な設定を確認するには、オペレーティング システムまたはネットワーク アプリケーションのドキュメントを参照してください。 Azure の送信接続を理解するには、「送信接続について」を参照してください。
アドレス プレフィックスとして 0.0.0.0/0 を持つルートと、仮想アプライアンスの次ホップの種類を定義できます。 この構成により、アプライアンスはトラフィックを検査し、トラフィックを転送するか削除するかを決定できます。 0.0.0.0/0 アドレス プレフィックスを含むユーザー定義ルートを作成する場合は、最初に 0.0.0.0/0 アドレス プレフィックスを読み取ります。
- 仮想ネットワーク ゲートウェイ: 特定のアドレス プレフィックス宛てのトラフィックを仮想ネットワーク ゲートウェイにルーティングするタイミングを指定します。 仮想ネットワーク ゲートウェイは、VPN の種類で作成する必要があります。 ExpressRoute ではカスタム ルートに BGP を使用する必要があるため、ユーザー定義ルートで ExpressRoute の種類として作成された仮想ネットワーク ゲートウェイを指定することはできません。 VPN と ExpressRoute の接続が共存している場合も、仮想ネットワーク ゲートウェイを指定することはできません。 0.0.0.0/0 アドレス プレフィックス宛てのトラフィックをルート ベースの仮想ネットワーク ゲートウェイに転送するルートを定義できます。 オンプレミスには、トラフィックを検査し、トラフィックを転送するか削除するかを決定するデバイスがある場合があります。 0.0.0.0/0 アドレス プレフィックスのユーザー定義ルートを作成する場合は、最初に 0.0.0.0/0 アドレス プレフィックスをお読みください。 VPN 仮想ネットワーク ゲートウェイで BGP を有効にしている場合は、0.0.0.0/0 アドレス プレフィックスに対してユーザー定義ルートを構成する代わりに、BGP 経由で 0.0.0.0/0 プレフィックスを持つルートをアドバタイズできます。
- なし: トラフィックを宛先に転送するのではなく、アドレス プレフィックスにトラフィックをドロップするタイミングを指定します。 機能を完全に構成していない場合は、オプションのシステム ルートの一部に対して Azure で None が一覧表示されることがあります。 たとえば、次ホップの種類が仮想ネットワーク ゲートウェイまたは仮想アプライアンスである次ホップ IP アドレスとして [なし] が一覧表示されている場合は、デバイスが実行されていないか、完全に構成されていない可能性があります。 Azure は、次ホップの種類として None を使用して予約済みアドレス プレフィックスのシステムの既定のルートを作成します。
- 仮想ネットワーク: 仮想ネットワーク内の既定のルーティングをオーバーライドする場合は、仮想ネットワーク オプションを指定します。
- インターネット: アドレス プレフィックス宛てのトラフィックを明示的にインターネットにルーティングする場合、またはパブリック IP アドレスを使用して Azure サービス宛てのトラフィックを Azure バックボーン ネットワーク内に保持する場合は、インターネット オプションを指定します。 ルーティングの例 を参照してください。これは、仮想ネットワークホップの種類であるルートを作成する理由の例です。
ユーザー定義ルートの次ホップの種類として仮想ネットワーク ピアリングまたは VirtualNetworkServiceEndpoint を指定することはできません。 仮想ネットワーク ピアリングまたは VirtualNetworkServiceEndpoint 次ホップの種類を持つルートは、仮想ネットワーク ピアリングまたはサービス エンドポイントを構成するときに、Azure によってのみ作成されます。
ユーザー定義ルートのサービス タグ
明示的な IP 範囲ではなく、ユーザー定義ルートのアドレス プレフィックスとしてサービス タグを指定できるようになりました。 サービス タグは、特定の Azure サービスからの IP アドレス プレフィックスのグループを表します。 Microsoft は、サービス タグに含まれるアドレス プレフィックスを管理し、アドレスの変更に合じてサービス タグを自動的に更新します。 したがって、ユーザー定義ルートに対する頻繁な更新の複雑さを最小限に抑え、作成する必要があるルートの数を減らします。 現在、各ルート テーブルにサービス タグを使用して 25 個以下のルートを作成できます。 このリリースでは、コンテナーのルーティング シナリオでサービス タグを使用することもサポートされています。
完全一致
明示的な IP プレフィックスを持つルートとサービス タグを持つルートの間に正確なプレフィックスが一致する場合、システムは明示的なプレフィックスを持つルートを優先します。 サービス タグを持つ複数のルートに一致する IP プレフィックスがある場合、ルートは次の順序で評価されます。
- リージョン タグ (Storage.EastUS、AppService.AustraliaCentral など)
- 最上位レベルのタグ (Storage、AppService など)
- AzureCloud リージョン タグ (AzureCloud.canadacentral、AzureCloud.eastasia など)
- AzureCloud タグ
この機能を使用するには、ルート テーブル コマンドでアドレス プレフィックス パラメーターのサービス タグ名を指定します。 たとえば、PowerShell では、次を使用して、Azure Storage IP プレフィックスに送信されたトラフィックを仮想アプライアンスに転送する新しいルートを作成できます。
$param = @{ Name = 'StorageRoute' AddressPrefix = 'Storage' NextHopType = 'VirtualAppliance' NextHopIpAddress = '10.0.100.4' } New-AzRouteConfig @param
Azure CLI では同じコマンドが次のようになります。
az network route-table route create \ --resource-group MyResourceGroup \ --route-table-name MyRouteTable \ --name StorageRoute \ --address-prefix Storage \ --next-hop-type VirtualAppliance \ --next-hop-ip-address 10.0.100.4
Azure ツールにおけるネクストホップの種類
ネクスト ホップの種類として表示および参照される名前は、Azure portal とコマンド ライン ツール、および Resource Manager デプロイ モデルとクラシック デプロイ モデルで異なります。 各種ツールとデプロイ モデルで各ネクスト ホップの種類を指す際に使用される名前を次の表に示します。
テーブルの展開
| 次ホップの種類 | Azure CLI と PowerShell (Resource Manager) | Azure クラシック CLI と PowerShell (クラシック) |
|---|---|---|
| 仮想ネットワーク ゲートウェイ | VirtualNetworkGateway | VPNGateway |
| 仮想ネットワーク | VNetLocal | VNETLocal (クラシック デプロイ モデル モードではクラシック CLI では使用できません) |
| インターネット | インターネット | Internet (クラシック デプロイ モデル モードのクラシック CLI では使用不可) |
| 仮想アプライアンス | VirtualAppliance | VirtualAppliance |
| 無し | 無し | Null (クラシック デプロイ モデル モードのクラシック CLI では使用不可) |
| 仮想ネットワークピアリング | 仮想ネットワークピアリング | 適用なし |
| 仮想ネットワーク サービス エンドポイント | VirtualNetworkServiceEndpoint | 適用なし |
ボーダー ゲートウェイ プロトコル
オンプレミス ネットワーク ゲートウェイは、BGP を使用して Azure 仮想ネットワーク ゲートウェイとルートを交換できます。 Azure 仮想ネットワーク ゲートウェイでの BGP の使用方法は、ゲートウェイの作成時に選択した種類によって異なります。
- ExpressRoute:BGP を使用して、Microsoft Edge ルーターにオンプレミスのルートをアドバタイズする必要があります。 ExpressRoute の種類としてデプロイされた仮想ネットワーク ゲートウェイをデプロイする場合、ExpressRoute 仮想ネットワーク ゲートウェイへのトラフィックを強制する UDR を作成することはできません。 UDR を使用して、ExpressRoute からのトラフィックを (ネットワーク仮想アプライアンスなどに) 強制的に誘導することはできます。
- VPN: 必要に応じて、BGP を使用できます。 詳細については、「サイト間 VPN 接続での BGP」をご覧ください。
BGP を使用して Azure とルートを交換すると、仮想ネットワークのすべてのサブネットのルート テーブルに、アドバタイズされた各プレフィックスの個別のルートが追加されます。 追加されるルートは、ソースとネクストホップの種類が "仮想ネットワーク ゲートウェイ" になります。
サブネット上での ExpressRoute と Azure VPN Gateway のルート伝達は、ルート テーブルのプロパティを使用して無効にすることができます。 ルート伝達を無効にすると、システムにより、仮想ネットワーク ゲートウェイ ルート伝達が無効になっているすべてのサブネットのルート テーブルにはルートが追加されません。 このプロセスは、静的ルートと BGP ルートの両方に適用されます。 VPN 接続を使用した接続は、次ホップの種類が仮想ネットワーク ゲートウェイの カスタム ルート を使用して実現されます。 詳細については、「仮想ネットワーク ゲートウェイのルート伝達を無効にする」を参照してください。
注
GatewaySubnet では、ルートの伝達を無効にしないでください。 この設定を無効にするとゲートウェイが機能しません。
Azure がルートを選択するしくみ
送信トラフィックがサブネットから送信されると、Azure は最長プレフィックス一致アルゴリズムを使用して、宛先 IP アドレスに基づいてルートを選択します。 たとえば、ルート テーブルに 2 つのルートがあるとします。 一方のルートではアドレス プレフィックス 10.0.0.0/24 を指定し、もう一方のルートではアドレス プレフィックス 10.0.0.0/16 を指定しています。
Azure は、10.0.0.5 宛てのトラフィックを、10.0.0.0/24 アドレス プレフィックスを使用してルートで指定されたネクスト ホップの種類に転送します。 このプロセスが発生するのは、10.0.0.5 が両方のアドレス プレフィックスに含まれている場合でも、10.0.0.0/24 が 10.0.0.0/16 よりも長いプレフィックスであるためです。
Azure は、10.0.1.5 宛てのトラフィックを、10.0.0.0/16 アドレス プレフィックスを使用してルートで指定されたネクスト ホップの種類に転送します。 このプロセスが発生するのは、10.0.1.5 が 10.0.0.0/24 アドレス プレフィックスに含まれておらず、10.0.0.0/16 アドレス プレフィックスを持つルートが一致する最長プレフィックスであるためです。
複数のルートに同じアドレス プレフィックスが含まれている場合は、次の優先順位に基づいてルートの種類が選択されます。
- ユーザー定義のルート
- BGP のルート
- システム ルート
注
仮想ネットワーク、仮想ネットワークのピアリング、または仮想ネットワーク サービス エンドポイントに関連したトラフィックの場合はシステム ルートが優先されるルートです。 BGP ルートの方が具体的な場合でも優先されます。 ネクスト ホップの種類が仮想ネットワーク サービス エンドポイントであるルートは、ルート テーブルを使用するしてもオーバーライドできません。
たとえば、ルート テーブルに次のルートが含まれているとします。
テーブルの展開
| ソース | アドレス プレフィックス | 次ホップの種類 |
|---|---|---|
| 既定値 | 0.0.0.0/0 | インターネット |
| ユーザー | 0.0.0.0/0 | 仮想ネットワーク ゲートウェイ |
トラフィックがルート テーブル内の他のルートのアドレス プレフィックスの外側にある IP アドレス宛てである場合、Azure はユーザー ソースを含むルートを選択します。 システムの既定ルートよりも UDR の優先順位が高いため、Azure によってこのように選択されます。
テーブル内のルートの説明を含む包括的なルーティング テーブルについては、「ルーティングの例」をご覧ください。
0.0.0.0/0 アドレス プレフィックス
アドレス プレフィックスが 0.0.0.0/0 のルートでは、Azure への指示が提供されます。 Azure ではこれらの指示を使用して、サブネットのルート テーブルのその他のルートのアドレス プレフィックスに含まれていない IP アドレス宛てのトラフィックがルーティングされます。 サブネットが作成されると、Azure は、インターネットの次ホップの種類を持つ 0.0.0.0/0 アドレス プレフィックスへの 既定 のルートを作成します。 このルートをオーバーライドしない場合、その他のルートのアドレス プレフィックスに含まれていない IP アドレス宛てのすべてのトラフィックがインターネットにルーティングされます。
例外として、Azure サービスのパブリック IP アドレスへのトラフィックは Azure バックボーン ネットワーク上に残され、インターネットにルーティングされません。 このルートをカスタム ルートでオーバーライドすると、ルート テーブル内の他のルートのアドレス プレフィックス内にないアドレス宛てのトラフィックが転送されます。 宛先は、カスタム ルートでネットワーク仮想アプライアンスと仮想ネットワーク ゲートウェイのどちらを指定するかによって異なります。
0.0.0.0/0 アドレス プレフィックスをオーバーライドすると、サブネットからの送信トラフィックは仮想ネットワーク ゲートウェイまたは仮想アプライアンスを通過します。 Azure の既定のルーティングも次のように変わります。
Azure サービスのパブリック IP アドレス宛てのトラフィックを含め、すべてのトラフィックがルートで指定されている次ホップの種類に送信されます。
アドレス プレフィックスが 0.0.0.0/0 のルートの次ホップの種類がインターネットの場合、Azure サービスのパブリック IP アドレス宛てのサブネットからのトラフィックは、仮想ネットワークまたは Azure サービス リソースが存在する Azure リージョンに関係なく、Azure バックボーン ネットワークから離れることはありません。
仮想ネットワーク ゲートウェイまたは仮想アプライアンスの次ホップの種類を使用して UDR または BGP ルートを作成すると、すべてのトラフィックがルートで指定された次ホップの種類に送信されます。 これには、サービス エンドポイントを有効にしていない Azure サービスのパブリック IP アドレスに送信されるトラフィックが含まれます。
サービスのサービス エンドポイントを有効にすると、Azure では、サービスのアドレス プレフィックスを持つルートが作成されます。 サービスへのトラフィックは、0.0.0.0/0 アドレス プレフィックスを持つルート内のネクスト ホップの種類にルーティングされません。 サービスのアドレス プレフィックスは、0.0.0.0/0 よりも長くなっています。
サブネット内のリソースにインターネットから直接アクセスすることはできなくなります。 サブネット内のリソースには、インターネットから間接的にアクセスできます。 0.0.0.0/0 アドレス プレフィックスを持つルートのネクスト ホップの種類で指定されたデバイスは、受信トラフィックを処理する必要があります。 トラフィックがデバイスを通過すると、トラフィックは仮想ネットワーク内のリソースに到達します。 ネクスト ホップの種類として次の値がルートに含まれている場合:
仮想アプライアンス: アプライアンスは次の手順を実行する必要があります。
- インターネットからアクセスできる。
- パブリック IP アドレスが割り当てられている。
- デバイスとの通信の妨げとなるネットワーク セキュリティ グループの規則が関連付けられていない。
- 通信を拒否しない。
- ネットワーク アドレス変換を実行し、転送することができる。または、サブネット内の宛先リソースへのトラフィックをプロキシし、トラフィックをインターネットに送信できる。
仮想ネットワーク ゲートウェイ: ゲートウェイが ExpressRoute 仮想ネットワーク ゲートウェイの場合、オンプレミスのインターネットに接続されたデバイスは、ExpressRoute プライベート ピアリングを介して、サブネット内の宛先リソースへのトラフィックをネットワーク アドレス変換および転送またはプロキシできます。
仮想ネットワークが Azure VPN ゲートウェイに接続されている場合は、宛先が 0.0.0.0/0 であるルートを含むゲートウェイ サブネットにルート テーブルを関連付けないでください。 関連付けると、ゲートウェイが正しく機能しない可能性があります。 詳細については、「VPN ゲートウェイで特定のポートが開いているのはなぜですか。」を参照してください。
インターネットと Azure の間で仮想ネットワーク ゲートウェイを使用する場合の実装の詳細については、「Azure とオンプレミス データセンター間の DMZ」を参照してください。
ルーティングの例
この記事の概念を説明するために、この後のセクションでは以下について説明します。
- シナリオと要件。
- 要件を満たすために必要なカスタム ルート。
- 要件を満たすために必要な既定のルートとカスタム ルートが含まれた 1 つのサブネットのためのルート テーブル。
注
この例は、推奨される実装やベスト プラクティスの実装を示すものではありません。 この記事の概念の説明のみを目的としています。
要求事項
同じ Azure リージョンに 2 つの仮想ネットワークを実装し、リソースが仮想ネットワーク間で通信できるようにします。
オンプレミス ネットワークが、インターネット経由の VPN トンネルを介して両方の仮想ネットワークと安全に通信できるようにします。 "代わりに ExpressRoute 接続を使用することもできますが、この例では VPN 接続を使用します。"
一方の仮想ネットワークの 1 つのサブネットに次の要件が適用されます。
- そのサブネットからのすべてのアウトバウンド トラフィックを、検査とログ記録を目的としてネットワーク仮想アプライアンスを通してルーティングします。 Azure Storage への、およびこのサブネット内のトラフィックは、このルーティングから除外します。
- サブネット内のプライベート IP アドレス間のトラフィックを検査しないでください。 トラフィックがすべてのリソース間を直接流れることを許可します。
- もう一方の仮想ネットワーク宛ての送信トラフィックを破棄します。
- Azure Storage への送信トラフィックには、ネットワーク仮想アプライアンスを経由することを強制せず、トラフィックがストレージに直接流れることができるようにします。
他のすべてのサブネット間および仮想ネットワーク間ですべてのトラフィックを許可します。
実装
次の図は、上記の要件を満たす Resource Manager デプロイ モデルを使用した実装を示しています。
注
矢印はトラフィックのフローを示しています。
ルートテーブル
ここでは、前のルーティング例のルート テーブルについて説明します。
Subnet1
前の図の Subnet1 のルート テーブルには、次のルートが含まれています。
テーブルの展開
| ID | ソース | State | アドレス プレフィックス | 次ホップの種類 | 次ホップの IP アドレス | UDR 名 |
|---|---|---|---|---|---|---|
| 1 | 既定値 | 無効です | 10.0.0.0/16 | 仮想ネットワーク | ||
| 2 | ユーザー | アクティブです | 10.0.0.0/16 | 仮想アプライアンス | 10.0.100.4 | Within-VNet1 |
| 3 | ユーザー | アクティブです | 10.0.0.0/24 | 仮想ネットワーク | Within-Subnet1 | |
| 4 | 既定値 | 無効です | 10.1.0.0/16 | 仮想ネットワークピアリング | ||
| 5 | 既定値 | 無効です | 10.2.0.0/16 | 仮想ネットワークピアリング | ||
| 6 | ユーザー | アクティブです | 10.1.0.0/16 | 無し | ToVNet2-1-Drop | |
| 7 | ユーザー | アクティブです | 10.2.0.0/16 | 無し | ToVNet2-2-Drop | |
| 8 | 既定値 | 無効です | 10.10.0.0/16 | 仮想ネットワーク ゲートウェイ | [X.X.X.X] | |
| 9 | ユーザー | アクティブです | 10.10.0.0/16 | 仮想アプライアンス | 10.0.100.4 | To-On-Prem |
| 10 | 既定値 | アクティブです | [X.X.X.X] | VirtualNetworkServiceEndpoint | ||
| 11 | 既定値 | 無効です | 0.0.0.0/0 | インターネット | ||
| 12 | ユーザー | アクティブです | 0.0.0.0/0 | 仮想アプライアンス | 10.0.100.4 | Default-NVA |
各ルート ID の説明は次のとおりです。
ID1: 10.0.0.0/16 が仮想ネットワークのアドレス空間で定義されている唯一のアドレス範囲であるため、 Azure によって Virtual-network-1 内のすべてのサブネットに対してこのルートが自動的に追加されました。 ルート ID2 で UDR を作成しない場合、10.0.0.1 から 10.0.255.254 までのアドレスに送信されるトラフィックは、仮想ネットワーク内でルーティングされます。 このプロセスが発生するのは、プレフィックスが 0.0.0.0/0 より長く、他のどのルートのアドレス プレフィックスにも含まれていないためです。
UDR ID2 が追加されたときに、Azure によって状態が自動的にアクティブから無効に変更されました。 このプレフィックスは既定のルートと同じで、UDR によって既定のルートがオーバーライドされます。 UDR ID2 が存在するルート テーブルが Subnet2 に関連付けられていないため、このルートの状態は Subnet2 で引き続きアクティブです。
ID2: 10.0.0.0/16 アドレス プレフィックスの UDR が Virtual-network-1 仮想ネットワークの Subnet1 サブネットに関連付けられているときに、Azure によってこのルートが追加されました。 この UDR では、仮想アプライアンスの IP アドレスとして 10.0.100.4 を指定しています。このアドレスは、仮想アプライアンス仮想マシンに割り当てられているプライベート IP アドレスであるためです。 このルートが存在するルート テーブルは Subnet2 に関連付けられていないので、このルートは Subnet2 のルート テーブルには表示されません。
このルートによって、プレフィックスが 10.0.0.0/16 の既定のルート (ID 1) がオーバーライドされるので、仮想ネットワークのネクストホップの種類を使用して、10.0.0.1 および 10.0.255.254 にアドレス指定されたトラフィックが仮想ネットワーク内で自動的にルーティングされます。 このルートは、すべての送信トラフィックに仮想アプライアンスを経由することを強制するという要件 3 を満たすために存在しています。
ID3: 10.0.0.0/24 アドレス プレフィックスの UDR が Subnet1 サブネットに関連付けられているときに、Azure によってこのルートが追加されました。 10.0.0.1 から 10.0.0.254 までのアドレス宛てのトラフィックは、サブネット内にとどまります。 このトラフィックは、前の規則 (ID2) で指定された仮想アプライアンスにはルーティングされません。プレフィックスが ID2 ルートよりも長いからです。
このルートは Subnet2 に関連付けられていないので、Subnet2 のルート テーブルには表示されません。 このルートにより、Subnet1 内のトラフィック用の ID 2 のルートが効果的にオーバーライドされます。 このルートは、要件 3. を満たすために存在しています。
ID4: 仮想ネットワークが Virtual-network-2 とピアリングされたときに、Azure によって Virtual-network-1 内のすべてのサブネットの ID 4 と 5 のルートが自動的に追加されました。Virtual-network-2 のアドレス空間には、10.1.0.0/16 と 10.2.0.0/16 の 2 つのアドレス範囲があるため、Azure では範囲ごとにルートが追加されました。 ルート ID 6 と 7 で UDR を作成しない場合、10.1.0.1 から 10.1.255.254 まで、および 10.2.0.1 から 10.2.255.254 までのアドレスに送信されるトラフィックは、ピアリングされた仮想ネットワークにルーティングされます。 このプロセスが発生するのは、プレフィックスが 0.0.0.0/0 より長く、他のどのルートのアドレス プレフィックスにも含まれていないためです。
ID 6 と 7 でルートを追加すると、Azure によって状態が自動的にアクティブから無効に変更されます。 このプロセスが発生するのは、それらが ID 4 と 5 のルートと同じプレフィックスを持ち、UDR により既定のルートがオーバーライドされるためです。 ID 4 および 5 のルートの状態は、ID 6 と 7 の UDR が Subnet2 に関連付けられていないルート テーブルであるため、 Subnet2 では引き続きアクティブです。 仮想ネットワーク ピアリングは、要件 1. を満たすために作成されました。
ID5: ID4 と同じ説明。
ID6: 10.1.0.0/16 および 10.2.0.0/16 アドレス プレフィックスの UDR が Subnet1 サブネットに関連付けられている場合、Azure はこのルートと ID7 のルートを追加しました。 UDR によって既定のルートがオーバーライドされるので、10.1.0.1 から 10.1.255.254 まで、および 10.2.0.1 から 10.2.255.254 までのアドレス宛てのトラフィックは、ピアリングされた仮想ネットワークにルーティングされるのではなく、Azure によって破棄されます。 これらのルートは Subnet2 に関連付けられていないので、Subnet2 のルート テーブルには表示されません。 これらのルートによって、Subnet1 から出ていくトラフィック用の ID 4 と ID 5 のルートがオーバーライドされます。 ID 6 と ID 7 のルートは、もう一方の仮想ネットワーク宛てのトラフィックを破棄するという要件 3. を満たすために存在しています。
ID7: ID6 と同じ説明。
ID8: 仮想ネットワーク内に VPN タイプの仮想ネットワーク ゲートウェイが作成されたときに、 Azure によって Virtual-network-1 内のすべてのサブネットに対してこのルートが自動的に追加されました。 仮想ネットワーク ゲートウェイのパブリック IP アドレスがルート テーブルに追加されました。 10.10.0.1 ～ 10.10.255.254 のアドレスに送信されるトラフィックは、仮想ネットワーク ゲートウェイにルーティングされます。 プレフィックスが 0.0.0.0/0 より長く、他のどのルートのアドレス プレフィックスにも含まれていません。 仮想ネットワーク ゲートウェイは、要件 2. を満たすために作成されました。
ID9: 10.10.0.0/16 アドレス プレフィックスの UDR が Subnet1 に関連付けられているルート テーブルに追加されたときに、Azure によってこのルートが追加されました。 このルートによって ID 8 がオーバーライドされます。 このルートは、オンプレミス ネットワーク宛てのすべてのトラフィックをオンプレミスに直接ルーティングするのではなく、検査のためにネットワーク仮想アプライアンスに送信します。 このルートは、要件 3. を満たすために作成されました。
ID10: Azure サービスへのサービス エンドポイントがサブネットに対して有効になっているときに、Azure によってサブネットにこのルートが自動的に追加されました。 サブネットからのトラフィックは、Azure インフラストラクチャ ネットワーク経由でサービスのパブリック IP アドレスにルーティングされます。 プレフィックスが 0.0.0.0/0 より長く、他のどのルートのアドレス プレフィックスにも含まれていません。 サービス エンドポイントは、Azure Storage 宛てのトラフィックが Azure Storage に直接流れることができるようにするという要件 3 を満たすために作成されました。
ID11: Azure によって、 Virtual-network-1 および Virtual-network-2 内のすべてのサブネットのルート テーブルにこのルートが自動的に追加されました 。 0.0.0.0/0 アドレス プレフィックスは最短プレフィックスです。 これよりも長いアドレス プレフィックスに含まれるアドレスに送信されるすべてのトラフィックは、他のルートに基づいてルーティングされます。
既定では、他のルートのいずれかで指定されたアドレス以外のアドレス宛てのトラフィックはすべてインターネットにルーティングされます。 0.0.0.0/0 アドレス プレフィックス ( ID12 ) の UDR がサブネットに関連付けられているときに、Azure によって Subnet1 サブネットの状態が自動的にアクティブから無効に変更されました。 ルートは他の仮想ネットワーク内の他のサブネットに関連付けられていないため、このルートの状態は両方の仮想ネットワーク内の他のすべてのサブネットで引き続きアクティブです。
ID12: 0.0.0.0/0 アドレス プレフィックスの UDR が Subnet1 サブネットに関連付けられているときに、Azure によってこのルートが追加されました。 この UDR では、仮想アプライアンスの IP アドレスとして 10.0.100.4 を指定しています。 このルートは Subnet2 に関連付けられていないので、Subnet2 のルート テーブルには表示されません。 他のどのルートのアドレス プレフィックスにも含まれていないアドレス宛てのすべてのトラフィックが仮想アプライアンスに送信されます。
このルートを追加すると、UDR によって既定のルートがオーバーライドされるため、0.0.0.0/0 アドレス プレフィックス (ID11) の既定のルートの状態が Active から Invalid for Subnet1 に変更されました。 このルートは、要件 3. を満たすために存在しています。
Subnet2
前の図の Subnet2 のルート テーブルには、次のルートが含まれています。
テーブルの展開
| ソース | State | アドレス プレフィックス | 次ホップの種類 | 次ホップの IP アドレス |
|---|---|---|---|---|
| 既定値 | アクティブです | 10.0.0.0/16 | 仮想ネットワーク | |
| 既定値 | アクティブです | 10.1.0.0/16 | 仮想ネットワークピアリング | |
| 既定値 | アクティブです | 10.2.0.0/16 | 仮想ネットワークピアリング | |
| 既定値 | アクティブです | 10.10.0.0/16 | 仮想ネットワーク ゲートウェイ | [X.X.X.X] |
| 既定値 | アクティブです | 0.0.0.0/0 | インターネット | |
| 既定値 | アクティブです | 10.0.0.0/8 | 無し | |
| 既定値 | アクティブです | 100.64.0.0/10 | 無し | |
| 既定値 | アクティブです | 192.168.0.0/16 | 無し |
Subnet2 のルート テーブルには、Azure によって作成されたすべての既定のルートと、オプションの仮想ネットワーク ピアリング ルートおよび仮想ネットワーク ゲートウェイ ルートが含まれています。 ゲートウェイとピアリングが仮想ネットワークに追加されたときに、Azure によって、仮想ネットワークのすべてのサブネットにオプション ルートが追加されました。
アドレス プレフィックスが 0.0.0.0/0 の UDR が Subnet1 に追加されたときに、アドレス プレフィックスが 10.0.0.0/8、192.168.0.0/16、100.64.0.0/10 の各ルートが Subnet1 のルート テーブルから削除されました。