仮想ネットワーク トラフィックのルーティング
この記事では、Azure が、Azure、オンプレミス、インターネットの各リソース間でトラフィックをルーティングするしくみについて説明します。 Azure では、Azure 仮想ネットワークのサブネットごとにルート テーブルが自動的に作成され、既定のシステム ルートがテーブルに追加されます。 仮想ネットワークとサブネットの詳細については、仮想ネットワークの概要に関する記事をご覧ください。 Azure の一部のシステム ルートをカスタム ルートでオーバーライドし、ルート テーブルにカスタム ルートを追加できます。 サブネットのルート テーブルのルートに基づいて、サブネットからの送信トラフィックがルーティングされます。
システム ルート
Azure では、システム ルートが自動的に作成され、仮想ネットワークの各サブネットに割り当てられます。 システム ルートは作成することも削除することもできませんが、システム ルートをカスタム ルートでオーバーライドすることはできます。 Azure では、サブネットごとに既定のシステム ルートが作成されます。また、Azure の特定の機能を使用するときは、特定のサブネットまたはすべてのサブネットにオプションの既定のルートが追加されます。
既定値
各ルートには、アドレス プレフィックスとネクストホップの種類が含まれています。 サブネットから出ていくトラフィックが、ルートのアドレス プレフィックスに含まれる IP アドレスに送信されるとき、そのプレフィックスを含むルートが、Azure によって使用されるルートです。 複数のルートに同じプレフィックスが含まれている (プレフィックスが重複している) ときに、Azure がルートを選択するしくみの詳細については、こちらをご覧ください。 仮想ネットワークが作成されるたびに、その仮想ネットワークのサブネットごとに、次の既定のシステム ルートが自動的に作成されます。
| ソース | アドレス プレフィックス | 次ホップの種類 |
|---|---|---|
| Default | 仮想ネットワークに固有 | 仮想ネットワーク |
| Default | 0.0.0.0/0 | インターネット |
| Default | 10.0.0.0/8 | なし |
| 既定値 | 172.16.0.0/12 | なし |
| Default | 192.168.0.0/16 | なし |
| Default | 100.64.0.0/10 | なし |
上記の表に記載されているネクストホップの種類は、記載されているアドレス プレフィックス宛てのトラフィックを Azure がどのようにルーティングするのかを示しています。 ここで各ネクスト ホップの種類について説明します。
仮想ネットワーク:仮想ネットワークのアドレス空間内のアドレス範囲間でトラフィックをルーティングします。 Azure によって、仮想ネットワークのアドレス空間に定義された各アドレス範囲に対応するアドレス プレフィックスを含むルートが作成されます。 仮想ネットワークのアドレス空間に複数のアドレス範囲が定義されている場合は、アドレス範囲ごとに個別のルートが作成されます。 Azure の既定では、サブネット間でトラフィックがルーティングされます。 Azure がサブネット間でトラフィックをルーティングするためのルート テーブルやゲートウェイを定義する必要はありません。 Azure によってサブネット アドレス範囲の既定のルートが作成されることはありません。 各サブネットのアドレス範囲は、仮想ネットワークのアドレス空間のアドレス範囲に含まれます。
インターネット: アドレス プレフィックスで指定されたトラフィックをインターネットにルーティングします。 既定のシステム ルートでは、アドレス プレフィックス 0.0.0.0/0 が指定されています。 Azure の既定のルートをオーバーライドしない場合、Azure では、仮想ネットワーク内のアドレス範囲で指定されていないアドレス宛てのトラフィックはインターネットにルーティングされます。 このルーティングには 1 つの例外があります。 宛先アドレスが Azure サービスである場合、トラフィックはインターネットにルーティングされる代わりに、Azure バックボーン ネットワークを介してサービスに直接ルーティングされます。 Azure サービス間のトラフィックはインターネットを経由しません。 これは、仮想ネットワークが存在する Azure リージョン、または Azure サービスのインタンスがデプロイされている Azure リージョンには関係ありません。 アドレス プレフィックスが 0.0.0.0/0 の Azure の既定のシステム ルートは、カスタム ルートでオーバーライドできます。
なし: 種類がなしのネクスト ホップにルーティングされるトラフィックは、サブネットの外部にルーティングされるのではなく破棄されます。 Azure では、次のアドレス プレフィックスの既定のルートが自動的に作成されます。
- 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16: RFC 1918 でプライベート用に予約されています。
- 100.64.0.0/10:RFC 6598 で予約されています。
仮想ネットワークのアドレス空間内で上記のアドレス範囲のいずれかを割り当てた場合、ルートの次ホップの種類がなしから仮想ネットワークに自動的に変更されます。 4 つの予約済みアドレス プレフィックスのいずれかを含む仮想ネットワークのアドレス空間に、そのアドレス プレフィックスとは異なるアドレス範囲を割り当てた場合は、Azure によって元のプレフィックスのルートが削除され、追加したアドレス プレフィックスで、次ホップの種類が仮想ネットワークのルートが追加されます。
オプションの既定のルート
Azure では、Azure のさまざまな機能を有効にした場合に限り、その機能に対応する既定のシステム ルートが追加されます。 機能に応じて、仮想ネットワークの特定のサブネットまたはすべてのサブネットにオプションの既定のルートが追加されます。 各種機能を有効にしたときに追加される可能性がある他のシステム ルートとネクスト ホップの種類を次の表に示します。
| source | アドレス プレフィックス | 次ホップの種類 | ルートの追加先となる仮想ネットワークのサブネット |
|---|---|---|---|
| Default | 仮想ネットワークに固有 (例: 10.1.0.0/16 | 仮想ネットワーク ピアリング | すべて |
| 仮想ネットワーク ゲートウェイ | Border Gateway Protocol (BGP) 経由でオンプレミスからアドバタイズされたプレフィックス、またはローカル ネットワーク ゲートウェイで構成されているプレフィックス | 仮想ネットワーク ゲートウェイ | All |
| Default | 複数 | VirtualNetworkServiceEndpoint |
サービス エンドポイントが有効になっているサブネットのみ |
仮想ネットワーク ピアリング: 2 つの仮想ネットワーク間に仮想ネットワーク ピアリングを作成すると、システムにより、ピアリングに含まれる各仮想ネットワークのアドレス空間内のアドレス範囲ごとにルートが追加されます。 仮想ネットワーク ピアリングの詳細については、こちらをご覧ください。
[仮想ネットワーク ゲートウェイ] :仮想ネットワークに仮想ネットワーク ゲートウェイを追加すると、ネクストホップの種類が 仮想ネットワーク ゲートウェイ である 1 つ以上のルートが追加されます。 ゲートウェイによってサブネットにルートが追加されるため、ソースも仮想ネットワーク ゲートウェイです。 オンプレミス ネットワーク ゲートウェイが仮想ネットワーク ゲートウェイと BGP ルートを交換すると、システムにより、各ルートにルートが追加されます。 これらのルートは、オンプレミスのネットワーク ゲートウェイから伝達されます。 Azure 仮想ネットワーク ゲートウェイに伝達されるルートの数を最小限に抑えるために、オンプレミスのルートを最大限のアドレス範囲に集約することをお勧めします。 Azure 仮想ネットワーク ゲートウェイに伝達できるルートの数には制限があります。 詳しくは、Azure での制限に関するページをご覧ください。
VirtualNetworkServiceEndpoint: サービスのサービス エンドポイントを有効にすると、Azure によって特定のサービスのパブリック IP アドレスがルート テーブルに追加されます。 サービス エンドポイントは、仮想ネットワークの個々のサブネットで有効になるので、サービス エンドポイントが有効になっているサブネットのルート テーブルにのみルートが追加されます。 Azure サービスのパブリック IP アドレスは定期的に変更されます。 アドレスが変更されると、Azure によってルート テーブルのアドレスが自動的に管理されます。 仮想ネットワーク サービス エンドポイントと、サービス エンドポイントを作成できるサービスの詳細については、こちらをご覧ください。Note
仮想ネットワーク ピアリングと
VirtualNetworkServiceEndpointのネクスト ホップの種類それぞれは、Azure Resource Manager デプロイ モデルを使用して作成された仮想ネットワークのサブネットのルート テーブルにのみ追加されます。 これらのネクスト ホップの種類は、クラシック デプロイ モデルを使用して作成された仮想ネットワークのサブネットに関連付けられているルート テーブルには追加されません。 Azure のデプロイメント モデルの詳細については、こちら をご覧ください。
カスタム ルート
カスタム ルートを作成するには、ユーザー定義ルート (UDR) を作成するか、オンプレミス ネットワーク ゲートウェイと Azure 仮想ネットワーク ゲートウェイの間で BGP ルートを交換します。
ユーザー定義
トラフィック ルートをカスタマイズするために、既定のルートを変更しないでください。 Azure の既定のシステム ルートをオーバーライドする、カスタム ルートすなわちユーザー定義 (静的) ルートを作成する必要があります。 Azure では、ルート テーブルを作成した後、そのルート テーブルを 0 個以上の仮想ネットワーク サブネットに関連付けます。 各サブネットには、0 個または 1 個のルート テーブルを関連付けることができます。 ルート テーブルに追加できるルートの最大数と、Azure サブスクリプションごとに作成できる UDR テーブルの最大数については、Azure の制限に関する記事をご覧ください。
既定では、ルート テーブルには最大 400 個の UDR を含めることができます。 Azure Virtual Network Manager のルーティング構成を使用すると、この数をルート テーブルあたり 1000 個の UDR にまで増やすことができます。 この制限の引き上げにより、より高度なルーティング設定がサポートされるようになります。 たとえば、スポーク仮想ネットワークの数が多い場合に、オンプレミスのデータ センターからハブ アンド スポーク トポロジ内の各スポーク仮想ネットワークへファイアウォール経由でトラフィックを転送するなどです。
ルート テーブルを作成してサブネットに関連付けると、そのテーブルのルートがサブネットの既定のルートと結合されます。 ルートの割り当てが競合している場合は、UDR で既定のルートがオーバーライドされます。
UDR を作成するときは、次のネクスト ホップの種類を指定できます。
仮想アプライアンス:仮想アプライアンスとは、一般にネットワーク アプリケーション (ファイアウォールなど) が実行されている仮想マシンです。 仮想ネットワークにデプロイできる事前構成された各種ネットワーク仮想アプライアンスについては、Azure Marketplace のページをご覧ください。 ホップの種類が仮想アプライアンスのルートを作成するときは、ネクスト ホップの IP アドレスも指定します。 IP アドレスには、次のアドレスを指定できます。
仮想マシンに接続されたネットワーク インターフェイスのプライベート IP アドレス。 自身のアドレス以外のアドレスにネットワーク トラフィックを転送する、仮想マシンに接続されたネットワーク インターフェイスでは、Azure の [Enable IP forwarding](IP 転送を有効にする) オプションが有効になっている必要があります。 この設定により、Azure によるネットワーク インターフェイスの送信元と送信先のチェックが無効になります。 ネットワーク インターフェイスの IP 転送を有効にする方法の詳細については、こちらをご覧ください。 "IP 転送を有効にする" は、Azure の設定の 1 つです。
Azure のネットワーク インターフェイスに割り当てられたプライベート IP アドレス間でアプライアンスがトラフィックを転送できるようにするには、仮想マシンのオペレーティング システムの中で IP 転送を有効にすることが必要な場合があります。 アプライアンスがトラフィックをパブリック IP アドレスにルーティングする必要がある場合は、トラフィックをプロキシ経由にするか、ソースのプライベート IP アドレスから独自のプライベート IP アドレスにネットワーク アドレス変換 (NAT) を実行する必要があります。 その後、Azure では、トラフィックをインターネットに送信する前に、パブリック IP アドレスに NAT が実行されます。 仮想マシン内で必要な設定を確認するには、オペレーティング システムまたはネットワーク アプリケーションのドキュメントをご覧ください。 Azure での送信接続については、送信用接続の詳細に関するページを参照してください。
Note
仮想アプライアンスは、その仮想アプライアンス経由でルーティングされるリソースとは異なるサブネットにデプロイします。 仮想アプライアンスを同じサブネットにデプロイし、その仮想アプライアンスを介してトラフィックをルーティングするサブネットにルート テーブルを適用すると、トラフィックがサブネットから出ていくことのないルーティング ループが発生する可能性があります。
ネクスト ホップのプライベート IP アドレスは、Azure ExpressRoute ゲートウェイまたは Azure Virtual WAN 経由でルーティングせず、直接接続する必要があります。 直接接続せずにネクスト ホップを IP アドレスに設定すると、UDR 構成が無効になります。
Azure 内部ロード バランサーのプライベート IP アドレス。 多くの場合、ロード バランサーは、ネットワーク仮想アプライアンスの高可用性戦略の一環として使用されます。
アドレス プレフィックスが 0.0.0.0/0 で、仮想アプライアンスがネクスト ホップの種類のルートを定義することができます。 この構成により、アプライアンスがトラフィックを検査し、トラフィックを転送するか破棄するかを判断できるようになります。 アドレス プレフィックス 0.0.0.0/0 を含む UDR を作成する場合は、まず「アドレス プレフィックス 0.0.0.0/0」をお読みください。
[仮想ネットワーク ゲートウェイ] :特定のアドレス プレフィックス宛てのトラフィックを仮想ネットワーク ゲートウェイにルーティングする場合に指定します。 種類が VPN の仮想ネットワーク ゲートウェイを作成する必要があります。 ExpressRoute ではカスタム ルートに BGP を使用する必要があるため、種類を ExpressRoute として作成された仮想ネットワーク ゲートウェイを UDR で指定することはできません。 仮想プライベート ネットワーク (VPN) 接続と ExpressRoute 接続が共存している場合、仮想ネットワーク ゲートウェイは指定できません。 アドレス プレフィックス 0.0.0.0/0 宛てのトラフィックをルートベースの仮想ネットワーク ゲートウェイに送信するルートを定義できます。
オンプレミスで、トラフィックを検査し、トラフィックを転送するか破棄するかを判断するデバイスを使用している場合もあります。 アドレス プレフィックス 0.0.0.0/0 の UDR を作成する場合は、まず「アドレス プレフィックス 0.0.0.0/0」をお読みください。 VPN 仮想ネットワーク ゲートウェイに対する BGP が有効化されている場合は、アドレス プレフィックス 0.0.0.0/0 のための UDR を構成する代わりに、プレフィックス 0.0.0.0/0 のルートを BGP 経由でアドバタイズできます。
なし: アドレス プレフィックスへのトラフィックを宛先に転送するのではなく破棄する場合に指定します。 一部のオプションのシステム ルートでは、機能が構成されていない場合に [なし] と表示されることがあります。 たとえば、[ネクスト ホップ IP アドレス] に [なし] が表示されている場合に、[ネクスト ホップの種類] に [仮想ネットワーク ゲートウェイ] または [仮想アプライアンス] と表示されているならば、原因としてデバイスが稼働していないか、完全には構成されていないことが考えられます。 Azure では、予約済みアドレス プレフィクスの既定のシステム ルート は、ネクストホップの種類が なし で作成されます。
仮想ネットワーク: 仮想ネットワーク内の既定のルーティングをオーバーライドする場合に仮想ネットワーク オプションを指定します。 ホップの種類が [仮想ネットワーク] のルートを作成する理由の例については、「ルーティングの例」をご覧ください。
インターネット: アドレス プレフィックス宛てのトラフィックを明示的にインターネットにルーティングするときは、[インターネット] オプションを指定します。 または、パブリック IP アドレスを使用した Azure サービス宛てのトラフィックを Azure バックボーン ネットワークにとどめたい場合に、これを使用します。
UDR では、[仮想ネットワーク ピアリング] または VirtualNetworkServiceEndpoint をネクスト ホップの種類として指定することはできません。 ネクスト ホップの種類が [仮想ネットワーク ピアリング]または VirtualNetworkServiceEndpoint のルートが Azure によって作成されるのは、仮想ネットワーク ピアリングまたはサービス エンドポイントを構成するときだけです。
ユーザー定義ルートのサービス タグ
明示的な IP 範囲の代わりに、UDR のアドレス プレフィックスとしてサービス タグを指定できるようになりました。 サービス タグは、特定の Azure サービスからの IP アドレス プレフィックスのグループを表します。 サービス タグに含まれるアドレス プレフィックスの管理は Microsoft が行い、アドレスが変化するとサービス タグは自動的に更新されます。 これがサポートされることで、UDR が頻繁に更新されるという複雑さが最小化され、作成する必要があるルートの数が削減されます。 現在、各ルート テーブルで、サービス タグを含む 25 個以下のルートを作成できます。 このリリースでは、コンテナーのルーティング シナリオでのサービス タグの使用もサポートされています。
完全一致
明示的な IP プレフィックスを持つルートとサービス タグを持つルートの間で完全にプレフィックスが一致する場合は、システムにより、明示的なプレフィックスを持つルートが優先されます。 サービス タグを持つ複数のルートが IP プレフィックスに一致する場合、ルートは次の順序で評価されます。
リージョン タグ (
Storage.EastUSやAppService.AustraliaCentralなど)最上位レベル タグ (
StorageやAppServiceなど)AzureCloudリージョン タグ (AzureCloud.canadacentralやAzureCloud.eastasiaなど)AzureCloudタグ
この機能を使用するには、route table コマンドの address prefix パラメーターにサービス タグ名を指定します。 たとえば、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 エッジ ルーターにオンプレミスのルートをアドバタイズする必要があります。 仮想ネットワーク ゲートウェイの種類を ExpressRoute としてデプロイした場合、ExpressRoute 仮想ネットワーク ゲートウェイにトラフィックを強制的に誘導する UDR は作成できません。 UDR を使用して、ExpressRoute からのトラフィックを (ネットワーク仮想アプライアンスなどに) 強制的に誘導することはできます。
- VPN: 必要に応じて BGP を使用できます。 詳細については、「サイト間 VPN 接続での BGP」をご覧ください。
BGP を使用して Azure とルートを交換すると、仮想ネットワークのすべてのサブネットのルート テーブルに、アドバタイズされた各プレフィックスの個別のルートが追加されます。 追加されるルートは、ソースとネクストホップの種類が "仮想ネットワーク ゲートウェイ" になります。
サブネット上での ExpressRoute と Azure VPN Gateway のルート伝達は、ルート テーブルのプロパティを使用して無効にすることができます。 ルート伝達を無効にすると、システムにより、仮想ネットワーク ゲートウェイのルート伝達が無効になっているすべてのサブネットのルート テーブルにはルートが追加されません。 このプロセスは、静的ルートと BGP ルートの両方に適用されます。 VPN 接続の接続は、ネクスト ホップの種類が仮想ネットワーク ゲートウェイであるカスタム ルートを使用して実現されます。 詳細については、「仮想ネットワーク ゲートウェイのルート伝達を無効にする」を参照してください。
Note
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 のルート
システム ルート
Note
仮想ネットワーク、仮想ネットワークのピアリング、または仮想ネットワーク サービス エンドポイントに関連したトラフィックの場合はシステム ルートが優先されるルートです。 BGP ルートの方が具体的な場合でも優先されます。 ネクスト ホップの種類が仮想ネットワーク サービス エンドポイントであるルートは、ルート テーブルを使用するしてもオーバーライドできません。
たとえば、ルート テーブルに次のルートが含まれているとします。
| source | アドレス プレフィックス | 次ホップの種類 |
|---|---|---|
| Default | 0.0.0.0/0 | インターネット |
| User | 0.0.0.0/0 | 仮想ネットワーク ゲートウェイ |
トラフィックの宛先が、ルート テーブルのその他のルートのアドレス プレフィックスに含まれていない IP アドレスの場合、ソースが [ユーザー] のルートが選択されます。 システムの既定ルートよりも UDR の優先順位が高いため、Azure によってこのように選択されます。
テーブル内のルートの説明を含む包括的なルーティング テーブルについては、「ルーティングの例」をご覧ください。
アドレス プレフィックス 0.0.0.0/0
アドレス プレフィックスが 0.0.0.0/0 のルートでは、Azure への指示が提供されます。 Azure ではこれらの指示を使用して、サブネットのルート テーブルのその他のルートのアドレス プレフィックスに含まれていない IP アドレス宛てのトラフィックがルーティングされます。 サブネットが作成されると、アドレス プレフィックスが 0.0.0.0/0 で、ネクストホップの種類が インターネット の既定 のルートが作成されます。 このルートをオーバーライドしない場合、その他のルートのアドレス プレフィックスに含まれていない IP アドレス宛てのすべてのトラフィックがインターネットにルーティングされます。
例外として、Azure サービスのパブリック IP アドレスへのトラフィックは Azure バックボーン ネットワーク上に残され、インターネットにルーティングされません。 このルートをカスタム ルートでオーバーライドすると、ルート テーブル内の他のルートのアドレス プレフィックス内にないアドレス宛てのトラフィックが転送されます。 宛先は、カスタム ルートでネットワーク仮想アプライアンスと仮想ネットワーク ゲートウェイのどちらを指定するかによって異なります。
0.0.0.0/0 アドレス プレフィックスをオーバーライドすると、サブネットからの送信トラフィックは仮想ネットワーク ゲートウェイまたは仮想アプライアンスを通過します。 Azure の既定のルーティングも次のように変わります。
Azure サービスのパブリック IP アドレス宛てのトラフィックを含め、すべてのトラフィックがルートで指定されている次ホップの種類に送信されます。
アドレス プレフィックスが 0.0.0.0/0 のルートのネクスト ホップの種類が [インターネット]の場合、仮想ネットワークまたは Azure サービス リソースが存在する Azure リージョンに関係なく、Azure サービスのパブリック IP アドレスを宛先とするサブネットからのトラフィックは、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 つのサブネットのためのルート テーブル。
Note
この例は、推奨される実装やベスト プラクティスの実装を示すものではありません。 この記事の概念の説明のみを目的としています。
要件
同じ Azure リージョンに 2 つの仮想ネットワークを実装し、リソースが仮想ネットワーク間で通信できるようにします。
オンプレミス ネットワークが、インターネット経由の VPN トンネルを介して両方の仮想ネットワークと安全に通信できるようにします。 "代わりに ExpressRoute 接続を使用することもできますが、この例では VPN 接続を使用します。"
一方の仮想ネットワークの 1 つのサブネットに次の要件が適用されます。
- そのサブネットからのすべてのアウトバウンド トラフィックを、検査とログ記録を目的としてネットワーク仮想アプライアンスを通してルーティングします。 Azure Storage への、およびこのサブネット内のトラフィックは、このルーティングから除外します。
- サブネット内のプライベート IP アドレス間のトラフィックを検査しないでください。 トラフィックがすべてのリソース間を直接流れることを許可します。
- もう一方の仮想ネットワーク宛ての送信トラフィックを破棄します。
- Azure Storage への送信トラフィックには、ネットワーク仮想アプライアンスを経由することを強制せず、トラフィックがストレージに直接流れることができるようにします。
他のすべてのサブネット間および仮想ネットワーク間ですべてのトラフィックを許可します。
実装
次の図は、上記の要件を満たす Resource Manager デプロイ モデルを使用した実装を示しています。
矢印はトラフィックのフローを示しています。
ルート テーブル
ここでは、前のルーティング例のルート テーブルについて説明します。
Subnet1
前の図の Subnet1 のルート テーブルには、次のルートが含まれています。
| ID | source | State | アドレス プレフィックス | ネクストホップの種類 | 次ホップの IP アドレス | UDR 名 |
|---|---|---|---|---|---|---|
| 1 | Default | 無効 | 10.0.0.0/16 | 仮想ネットワーク | ||
| 2 | User | アクティブ | 10.0.0.0/16 | 仮想アプライアンス | 10.0.100.4 | Within-VNet1 |
| 3 | User | アクティブ | 10.0.0.0/24 | 仮想ネットワーク | Within-Subnet1 | |
| 4 | Default | 無効 | 10.1.0.0/16 | 仮想ネットワーク ピアリング | ||
| 5 | Default | 無効 | 10.2.0.0/16 | 仮想ネットワーク ピアリング | ||
| 6 | User | アクティブ | 10.1.0.0/16 | なし | ToVNet2-1-Drop | |
| 7 | User | アクティブ | 10.2.0.0/16 | なし | ToVNet2-2-Drop | |
| 8 | Default | 無効 | 10.10.0.0/16 | 仮想ネットワーク ゲートウェイ | [X.X.X.X] | |
| 9 | User | アクティブ | 10.10.0.0/16 | 仮想アプライアンス | 10.0.100.4 | To-On-Prem |
| 10 | Default | アクティブ | [X.X.X.X] | VirtualNetworkServiceEndpoint |
||
| 11 | Default | 無効 | 0.0.0.0/0 | インターネット | ||
| 12 | User | アクティブ | 0.0.0.0/0 | 仮想アプライアンス | 10.0.100.4 | Default-NVA |
各ルート ID の説明は次のとおりです。
ID1: 10.0.0.0/16 は Virtual-network-1 のアドレス空間に定義されている唯一のアドレス範囲であるため、Azure によって、この仮想ネットワークのすべてのサブネットにこのルートが自動的に追加されました。 ルート 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-1 が Virtual-network-2 とピアリングされたときに、Azure によって、仮想ネットワークのすべてのサブネットに ID 4 と 5 のルートが自動的に追加されました。Virtual-network-2 のアドレス空間には、10.1.0.0/16 と 10.2.0.0/16 の 2 つのアドレス範囲が含まれているので、範囲ごとにルートが追加されました。 ルート 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 6 と ID 7 の UDR が存在するルート テーブルは Subnet2 に関連付けられていないので、ID 4 と ID 5 のルートの状態は Subnet2 では [アクティブ] のままになります。 仮想ネットワーク ピアリングは、要件 1. を満たすために作成されました。
ID5: ID 4 の説明と同じです。
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: ID 6 の説明と同じです。
ID8: Virtual-network-1 内で種類が VPN の仮想ネットワーク ゲートウェイが作成されたときに、Azure によって、仮想ネットワークのすべてのサブネットにこのルートが自動的に追加されました。 仮想ネットワーク ゲートウェイのパブリック 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 の UDR (ID 12) が Subnet1 サブネットに関連付けられたときに、Azure によって、このサブネットでの状態が [アクティブ] から [無効] に自動的に変更されました。 このルートはその他の仮想ネットワーク内のその他のサブネットに関連付けられていないので、両方の仮想ネットワークの他のすべてのサブネットで、このルートの状態は [アクティブ] のままになります。
ID12: アドレス プレフィックス 0.0.0.0/0 の UDR が Subnet1 サブネットに関連付けられたときに、Azure によってこのルートが追加されました。 この UDR では、仮想アプライアンスの IP アドレスとして 10.0.100.4 を指定しています。 このルートは Subnet2 に関連付けられていないので、Subnet2 のルート テーブルには表示されません。 他のどのルートのアドレス プレフィックスにも含まれていないアドレス宛てのすべてのトラフィックが仮想アプライアンスに送信されます。
UDR によって既定のルートがオーバーライドされるので、このルートの追加により、Subnet1 では、アドレス プレフィックスが 0.0.0.0/0 の既定のルート (ID 11) の状態が [アクティブ] から [無効] に変更されました。 このルートは、要件 3. を満たすために存在しています。
Subnet2
前の図の Subnet2 のルート テーブルには、次のルートが含まれています。
| ソース | State | アドレス プレフィックス | ネクストホップの種類 | 次ホップの IP アドレス |
|---|---|---|---|---|
| Default | アクティブ | 10.0.0.0/16 | 仮想ネットワーク | |
| Default | アクティブ | 10.1.0.0/16 | 仮想ネットワーク ピアリング | |
| Default | アクティブ | 10.2.0.0/16 | 仮想ネットワーク ピアリング | |
| Default | アクティブ | 10.10.0.0/16 | 仮想ネットワーク ゲートウェイ | [X.X.X.X] |
| Default | アクティブ | 0.0.0.0/0 | インターネット | |
| Default | アクティブ | 10.0.0.0/8 | なし | |
| Default | アクティブ | 100.64.0.0/10 | なし | |
| Default | アクティブ | 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 のルート テーブルから削除されました。
関連するコンテンツ
- 複数のルートを含む UDR テーブルとネットワーク仮想アプライアンスを作成します。
- Azure VPN Gateway 用の BGP を構成します。
- ExpressRoute で BGP を使用します。
- サブネットのすべてのルートを表示します。 UDR テーブルに表示されるのは、UDR だけであり、サブネットの既定のルートや BGP ルートは表示されません。 すべてのルートを表示すると、ネットワーク インターフェイスが存在するサブネットの既定のルート、BGP ルート、UDR が表示されます。
- 仮想マシンと宛先 IP アドレス間のネクストホップの種類を確認 します。 Azure Network Watcher のネクスト ホップ機能を使用すると、トラフィックがサブネットを出ていき、想定している場所にルーティングされているかどうかを確認できます。