ルートテーブルは、Virtual Private Cloud (VPC) 内のネットワークトラフィックの転送パスを決定します。テーブルにルートを設定して、ECS インスタンスなどの送信元から送信先へパケットを転送できます。
特徴
ルートテーブル
Virtual Private Cloud (VPC) を作成すると、システムは自動的に システムルートテーブル を作成します。デフォルトでは、このルートテーブルは VPC 内のすべての vSwitch に関連付けられ、VPC 内のトラフィックを制御します。
VPC 内の異なる Elastic Compute Service (ECS) インスタンスが、同じ宛先 CIDR ブロックにアクセスするために異なるネットワークパスを使用する必要がある場合、カスタムルートテーブル を使用できます。ECS インスタンスを異なる vSwitch にデプロイし、各 vSwitch に固有のカスタムルートテーブルを関連付けることで、詳細なトラフィック制御を実現できます。
VPC へのインバウンドインターネットトラフィックを自己管理型ファイアウォールで保護するには、ボーダーゲートウェイに関連付けられたカスタムルートテーブルの一種である ゲートウェイルートテーブル を使用できます。ゲートウェイルートテーブルを IPv4/IPv6 ゲートウェイに関連付けることで、インバウンドインターネットトラフィックを自己管理型ファイアウォールに転送し、一元的なフィルタリング、監査、セキュリティポリシー管理を行うことができます。
次の表は、さまざまな種類のルートテーブルを比較したものです。
特徴 | システムルートテーブル | カスタムルートテーブル | |
関連付けオブジェクト | vSwitch | vSwitch | IPv4/IPv6 ゲートウェイ |
図 | |||
ユースケース | デフォルトですべての新しい vSwitch に関連付けられ、トラフィックを一元的に制御します。 | 特定の vSwitch に関連付けられ、個々のトラフィックフローを制御します。 | IPv4/IPv6 ゲートウェイに関連付けられ、インバウンドインターネットトラフィックを安全にリダイレクトします。 |
作成方法 | VPC を作成すると自動的に作成されます。 | 手動で作成します。ルートテーブルタイプとして vSwitch を選択します。 | 手動で作成します。ルートテーブルタイプとしてボーダーゲートウェイを選択します。 |
削除 | 削除できません。 | 削除できます。まず vSwitch からの関連付けを解除する必要があります。 | 削除できます。まず IPv4/IPv6 ゲートウェイからの関連付けを解除する必要があります。 |
クォータ | VPC ごとに 1 つのシステムルートテーブル。 | デフォルトでは、VPC は vSwitch に関連付けられた最大 9 つのカスタムルートテーブルをサポートします。クォータの引き上げをリクエストできます。 | VPC は IPv4/IPv6 ゲートウェイに関連付けられたルートテーブルを 1 つだけサポートします。 |
各 vSwitch は、必ず 1 つのルートテーブルに関連付ける必要があります。1 つのルートテーブルは、複数の vSwitch に関連付けることができます。
ルート
ルートは、ルートテーブル内のエントリです。特定の宛先 CIDR ブロックにトラフィックを転送する ネクストホップ (NAT Gateway や ECS インスタンスなど) を定義します。
VPC のルートは、次の 2 種類に分類されます。
1. 静的ルート:システムが追加したルート、またはユーザーが追加したルート。
2. 動的ルート:Transit Router (TR) や VPN Gateway などの他のネットワークインスタンスから VPC に伝播されるルート。
1. 静的ルート
静的ルートには、次の 2 種類があります。
システムルート:ネクストホップが
Localのルート。VPC と vSwitch を作成すると、システムが自動的にこのタイプのルートを追加します。これらのルートは、VPC 内のインスタンス間の通信や Alibaba Cloud サービスへのアクセスに使用されます。カスタムルート:トラフィックパスをカスタマイズするために手動で追加するルート。
次の図に示すように、2 つの VPC が VPC ピアリング接続を介して接続されています。VPC1 のシステムルートテーブルには、次の静的ルートが含まれています。
VPC と vSwitch を作成すると、システムはネクストホップが
Localに設定されたシステムルートを自動的に追加します。Alibaba Cloud サービスルート:宛先 CIDR ブロックは
100.64.0.0/10です。このルートにより、VPC1 のインスタンスは Alibaba Cloud サービスにアクセスできます。vSwitch ルート:宛先 CIDR ブロックは
10.0.0.0/24です。このルートにより、VPC1 内の vSwitch 間でプライベート通信が可能になります。
VPC ピアリング接続を作成した後、次のカスタムルートを手動で追加する必要があります。
宛先 CIDR ブロックは
172.16.0.0/16で、ネクストホップはVPC ピアリング接続です。このルートは、VPC2宛てのトラフィックを VPC ピアリング接続に転送します。
VPC2 のシステムルートテーブルのルートは、VPC1 のルートと同じ原則に従うため、ここでは説明を省略します。
システムルートとカスタムルートの比較
項目 | システムルート | カスタムルート |
定義 | ネクストホップが | 手動で追加するルート。 |
IPv4 ルート | システムは、VPC 内のすべてのルートテーブルに次のルートを自動的に追加します。
| 次のルートを手動で追加できます。
|
IPv6 ルート | VPC で IPv6 が有効になっている場合、システムは VPC 内のすべてのルートテーブルに次のルートを自動的に追加します。
| VPC で IPv6 が有効になっている場合、次のパラメーターを持つルートを追加できます。
|
ネクストホップは変更できますか? |
| システムルートのネクストホップを変更して作成されたカスタムルートの場合、このカスタムルートのネクストホップは Local、ECS インスタンス、ENI、または Gateway Load Balancer エンドポイントにのみ変更できます。 |
手動で作成できますか? | システムルートを手動で作成または削除することはできません。 | 作成および削除できます。 |
2. 動的ルート
動的ルートは、他のネットワークインスタンスから VPC に伝播されるルートです。静的ルートとは異なり、VPC ルートテーブルで動的ルートを手動で設定する必要はありません。動的ルートソースから自動的に学習され、更新されます。
2.1 動的ルートソース
VPC にルートを自動的に伝播するネットワークインスタンスには、Enterprise Edition Transit Router (TR)、Basic Edition Transit Router (TR)、VPN Gateway、および Express Connect Router (ECR) が含まれます。コンソールのルートテーブル詳細ページの タブで、動的ルートのソースと詳細を表示できます。
Enterprise Edition TR から受信したルートの詳細は、 タブに表示されます。
2.2 動的ルート受信の有効化または無効化
デフォルトでは、すべてのルートテーブルが動的ルートを受信します。純粋な静的ルーティング設定が必要な場合は、特定のルートテーブルに対して 動的ルート受信を無効にすることができます。これにより、ルーティング設定を柔軟に管理できます。
2.3 動的ルートの制限事項
VPC ルートテーブルは、一度に 1 つの動的ルートソースからのみ動的ルートを受信できます。
たとえば、VPC を ECR に関連付けた後、Enterprise Edition TR に接続すると、TR で VPC の ルート同期を有効にしようとしても失敗します。同様に、VPN Gateway を作成して BGP ルートの自動伝播を有効にすると、VPN Gateway によって学習された BGP ルートは VPC のシステムルートテーブルに自動的に伝播されます。この状態では、VPC を ECR に関連付けることはできません。
受信した動的ルートがルートテーブル内の既存のルートと重複する場合、ルート優先度を参照して、どのルートが優先されるかを判断してください。
vSwitch に関連付けられたルートテーブルのみが動的ルートを受信できます。ゲートウェイに関連付けられたルートテーブルは、動的ルートをサポートしていません。
デフォルトでは、1 つのルートテーブルは ECR から最大 200 のアクティブな動的ルートをサポートします。このクォータを超えるルートは受信されますが、非アクティブなままです。クォータを増やすと、新しい制限は次のルート伝播時に適用されます。非アクティブなルートは、受信した順に有効になります。
ルート優先度
VPC ルートテーブルのルートは、次のように優先順位が付けられます。
宛先 CIDR ブロックが重複するルートが存在する場合:
IPv4 と IPv6 のトラフィックは独立してルーティングされます。システムは最長プレフィックス一致ルールを使用して、宛先 IP アドレスに一致する最も具体的なルートを選択します。これにより、トラフィック転送のネクストホップが決定されます。
最長プレフィックス一致:複数のルートの宛先 CIDR ブロックがパケットの宛先 IP アドレスと一致する場合、システムはサブネットマスクが最も長い (最も具体的なネットワーク範囲) ルートを使用します。たとえば、
192.168.1.100宛てのトラフィックは、192.168.0.0/16ルートよりも先に192.168.1.0/24ルートに一致します。新しいルートの宛先 CIDR ブロックが既存のルートの宛先 CIDR ブロックと重複する場合:
アクション
既存のシステムルート
既存のカスタムルート
既存の動的ルート
vSwitch の作成
vSwitch の CIDR ブロックは、既存のシステムルートと重複できません。
vSwitch の CIDR ブロックは、以下を満たすことはできません。
既存のカスタムルートの宛先 CIDR ブロックと同一であること。
既存のカスタムルートの宛先 CIDR ブロックを含むこと。
vSwitch の CIDR ブロックは、以下を満たすことはできません。
既存の動的ルートの宛先 CIDR ブロックと同一であること。
既存の動的ルートの宛先 CIDR ブロックを含むこと。
カスタムルートの追加
新しいカスタムルートの宛先 CIDR ブロックは、以下を満たすことはできません。
既存のシステムルートの CIDR ブロックと同一であること。
既存のシステムルートよりも具体的であること。
新しいカスタムルートの宛先 CIDR ブロックは、既存のカスタムルートの宛先 CIDR ブロックと同一にすることはできません。
ネクストホップタイプが ルーターインターフェイス (VBR へ) の場合、アクティブ/スタンバイまたは等コストマルチパス (ECMP) ルートを設定できます。詳細については、ルーターインターフェイスへのルートをご参照ください。
カスタムルートを追加する場合、その宛先 CIDR ブロックは既存の動的ルートの宛先 CIDR ブロックと同一にすることはできません。
新しいカスタムルートのネクストホップが VPN Gateway またはルーターインターフェイスであり、CEN からの既存の動的ルートが同じ宛先 CIDR ブロックを持つ場合、動的ルートは取り消され、カスタムルートが有効になります。
動的ルートの受信
既存のシステムルートと同じ宛先 CIDR ブロックを持つことはできません。
既存のシステムルートよりも具体的な場合、動的ルートは有効になりません。
ルートソースが ECR の場合、動的ルートは VPC ルートテーブルに表示されますが、有効にはなりません。
ルートソースが VPN Gateway、Enterprise Edition Transit Router (TR)、または Basic Edition Transit Router (TR) の場合、動的ルートは VPC ルートテーブルに伝播されません。
既存のカスタムルートと同じ宛先 CIDR ブロックを持つ場合、動的ルートは有効になりません。
ルートソースが ECR の場合、動的ルートは VPC ルートテーブルに表示されますが、有効にはなりません。
ルートソースが VPN Gateway、Enterprise Edition Transit Router (TR)、または Basic Edition Transit Router (TR) の場合、動的ルートは VPC ルートテーブルに伝播されません。
カスタムルートが削除されると、動的ルートは自動的に有効になります。
サポートされていません。現在の VPC ルートテーブルには、ルート伝播ソースが 1 つしかありません。
ルートテーブルの管理
Virtual Private Cloud (VPC) を作成すると、システムは自動的にシステムルートテーブルを作成します。デフォルトでは、このルートテーブルはすべての vSwitch に関連付けられ、そのトラフィックを制御します。
VPC 内の特定の vSwitch のトラフィックを制御するには、vSwitch タイプのカスタムルートテーブルを作成し、それを vSwitch に関連付けます。
インターネットから VPC へのインバウンドトラフィックを制御するには、ボーダーゲートウェイタイプのカスタムルートテーブルを作成し、それを IPv4/IPv6 ゲートウェイに関連付けます。
ルートテーブルの作成と削除
vSwitch または IPv4/IPv6 ゲートウェイに関連付ける前に、カスタムルートテーブルを作成します。
コンソール
ルートテーブルの作成
VPC コンソールの ルートテーブル ページに移動し、作成 をクリックします。
対象の VPC を選択し、名前 を入力し、関連付ける オブジェクトタイプ を選択します。
vSwitch:このルートテーブルを vSwitch に関連付けた後、その特定の vSwitch のトラフィックパスを制御できます。
ボーダーゲートウェイ:このルートテーブルを IPv4/IPv6 ゲートウェイに関連付けた後、インターネットから VPC へのインバウンドトラフィックのパスを制御できます。
カスタムルートテーブルを作成すると、システムは自動的に次のシステムルートエントリを追加します。
vSwitch CIDR ブロックルート:宛先が VPC 内の任意の vSwitch の CIDR ブロックであるルートエントリ。このルートエントリにより、VPC 内のインスタンス間の通信が可能になります。
クラウドサービスルート:宛先 CIDR ブロックが
100.64.0.0/10のルートエントリ。このルートエントリにより、VPC 内のインスタンスは Alibaba Cloud サービスにアクセスできます。
ルートテーブルの削除
対象のルートテーブルの [アクション] 列またはその詳細ページで、[削除] をクリックします。ルートテーブルを削除する前に、すべてのリソースから 関連付けが解除されており、すべての カスタムルートエントリが削除されていることを確認してください。
削除できるのはカスタムルートテーブルのみです。システムルートテーブルは削除できません。
API
CreateRouteTable を呼び出してルートテーブルを作成します。
DeleteRouteTable を呼び出してカスタムルートテーブルを削除します。
Terraform
リソース:alicloud_route_table
variable "name" {
default = "terraform-example"
}
resource "alicloud_vpc" "defaultVpc" {
vpc_name = var.name
}
resource "alicloud_route_table" "default" {
description = "test-description"
vpc_id = alicloud_vpc.defaultVpc.id
route_table_name = var.name
associate_type = "VSwitch"
}ルートテーブルの関連付けと関連付け解除
デフォルトでは、新しいカスタムルートテーブルはどのリソースにも関連付けられていません。有効にするには、vSwitch または IPv4/IPv6 ゲートウェイに関連付ける必要があります。
コンソール
ルートテーブルの関連付け
VPC コンソールの ルートテーブル ページに移動します。対象のルートテーブルの [関連付けられたリソース] 列で、[関連付け] をクリックします。
ルートテーブルの オブジェクトタイプ が vSwitch の場合:[vSwitch の関連付け] をクリックし、表示されるダイアログボックスで対象の vSwitch を選択します。
vSwitch をカスタムルートテーブルに関連付けると、システムは自動的にシステムルートテーブルからその関連付けを解除します。
ルートテーブルの オブジェクトタイプ が ボーダーゲートウェイ の場合:[ボーダーゲートウェイの関連付け] をクリックし、表示されるダイアログボックスで対象の IPv4 ゲートウェイ または IPv6 ゲートウェイ を選択します。
ボーダーゲートウェイに関連付けられたルートテーブルの使用に関するチュートリアルについては、ゲートウェイルートテーブルを使用して VPC へのインバウンドトラフィックを制御するをご参照ください。
ルートテーブルの関連付け解除
対象のルートテーブルの詳細ページに移動します。
ルートテーブルの オブジェクトタイプ が vSwitch の場合: タブで、関連付けを解除する vSwitch を選択し、[関連付け解除] をクリックします。vSwitch の関連付けが解除されると、自動的にシステムルートテーブルに再関連付けされます。
ルートテーブルの オブジェクトタイプ が ボーダーゲートウェイ の場合: タブで、IPv4/IPv6 ゲートウェイを見つけ、[アクション] 列の [関連付け解除] をクリックします。
ルートテーブルの関連付けを解除する前に、サービスの中断を避けるために、ルート変更の潜在的な影響を評価してください。
API
AssociateRouteTable を呼び出して、ルートテーブルを vSwitch に関連付けます。
AssociateRouteTableWithGateway を呼び出して、ルートテーブルを IPv4/IPv6 ゲートウェイに関連付けます。
ルートテーブルの関連付けを解除する前に、サービスの中断を避けるために、ルート変更の潜在的な影響を評価してください。
UnassociateRouteTable を呼び出して、ルートテーブルを vSwitch から関連付け解除します。
DissociateRouteTableFromGateway を呼び出して、ルートテーブルを IPv4/IPv6 ゲートウェイから関連付け解除します。
Terraform
ルートテーブルと vSwitch の関連付け
リソース:alicloud_route_table_attachment
データソース:alicloud_zones
variable "name" {
default = "terraform-example"
}
resource "alicloud_vpc" "foo" {
cidr_block = "172.16.0.0/12"
vpc_name = var.name
}
data "alicloud_zones" "default" {
available_resource_creation = "VSwitch"
}
resource "alicloud_vswitch" "foo" {
vpc_id = alicloud_vpc.foo.id
cidr_block = "172.16.0.0/21"
zone_id = data.alicloud_zones.default.zones[0].id
vswitch_name = var.name
}
resource "alicloud_route_table" "foo" {
vpc_id = alicloud_vpc.foo.id
route_table_name = var.name
description = "route_table_attachment"
}
resource "alicloud_route_table_attachment" "foo" {
vswitch_id = alicloud_vswitch.foo.id
route_table_id = alicloud_route_table.foo.id
}ルートテーブルとゲートウェイの関連付け
リソース:alicloud_vpc_gateway_route_table_attachment
resource "alicloud_vpc" "example" {
cidr_block = "172.16.0.0/12"
vpc_name = "terraform-example"
}
resource "alicloud_route_table" "example" {
vpc_id = alicloud_vpc.example.id
route_table_name = "terraform-example"
description = "terraform-example"
associate_type = "Gateway"
}
resource "alicloud_vpc_ipv4_gateway" "example" {
ipv4_gateway_name = "terraform-example"
vpc_id = alicloud_vpc.example.id
enabled = true
}
resource "alicloud_vpc_gateway_route_table_attachment" "example" {
ipv4_gateway_id = alicloud_vpc_ipv4_gateway.example.id
route_table_id = alicloud_route_table.example.id
}ルートエントリの管理
ルートエントリの追加と削除
VSwitch の ルートテーブル に カスタムルート を追加して、そのトラフィックパスを制御できます。
IPv4 または IPv6 ゲートウェイに関連付けられている ルートテーブル に ルートエントリ を追加することはできませんが、ルートエントリのネクストホップを変更することはできます。
コンソール
ルートエントリの追加
ルートエントリの削除
対象の ルートエントリ の [アクション] 列で、[削除] をクリックします。
ルートエントリ を削除する前に、サービスの中断を避けるためにビジネスへの影響を十分に評価してください。
API
CreateRouteEntry 操作を使用して単一の
ルートエントリを追加し、CreateRouteEntries 操作を使用してルートエントリを一括で追加します。
ルートエントリ を削除する前に、サービスの中断を避けるためにビジネスへの影響を十分に評価してください。
DeleteRouteEntry 操作を使用して単一の
カスタムルートを削除し、DeleteRouteEntries 操作を使用してカスタムルートを一括で削除します。
Terraform
リソース:alicloud_route_entry
resource "alicloud_route_entry" "foo" {
route_table_id = "rt-12345xxxx" # ルートテーブル ID を指定します。
destination_cidrblock = "172.16.1.1/32"
nexthop_type = "Instance" # ネクストホップタイプを指定します。
nexthop_id = "i-12345xxxx" # ネクストホップのインスタンス ID を指定します。
}ネクストホップの変更
ルートエントリ の ネクストホップ を変更して、宛先 CIDR ブロック のトラフィックパスを変更できます。
システムルート:カスタムルートテーブル(ゲートウェイルートテーブルを含む) にある場合にのみ、システムルートのネクストホップを変更できます。変更後、ルートエントリはカスタムルートになります。このカスタムルートを削除すると、元のシステムルートが復元されます。カスタムルート:システムおよびカスタムのルートテーブルの両方で、カスタムルートのネクストホップを変更できます。
宛先 CIDR ブロック と ネクストホップ でサポートされているタイプについては、システムルートとカスタムルートの比較をご参照ください。
ルートエントリ の ネクストホップ を変更する前に、サービスの中断を避けるためにビジネスへの影響を十分に評価してください。
コンソール
対象の ルートエントリ の [アクション] 列で、[編集] をクリックします。表示されるダイアログボックスで、[ネクストホップタイプ] ドロップダウンリストから新しい ネクストホップ を選択します。
さまざまな ネクストホップ タイプの典型的なシナリオについては、設定例をご参照ください。
API
ModifyRouteEntry 操作を呼び出して、
VSwitchに関連付けられたルートテーブル内のルートエントリのネクストホップを変更します。UpdateGatewayRouteTableEntryAttribute 操作を呼び出して、IPv4/IPv6 ゲートウェイに関連付けられた
ルートテーブル内のルートエントリのネクストホップを変更します。
静的ルートの公開と取り消し
ルートテーブル の ルートエントリ は、Express Connect Router (ECR) または Transit Router (TR) に公開できます。この機能を 動的ルート受信 と組み合わせることで、ルート設定が簡素化されます。
静的ルートを Express Connect Router (ECR) に公開する:静的ルートが ECR に公開されると、ECR はそのルートをオンプレミスデータセンターに動的に伝播します。ルートの競合が存在しない場合、ECR に関連付けられているすべてのオンプレミスデータセンターがこのルートを学習できます。静的ルートを Transit Router (TR) に公開する:静的ルートが
Transit Routerに公開された後、ルートの競合がなく、TR でルート同期が有効になっている場合、TR に接続されているすべてのネットワークインスタンスがこのルートを学習します。
Virtual Private Cloud が ECR と TR の両方に接続されている場合、ルートエントリ の ECR への公開と TR への公開は互いに独立しています。
コンソール
静的ルートエントリの公開
対象の ルートエントリ の [ルートアドバタイズステータス] 列で、[公開] をクリックします。
[ルートアドバタイズステータス] 列は、Virtual Private Cloud が TR または ECR に接続された後にのみコンソールに表示されます。公開された静的ルートエントリの取り消し
対象の ルートエントリ の [ルートアドバタイズステータス] 列で、[取り消し] をクリックします。
[ルートアドバタイズステータス] 列は、Virtual Private Cloud が TR または ECR に接続された後にのみコンソールに表示されます。API
ECR の場合:
PublishVpcRouteEntries 操作を呼び出して、静的な
ルートエントリを ECR に公開します。WithdrawVpcPublishedRouteEntries 操作を呼び出して、ECR に公開された
ルートエントリを取り消します。
TR の場合:
PublishRouteEntries 操作を呼び出して、静的な
ルートエントリを TR に公開します。WithdrawPublishedRouteEntries 操作を呼び出して、TR に公開された
ルートエントリを取り消します。
タブ本文
動的ルート受信の有効化と無効化
デフォルトでは、すべての ルートテーブル が 動的ルート を受信します。純粋な静的ルーティング設定が必要な場合は、特定の ルートテーブル の 動的ルート受信 を無効にして、必要に応じてルーティング設定を管理できます。
動的ルート受信は、動的ルートのソースが[ルート伝搬タイプ ECR]の場合、または動的ルートが
仮想プライベートクラウドに伝搬されない場合に無効化できます。動的ルートが仮想プライベートクラウドに伝搬されない場合、[動的ルートソース]は、[ルートエントリ一覧] > [動的ルート] タブのルートテーブル詳細ページに表示されません。以下のケースでは、
Dynamic Route Receivingを無効化できません:仮想プライベートクラウドが Basic Edition のトランジットルーターに接続されている場合。仮想プライベートクラウドが Enterprise Edition のトランジットルーターに接続されており、トランジットルーター上で仮想プライベートクラウドのルート同期が有効になっている場合。仮想プライベートクラウドが VPN Gateway に関連付けられており、VPN Gateway のルート自動伝播が有効になっている場合。機能を無効にした場合の影響:
Virtual Private Cloudルートテーブルは、他のネットワークインスタンスから伝播されるルートを受信しなくなります。ルートテーブルに動的ルートが存在する場合、システムはそれらを削除します。注意して進めてください。Virtual Private Cloudは Basic Edition TR に接続できません。このVirtual Private Cloudに接続されている TR は、Virtual Private Cloudのルート同期を有効にできません。このVirtual Private Cloudに関連付けられているVPN GatewayのBGP ルートの自動伝播を有効にすることはできません。
無効にした後に機能を再有効化した場合の影響:
機能を再有効化すると、システムは動的ルートソースから伝播されたルートに基づいて、
Virtual Private Cloudルートテーブルの動的ルートを更新します。たとえば、ECR に 4 つの動的ルートがあるとします。この機能を無効にすると、動的ルートは
Virtual Private Cloudルートテーブルからクリアされます。ECR にさらに 2 つのルートエントリが追加され、その後この機能を再有効化すると、Virtual Private Cloudルートテーブルは ECR から 6 つの動的ルートを受信します。
コンソール
対象の ルートテーブル の [ルートテーブル詳細] ページに移動します。[アドバタイズされたルートの受信] スイッチを使用して、動的ルート受信 を有効または無効にします。
動的ルート受信 を有効または無効にする前に、サービスの中断を避けるために、ルート変更のビジネスへの影響を十分に評価してください。
API
ModifyRouteTableAttributes を呼び出し、RoutePropagationEnable パラメーターを変更して、動的ルート受信を有効または無効にします。
動的ルート受信 を有効または無効にする前に、サービスの中断を避けるために、ルート変更のビジネスへの影響を十分に評価してください。
Terraform
動的ルート受信 を有効または無効にする前に、サービスの中断を避けるために、ルート変更のビジネスへの影響を十分に評価してください。
リソース:alicloud_route_table
variable "name" {
default = "terraform-example"
}
resource "alicloud_vpc" "defaultVpc" {
vpc_name = var.name
}
resource "alicloud_route_table" "default" {
description = "test-description"
vpc_id = alicloud_vpc.defaultVpc.id
route_table_name = var.name
associate_type = "VSwitch"
route_propagation_enable = true # このパラメーターを変更して、動的ルート受信を有効または無効にします。
}ゲートウェイルートテーブルの使用
ゲートウェイルートテーブルを使用すると、インターネットからのインバウンドトラフィック をセキュリティデバイスに転送して、詳細な検査とフィルタリングを行うことができます。これにより、悪意のある攻撃や不正アクセスを防ぐことができます。また、ゲートウェイルートテーブルとカスタムルートテーブルを組み合わせて、アウトバウンドトラフィックをセキュリティデバイスにリダイレクトすることもできます。
この機能を使用するには、ルートテーブルを作成し、それを IPv4 ゲートウェイに関連付けます。次に、ルートテーブル内の vSwitch CIDR ブロックのシステムルートのネクストホップを、次のいずれかに変更します。
ECS インスタンス/Elastic Network Interface (ENI):インターネットトラフィックを特定の ECS インスタンスまたは ENI にリダイレクトして、セキュリティ検査を行います。
Gateway Load Balancer エンドポイント (GWLBe):Gateway Load Balancer (GWLB) を介して、インターネットトラフィックをサードパーティのセキュリティデバイスにリダイレクトします。
ネクストホップを Gateway Load Balancer エンドポイント (GWLBe) に変更できるのは、これらのリージョン
自己管理型ファイアウォールの使用
Virtual Private Cloud (VPC) の ECS インスタンスに自己管理型ファイアウォールをデプロイし、ゲートウェイルートテーブルを使用して VPC に入るトラフィックをファイアウォールにリダイレクトしてフィルタリングすることができます。
GWLB 高可用性アーキテクチャ
Gateway Load Balancer (GWLB) を使用して、異なるセキュリティデバイス間でトラフィックを分散し、アプリケーションのセキュリティと可用性を向上させることができます。
設定例
さまざまなネクストホップタイプは、さまざまなシナリオに適用されます。
IPv4 ゲートウェイへのルート
IPv4 ゲートウェイを、Virtual Private Cloud (VPC) とインターネット間のトラフィックの統一された入口および出口として使用できます。カスタムルートテーブルと併用すると、IPv4 ゲートウェイはインターネットアクセストラフィックの一元的な制御を可能にします。この設定は、統一されたセキュリティポリシーの実装を支援し、監査を簡素化し、分散アクセスポイントのセキュリティリスクを低減します。
IPv6 ゲートウェイへのルート
Virtual Private Cloud (VPC) で IPv6 を有効にすると、システムは自動的にシステムルートテーブルにルートを追加します。
宛先 CIDR ブロックは
::/0で、ネクストホップは IPv6 ゲートウェイです。
このルートは、デフォルトの IPv6 トラフィックを IPv6 ゲートウェイに転送します。IPv6 アドレスのパブリック帯域幅を有効にすると、システムルートテーブルに関連付けられた vSwitch はインターネットと通信できるようになります。
カスタムルートテーブルに関連付けられた IPv6 対応の vSwitch の場合、IPv6 インターネットアクセスを有効にするには、上記のルートをカスタムルートテーブルに手動で追加する必要があります。
ネクストホップが IPv6 ゲートウェイであるカスタムルートの場合、宛先 CIDR ブロックは ::/0 でなければなりません。インターネット NAT ゲートウェイへのルート
多くのサーバーがインターネットへの接続を開始する場合、インターネット NAT ゲートウェイの SNAT (ソースネットワークアドレス変換) 機能を使用できます。これにより、Virtual Private Cloud (VPC) 内の複数の ECS インスタンスが Elastic IP (EIP) アドレスを共有してインターネットにアクセスできます。この設定は、パブリック IP リソースを節約し、プライベート IP アドレスを公開しないことでセキュリティリスクを低減します。
インターネット NAT ゲートウェイを介したインターネットアクセスを有効にするには、トラフィックをゲートウェイに転送するカスタムルートを VPC ルートテーブルに追加する必要があります。
ECS インスタンスの VSwitch がカスタムルートテーブルに関連付けられている場合、[宛先 CIDR ブロック] が
0.0.0.0/0で、[ネクストホップ] がインターネット NAT ゲートウェイであるルートエントリを手動で設定する必要があります。ECS インスタンスの vSwitch がシステムルートテーブルに関連付けられている場合:
システムルートテーブルに宛先 CIDR ブロック
0.0.0.0/0のルートが存在しない場合、システムは自動的にインターネット NAT ゲートウェイを指すルートを追加します。システムルートテーブルに宛先 CIDR ブロック
0.0.0.0/0のルートが既に存在する場合、まず既存のルートを削除してから、インターネット NAT ゲートウェイを指す新しいルートを追加する必要があります。
- パブリック vSwitch 10.0.1.0/24
- VPC 10.0.0.0/16
- ...
- インターネット
- ネクストホップ
- NAT Gateway
- 宛先 CIDR
- Elastic IP (EIP)
- プライベート vSwitch ルートテーブル
- Elastic IP (EIP)
- ECS 2
- プライベート vSwitch 2 10.0.3.0/24
- 0.0.0.0/0
- プライベート vSwitch 1 10.0.2.0/24
- NAT Gateway
- ECS 1
VPC ピアリング接続へのルート
VPC は互いに分離されていますが、VPC ピアリング接続を使用して、同じまたは異なるアカウントおよびリージョンの 2 つの VPC 間でプライベート通信を有効にできます。2 つの VPC 間にピアリング接続が確立されると、VPC にデプロイされたクラウドリソースは、プライベート IPv4 または IPv6 アドレスを使用して互いにアクセスできます。
Transit Router へのルート
Cloud Enterprise Network (CEN) を使用して VPC を接続する場合、Transit Router を指すルートを VPC ルートテーブルに追加する必要があります。これには、次のいずれかの方法があります。
VPC 接続を作成するときに、[Transit Router を指すルートを自動的に作成し、現在の VPC のすべてのルートテーブルに追加する] を選択します。
この機能を有効にすると、システムは VPC のすべてのルートテーブルに 3 つのルートを自動的に追加します。これらのルートの宛先 CIDR ブロックは、10.0.0.0/8、172.16.0.0/12、および 192.168.0.0/16 です。これらのルートのネクストホップは VPC 接続であり、VPC からの IPv4 トラフィックを Transit Router に転送します。
Transit Router で ルート学習を有効にした後、各 VPC で ルート同期を有効にするか、各 VPC ルートテーブルにピア VPC を指すルートを手動で追加します。
次の図は、Transit Router でルート学習が有効になった後、VPC ルートテーブルにルートが手動で追加される例を示しています。ルートの宛先 CIDR ブロックはピア VPC の CIDR ブロックであり、そのネクストホップは Transit Router です。
VPN Gateway へのルート
VPN Gateway を使用して、オンプレミスデータセンターと VPC 間に安全で信頼性の高い暗号化トンネルを確立します。
VPN Gateway を使用する場合、VPC にルートを追加する必要があります。このルートでは、[宛先 CIDR ブロック] をオンプレミスデータセンターの CIDR ブロックに設定し、[ネクストホップ] を VPN Gateway に設定します。これにより、VPC は IPsec-VPN 接続を介してオンプレミスデータセンターにアクセスできます。
ECS インスタンスまたは ENI へのルート
VPC 内の 2 つの vSwitch が通信する必要がある場合、ルートテーブルを調整して、ファイアウォールや Web Application Firewall (WAF) などのサードパーティのセキュリティデバイスをトラフィックパスに挿入し、トラフィックを検査、分析、保護できます。
これを設定するには、通信する各 vSwitch を別々のカスタムルートテーブルに関連付けます。次に、対応する CIDR ブロックのシステムルートのネクストホップを、ファイアウォールの ECS インスタンスまたは Elastic Network Interface (ENI) に変更します。
ルーターインターフェイスへのルート
Express Connect の VBR-VPC 接続機能を使用すると、オンプレミスデータセンターを VPC に接続できます。
VBR-VPC 接続機能はデフォルトでは有効になっていません。使用するには、アカウントマネージャーにお問い合わせください。
この機能を使用する場合、VPC にルートを追加する必要があります。このルートでは、宛先 CIDR ブロックをオンプレミスデータセンターの CIDR ブロックに設定し、ネクストホップタイプを ルーターインターフェイス (VBR へ) に設定します。これにより、VPC は仮想ボーダールーター (VBR) を介してオンプレミスデータセンターにアクセスできます。このネクストホップタイプは、等コストマルチパス (ECMP) と アクティブ/スタンバイモードをサポートしています。これらのモードは ヘルスチェックと併用する必要があります。
アクティブ/スタンバイ:ネクストホップとして指定できるインスタンスは 2 つだけです。アクティブルートのネクストホップの重みは 100、スタンバイルートのネクストホップの重みは 0 です。アクティブルートのヘルスチェックが失敗すると、スタンバイルートが引き継ぎます。
ECMP:ネクストホップとして 2 ~ 16 のインスタンスを指定できます。各インスタンスは同じ重み (0 ~ 255 の整数) を持つ必要があります。システムは、ネクストホップインスタンス間でトラフィックを均等に分散します。
次の図は、アクティブ/スタンバイモードを示しています。
Express Connect Router へのルート
Express Connect Router (ECR) と Express Connect を使用して、オンプレミスデータセンターを VPC に接続できます。
デフォルトでは、VPC は ECR からの動的ルートを受け入れます。これらのルートでは、宛先 CIDR ブロックはオンプレミスデータセンターの CIDR ブロックであり、ネクストホップは ECR です。この設定により、VPC とオンプレミスデータセンター間の通信が可能になります。
VPC ルートテーブルで動的ルート受信が無効になっている場合、VPC ルートテーブルにルートを手動で追加する必要があります。このルートでは、[宛先 CIDR ブロック] をオンプレミスデータセンターの CIDR ブロックに設定し、[ネクストホップ] を Express Connect Router に設定します。これにより、VPC とオンプレミスデータセンター間の通信が可能になります。
Gateway Load Balancer エンドポイントへのルート
Gateway Load Balancer エンドポイント のネクストホップタイプは、これらのリージョンでのみ利用可能です。具体的なユースケースについては、ゲートウェイルートテーブルの使用 - GWLB 高可用性アーキテクチャをご参照ください。
関連ドキュメント
エリア | カスタムルートテーブルをサポートするリージョン |
アジアパシフィック - 中国 | 中国 (杭州)、中国 (上海)、中国 (南京-ローカルリージョン - 提供終了)、中国 (青島)、中国 (北京)、中国 (張家口)、中国 (フフホト)、中国 (ウランチャブ)、中国 (深セン)、中国 (河源)、中国 (広州)、中国 (成都)、中国 (香港)、中国 (武漢 - ローカルリージョン)、中国 (福州-ローカルリージョン - 提供終了) |
アジアパシフィック - その他 | 日本 (東京)、韓国 (ソウル)、シンガポール、マレーシア (クアラルンプール)、インドネシア (ジャカルタ)、フィリピン (マニラ)、タイ (バンコク) |
ヨーロッパおよびアメリカ | ドイツ (フランクフルト)、イギリス (ロンドン)、米国 (シリコンバレー)、米国 (バージニア)、メキシコ |
中東 | UAE (ドバイ)、サウジアラビア (リヤド - パートナー運営) |
クォータ
クォータ名 | 説明 | デフォルトの制限 | 調整可能 |
vpc_quota_route_tables_num | VPC ごとのカスタムルートテーブル。 | 9 | はい。 |
vpc_quota_route_entrys_num | ルートテーブルごとのカスタムルートエントリ (動的に伝播されるルートエントリを除く)。 | 200 | |
vpc_quota_dynamic_route_entrys_num | テーブルごとの動的に伝播されるルート。 | 500 | |
vpc_quota_havip_custom_route_entry | HaVip を指す最大カスタムルート数。 | 5 | |
vpc_quota_vpn_custom_route_entry | VPN ゲートウェイを指す最大カスタムルート数。 | 50 | |
なし | ルートテーブルごとのタグ。 | 20 | いいえ。 |
VPC ごとの vRouter。 | 1 | ||
TR 接続を指すルート。 | 600 |
制限事項
ルートテーブルの制限事項
vSwitch は必ず 1 つのルートテーブルに関連付ける必要がありますが、1 つのルートテーブルは複数の vSwitch に関連付けることができます。
カスタムルートテーブルは削除できますが、システムルートテーブルは削除できません。
ルートの制限事項
静的ルートの制限事項:
システムルートを手動で作成または削除することはできません。
Alibaba Cloud サービス用の 100.64.0.0/10 システムルートよりも具体的であるが、同一ではない宛先 CIDR ブロックを持つカスタムルートを作成できます。これらのルートを設定する際は注意が必要です。設定を誤ると、一部の Alibaba Cloud サービスへのアクセスが中断される可能性があります。
ネクストホップが IPv6 ゲートウェイインスタンスであるカスタムルートの場合、宛先 CIDR ブロックは
::/0にのみ設定できます。コンソールには、VPC が Transit Router (TR) または Express Connect Router (ECR) に接続された後にのみ、[ルートアドバタイズステータス] 列が表示されます。
新しいルートの宛先 CIDR ブロックが既存のルートと重複する場合、追加に失敗することがあります。詳細については、ルート優先度をご参照ください。
静的ルート公開の制限事項:
カスタムの
Virtual Private Cloudルートテーブルで設定されたルートエントリは、ECR に公開できません。宛先 CIDR ブロックがプレフィックスリストであるルートエントリは、ECR に公開できません。ネクストホップがルーターインターフェイス (VBR へ) であるアクティブ/スタンバイルートおよび等コストマルチパス (ECMP) ルートは、ECR に公開できません。Virtual Private Cloudルートが ECR に公開された後、そのルートエントリに対して ECMP またはアクティブ/スタンバイルートを設定することはできなくなります。Virtual Private Cloudルートが ECR に公開された後、ルートエントリを変更する場合、ネクストホップは次の表で説明されているように、公開をサポートするタイプにのみ設定できます。次の表は、さまざまなタイプの
ルートエントリのデフォルトのアドバタイズステータスと、公開および取り消し操作がサポートされているかどうかを示しています。
動的ルートの制限事項:
VPC ルートテーブルは、一度に 1 つの動的ルートソースからのみ動的ルートを受信できます。
たとえば、VPC を ECR に関連付けた後、Enterprise Edition TR に接続すると、TR で VPC の ルート同期を有効にしようとしても失敗します。同様に、VPN Gateway を作成して BGP ルートの自動伝播を有効にすると、VPN Gateway によって学習された BGP ルートは VPC のシステムルートテーブルに自動的に伝播されます。この状態では、VPC を ECR に関連付けることはできません。
受信した動的ルートがルートテーブル内の既存のルートと重複する場合、ルート優先度を参照して、どのルートが優先されるかを判断してください。
vSwitch に関連付けられたルートテーブルのみが動的ルートを受信できます。ゲートウェイに関連付けられたルートテーブルは、動的ルートをサポートしていません。
デフォルトでは、1 つのルートテーブルは ECR から最大 200 のアクティブな動的ルートをサポートします。このクォータを超えるルートは受信されますが、非アクティブなままです。クォータを増やすと、新しい制限は次のルート伝播時に適用されます。非アクティブなルートは、受信した順に有効になります。
課金
ルートテーブルは VPC の無料機能です。