仮想ネットワーク トラフィックのルーティング
Azure が、Azure、オンプレミス、インターネットの各リソース間でトラフィックをルーティングするしくみについて説明します。 Azure では、Azure 仮想ネットワークのサブネットごとにルート テーブルが自動的に作成され、既定のシステム ルートがテーブルに追加されます。 仮想ネットワークとサブネットの詳細については、仮想ネットワークの概要に関する記事をご覧ください。 Azure の一部のシステム ルートをカスタム ルートでオーバーライドし、ルート テーブルにカスタム ルートを追加できます。 サブネットのルート テーブルのルートに基づいて、サブネットからの送信トラフィックがルーティングされます。
システム ルート
Azure では、システム ルートが自動的に作成され、仮想ネットワークの各サブネットに割り当てられます。 システム ルートは作成することも削除することもできませんが、システム ルートをカスタム ルートでオーバーライドできます。 Azure では、サブネットごとに既定のシステム ルートが作成されます。また、Azure の特定の機能を使用するときは、特定のサブネットまたはすべてのサブネットにオプションの既定のルートが追加されます。
Default
各ルートには、アドレス プレフィックスとネクストホップの種類が含まれています。 サブネットから出ていくトラフィックを、ルートのアドレス プレフィックスに含まれる IP アドレスに送信するときに、そのプレフィックスを含むルートが使用されます。 複数のルートに同じプレフィックス (重複するプレフィックス) が含まれているときに、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 | VNET ピアリング | All |
| 仮想ネットワーク ゲートウェイ | BGP 経由でオンプレミスからアドバタイズされたプレフィックス、またはローカル ネットワーク ゲートウェイで構成されているプレフィックス | 仮想ネットワーク ゲートウェイ | All |
| Default | 複数 | VirtualNetworkServiceEndpoint | サービス エンドポイントが有効になっているサブネットのみ |
仮想ネットワーク (VNet) ピアリング: 2 つの仮想ネットワーク間に仮想ネットワーク ピアリングを作成すると、システムにより、ピアリングに含まれる各仮想ネットワークのアドレス空間内のアドレス範囲ごとにルートが追加されます。 仮想ネットワーク ピアリングの詳細については、こちらをご覧ください。
[仮想ネットワーク ゲートウェイ] :仮想ネットワークに仮想ネットワーク ゲートウェイを追加すると、ネクストホップの種類が 仮想ネットワーク ゲートウェイ である 1 つ以上のルートが追加されます。 ゲートウェイによってサブネットにルートが追加されるため、ソースも "仮想ネットワーク ゲートウェイ"です。 オンプレミス ネットワーク ゲートウェイが仮想ネットワーク ゲートウェイとボーダー ネットワーク プロトコル (BGP) ルートを交換すると、システムにより、各ルートにルートが追加されます。 これらのルートは、オンプレミスのネットワーク ゲートウェイから伝達されます。 Microsoft では、Azure 仮想ネットワーク ゲートウェイに伝達されるルートの数を最小限に抑えるために、オンプレミスのルートを最大限のアドレス範囲に集約することをお勧めします。 Azure 仮想ネットワーク ゲートウェイに伝達できるルートの数には制限があります。 詳細については、Azure の制限 に関する記事をご覧ください。
VirtualNetworkServiceEndpoint:サービスのサービス エンドポイントを有効にすると、Azure によって特定のサービスのパブリック IP アドレスがルート テーブルに追加されます。 サービス エンドポイントは、仮想ネットワークの個々のサブネットで有効になるので、サービス エンドポイントが有効になっているサブネットのルート テーブルにのみルートが追加されます。 Azure サービスのパブリック IP アドレスは定期的に変更されます。 アドレスが変更されると、Azure によってルート テーブルのアドレスが自動的に管理されます。 仮想ネットワーク サービス エンドポイントと、サービス エンドポイントを作成できるサービスの詳細については、こちらをご覧ください。
Note
VNet ピアリング と VirtualNetworkServiceEndpoint の各ネクストホップの種類は、Azure Resource Manager デプロイ モデルを使用して作成された仮想ネットワークのサブネットのルート テーブルにのみ追加されます。 これらのネクスト ホップの種類は、クラシック デプロイ モデルを使用して作成された仮想ネットワークのサブネットに関連付けられているルート テーブルには追加されません。 Azure のデプロイメント モデルの詳細については、こちら をご覧ください。
カスタム ルート
カスタム ルートを作成するには、ユーザー定義ルートを作成するか、オンプレミス ネットワーク ゲートウェイと Azure 仮想ネットワーク ゲートウェイの間でボーダー ゲートウェイ プロトコル (BGP) ルートを交換します。
ユーザー定義
トラフィック ルートをカスタマイズするには、既定のルートを変更しないでください。ただし、Azure の既定のシステム ルートをオーバーライドするカスタムまたはユーザー定義の (静的) ルートを作成する必要があります。 Azure では、ルート テーブルを作成し、0 個以上の仮想ネットワーク サブネットに関連付けます。 各サブネットには、0 個または 1 個のルート テーブルを関連付けることができます。 ルート テーブルに追加できるルートの最大数と、Azure サブスクリプションごとに作成できるユーザー定義ルート テーブルの最大数については、Azure の制限に関する記事をご覧ください。 ルート テーブルを作成してサブネットに関連付けると、そのテーブルのルートがサブネットの既定のルートと結合されます。 ルートの割り当てが競合している場合は、ユーザー定義ルートで既定のルートがオーバーライドされます。
ユーザー定義ルートを作成するときは、次のネクストホップの種類を指定できます。
仮想アプライアンス:仮想アプライアンスとは、一般にネットワーク アプリケーション (ファイアウォールなど) が実行されている仮想マシンです。 仮想ネットワークにデプロイできる事前構成された各種ネットワーク仮想アプライアンスについては、Azure Marketplace のページをご覧ください。 ホップの種類が仮想アプライアンスのルートを作成するときは、次ホップの IP アドレスも指定します。 IP アドレスには、次のアドレスを指定できます。
仮想マシンに接続されたネットワーク インターフェイスのプライベート IP アドレス。 自身のアドレス以外のアドレスにネットワーク トラフィックを転送する、仮想マシンに接続されたネットワーク インターフェイスでは、Azure の [Enable IP forwarding](IP 転送を有効にする) オプションが有効になっている必要があります。 この設定により、Azure によるネットワーク インターフェイスの送信元と送信先のチェックが無効になります。 ネットワーク インターフェイスの IP 転送を有効にする方法の詳細については、こちらをご覧ください。 [Enable IP forwarding](IP 転送を有効にする) は Azure の設定ですが、Azure のネットワーク インターフェイスに割り当てられたプライベート IP アドレス間でアプライアンスがトラフィックを転送するために、仮想マシンのオペレーティング システム内でも IP 転送を有効にすることが必要な場合があります。 アプライアンスがトラフィックをパブリック IP アドレスにルーティングする必要がある場合は、トラフィックをプロキシ経由にするか、ソースのプライベート IP アドレスから独自のプライベート IP アドレスにネットワーク アドレス変換 (NAT) を実行する必要があります。 その後、Azure では、トラフィックをインターネットに送信する前に、パブリック IP アドレスに NAT が実行されます。 仮想マシン内で必要な設定を確認するには、オペレーティング システムまたはネットワーク アプリケーションのドキュメントをご覧ください。 Azure での送信接続については、送信用接続の詳細に関するページを参照してください。
Note
仮想アプライアンスは、その仮想アプライアンス経由でルーティングされるリソースとは異なるサブネットにデプロイします。 仮想アプライアンスを同じサブネットにデプロイし、その仮想アプライアンス経由でトラフィックをルーティングするサブネットにルート テーブルを適用すると、トラフィックがサブネットから出ていくことのないルーティング ループが発生する可能性があります。
ネクスト ホップのプライベート IP アドレスは、ExpressRoute ゲートウェイまたは Virtual WAN 経由でルーティングせず、直接接続する必要があります。 直接接続せずにネクスト ホップを IP アドレスに設定すると、ユーザー定義のルーティング構成が無効になります。
Azure 内部ロード バランサーのプライベート IP アドレス。 多くの場合、ロード バランサーは、ネットワーク仮想アプライアンスの高可用性戦略の一環として使用されます。
アドレス プレフィックスが 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 のユーザー定義ルートを構成する代わりに、プレフィックス 0.0.0.0/0 を含むルートを BGP 経由でアドバタイズできます。
なし: アドレス プレフィックスへのトラフィックを宛先に転送するのではなく破棄する場合に指定します。 機能を完全には構成していない場合、一部のオプションのシステム ルートに "なし" と表示されることがあります。 たとえば、ネクストホップの種類 が "仮想ネットワーク ゲートウェイ" または "仮想アプライアンス" であり、ネクストホップの IP アドレスに "なし" と表示されている場合、デバイスが実行されていないか、完全には構成されていないことが原因である可能性があります。 Azure では、予約済みアドレス プレフィクスの既定のシステム ルート は、ネクストホップの種類が なし で作成されます。
仮想ネットワーク: 仮想ネットワーク内の既定のルーティングをオーバーライドする場合に仮想ネットワーク オプションを指定します。 ホップの種類が "仮想ネットワーク" のルートを作成する理由の例については、「ルーティングの例」をご覧ください。
インターネット: アドレス プレフィックス宛てのトラフィックをインターネットに明示的にルーティングする場合、またはパブリック 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 タグ
この機能を使用するには、route table コマンドの address prefix パラメーターにサービス タグ名を指定します。 たとえば、PowerShell で、以下を使用することで、Azure Storage IP プレフィックスに送信されたトラフィックを仮想アプライアンスに移動させる新しいルートを作成できます。
$param = @{
Name = 'StorageRoute'
AddressPrefix = 'Storage'
NextHopType = 'VirtualAppliance'
NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param
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 とコマンド ライン ツール、および Azure Resource Manager デプロイ モデルとクラシック デプロイ モデルで異なります。 各種ツールとデプロイメント モデル で各ネクストホップの種類を指す際に使用される名前を次の表に示します。
| ネクストホップの種類 | Azure CLI と PowerShell (Resource Manager) | Azure クラシック CLI と PowerShell (クラシック) |
|---|---|---|
| 仮想ネットワーク ゲートウェイ | VirtualNetworkGateway | VPNGateway |
| 仮想ネットワーク | VNetLocal | VNETLocal (サービス管理モードのクラシック CLI では使用不可) |
| インターネット | インターネット | Internet (サービス管理モードのクラシック CLI では使用不可) |
| 仮想アプライアンス | VirtualAppliance | VirtualAppliance |
| なし | なし | Null (サービス管理モードのクラシック CLI では使用不可) |
| 仮想ネットワーク ピアリング | VNET ピアリング | 適用なし |
| 仮想ネットワーク サービス エンドポイント | VirtualNetworkServiceEndpoint | 適用なし |
ボーダー ゲートウェイ プロトコル
オンプレミス ネットワーク ゲートウェイは、ボーダー ゲートウェイ プロトコル (BGP) を使用して Azure 仮想ネットワーク ゲートウェイとルートを交換できます。 Azure 仮想ネットワーク ゲートウェイでの BGP の使用方法は、ゲートウェイの作成時に選択した種類によって異なります。
ExpressRoute:BGP を使用して、Microsoft Edge ルーターにオンプレミスのルートをアドバタイズする必要があります。 種類が ExpressRoute の仮想ネットワーク ゲートウェイをデプロイした場合、ExpressRoute の仮想ネットワーク ゲートウェイにトラフィックを強制的に誘導するユーザー定義ルートは作成できません。 Express Route からのトラフィックを (ネットワーク仮想アプライアンスなどに) 強制的に誘導するユーザー定義ルートは使用できます。
VPN:必要に応じて、BGP を使用できます。 詳細については、サイト間 VPN 接続での BGP に関する記事をご覧ください。
BGP を使用して Azure とルートを交換すると、仮想ネットワークのすべてのサブネットのルート テーブルに、アドバタイズされた各プレフィックスの個別のルートが追加されます。 追加されるルートは、ソースとネクストホップの種類が "仮想ネットワーク ゲートウェイ" になります。
ER と 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 のルート
システム ルート
Note
仮想ネットワーク、仮想ネットワークのピアリング、または仮想ネットワーク サービス エンドポイントに関連したトラフィックに使用されるシステム ルートは、BGP のルートの方が具体的であったとしても、優先されるルートとなります。
たとえば、ルート テーブルに次のルートが含まれているとします。
| source | アドレス プレフィックス | 次ホップの種類 |
|---|---|---|
| Default | 0.0.0.0/0 | インターネット |
| User | 0.0.0.0/0 | 仮想ネットワーク ゲートウェイ |
トラフィックの宛先が、ルート テーブルのその他のルートのアドレス プレフィックスに含まれていない IP アドレスの場合、ユーザー定義ルートは既定のシステム ルートよりも優先順位が高いため、ソースがユーザーのルートが選択されます。
テーブルの各ルートについて説明する包括的なルーティング テーブルについては、「ルーティングの例」をご覧ください。
アドレス プレフィックス 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 のバックボーン ネットワークから出ていくことはありません。 ただし、次ホップの種類が仮想ネットワーク ゲートウェイまたは仮想アプライアンスのユーザー定義ルートまたは 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 Gateway の FAQ」の質問「VPN ゲートウェイで特定のポートが開いているのはなぜですか」を参照してください。
インターネットと Azure 間で仮想ネットワーク ゲートウェイを使用する場合の実装の詳細については、Azure とオンプレミス データセンター間のネットワーク DMZ に関する記事を参照してください。
ルーティングの例
この記事の概念を説明するために、以降のセクションでは以下について説明します。
シナリオと要件
要件を満たすために必要なカスタム ルート
要件を満たすために必要な既定のルートとカスタム ルートが含まれた、1 つのサブネットのルート テーブル
Note
この例は、推奨される実装やベスト プラクティスの実装を示すものではありません。 この記事の概念の説明のみを目的としています。
必要条件
同じ Azure リージョンに 2 つの仮想ネットワークを実装し、リソースが仮想ネットワーク間で通信できるようにします。
オンプレミス ネットワークが、インターネット経由の VPN トンネルを介して両方の仮想ネットワークと安全に通信できるようにします。 "ExpressRoute 接続を使用することもできますが、この例では VPN 接続を使用します。 "
一方の仮想ネットワークの 1 つのサブネットに次の要件が適用されます。
検査とログ記録のために、Azure Storage とサブネット内を除き、サブネットからのすべての送信トラフィックにネットワーク仮想アプライアンスを経由することを強制します。
サブネット内のプライベート IP アドレス間のトラフィックは検査しません。これにより、すべてのリソース間でトラフィックが直接流れるようにします。
もう一方の仮想ネットワーク宛ての送信トラフィックを破棄します。
Azure Storage への送信トラフィックには、ネットワーク仮想アプライアンスを経由することを強制せず、トラフィックがストレージに直接流れることができるようにします。
他のすべてのサブネット間および仮想ネットワーク間ですべてのトラフィックを許可します。
実装
次の図は、上記の要件を満たす Azure Resource Manager デプロイ モデルを使用した実装を示しています。
矢印はトラフィックのフローを示しています。
ルート テーブル
Subnet1
図の Subnet1 のルート テーブルには、次のルートが含まれています。
| id | source | State | アドレス プレフィックス | ネクストホップの種類 | 次ホップの IP アドレス | ユーザー定義ルートの名前 |
|---|---|---|---|---|---|---|
| 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 | VNET ピアリング | ||
| 5 | Default | 無効 | 10.2.0.0/16 | VNET ピアリング | ||
| 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 でユーザー定義ルートを作成しない場合、10.0.0.1 から 10.0.255.254 までのアドレスに送信されるトラフィックは、仮想ネットワーク内でルーティングされます。 このプロセスは、プレフィックスが 0.0.0.0/0 より長く、他のどのルートのアドレス プレフィックスにも含まれていないためです。 ID 2 のユーザー定義ルートには、既定のルートと同じプレフィックスが含まれており、ユーザー定義ルートによって既定のルートがオーバーライドされるので、このユーザー定義ルートが追加されたときに、状態が "アクティブ" から "無効" に自動的に変更されました。 ユーザー定義ルート ID 2 が含まれているルート テーブルは Subnet2 に関連付けられていないので、このルートの状態は Subnet2 では "アクティブ" のままになります。
ID2: アドレス プレフィックスが 10.0.0.0/16 のユーザー定義ルートが Virtual-network-1 仮想ネットワークの Subnet1 サブネットに関連付けられたときに、Azure によってこのルートが追加されました。 このユーザー定義ルートでは、仮想アプライアンスの 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 のユーザー定義ルートが Subnet1 サブネットに関連付けられたときに、Azure によってこのルートが追加されました。 このルートのプレフィックスは ID 2 のルートよりも長いため、10.0.0.1 から 10.0.0.254 のアドレス宛てのトラフィックは、前の規則 (ID 2) で指定された仮想アプライアンスにルーティングされるのではなくサブネット内に残されます。 このルートは 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 でユーザー定義ルートを作成しない場合、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 のルートと同じプレフィックスを持ち、ユーザー定義ルートにより既定のルートがオーバーライドされるためです。 ID 6 と ID 7 のユーザー定義ルートが存在するルート テーブルは Subnet2 に関連付けられていないので、ID 4 と ID 5 のルートの状態は Subnet2 では "アクティブ" のままになります。 仮想ネットワーク ピアリングは、要件 1. を満たすために作成されました。
ID5: ID 4 の説明と同じです。
ID6: アドレス プレフィックスが 10.1.0.0/16 および 10.2.0.0/16 のユーザー定義ルートが Subnet1 サブネットに関連付けられたときに、Azure によってこのルートと ID 7 のルートが追加されました。 ユーザー定義ルートによって既定のルートがオーバーライドされるので、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 のユーザー定義ルートが、Subnet1 に関連付けられているルート テーブルに追加されたときに、Azure によってこのルートが追加されました。 このルートによって ID 8 がオーバーライドされます。 このルートは、オンプレミス ネットワーク宛てのすべてのトラフィックをオンプレミスに直接ルーティングするのではなく、検査のために NVA に送信します。 このルートは、要件 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 のユーザー定義ルート (ID 12) が Subnet1 サブネットに関連付けられたときに、Azure によって、このサブネットでの状態が "アクティブ" から "無効" に自動的に変更されました。 このルートはその他の仮想ネットワーク内のその他のサブネットに関連付けられていないので、両方の仮想ネットワークの他のすべてのサブネットで、このルートの状態は "アクティブ" のままになります。
ID12: アドレス プレフィックスが 0.0.0.0/0 のユーザー定義ルートが Subnet1 サブネットに関連付けられたときに、Azure によってこのルートが追加されました。 このユーザー定義ルートでは、仮想アプライアンスの IP アドレスとして 10.0.100.4 を指定しています。 このルートは Subnet2 に関連付けられていないので、Subnet2 のルート テーブルには表示されません。 他のどのルートのアドレス プレフィックスにも含まれていないアドレス宛てのすべてのトラフィックが仮想アプライアンスに送信されます。 ユーザー定義ルートによって既定のルートがオーバーライドされるので、このルートの追加により、Subnet1 では、アドレス プレフィックスが 0.0.0.0/0 の既定のルート (ID 11) の状態が "アクティブ" から "無効" に変更されました。 このルートは、3 番目の要件を満たすために存在しています。
Subnet2
図の Subnet2 のルート テーブルには、次のルートが含まれています。
| source | 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 のユーザー定義ルートが Subnet1 に追加されたときに、アドレス プレフィックスが 10.0.0.0/8、192.168.0.0/16、100.64.0.0/10 の各ルートが Subnet1 のルート テーブルから削除されました。
次のステップ
サブネットのすべてのルートを表示します。 ユーザー定義ルート テーブルに表示されるのは、ユーザー定義ルートだけであり、サブネットの既定のルートや BGP ルートは表示されません。 すべてのルートを表示すると、ネットワーク インターフェイスが存在するサブネットの既定のルート、BGP ルート、ユーザー定義ルートが表示されます。
仮想マシンと宛先 IP アドレス間のネクストホップの種類を確認 します。 Azure Network Watcher のネクストホップ機能を使用すると、トラフィックがサブネットを出ていき、想定している場所にルーティングされているかどうかを確認できます。