|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
仮想プライベートクラウド
|
Kube-OVNを使用するすべての機能は、実験的と見なされます。実験的機能に関する詳細は、機能ラベルを参照してください。 |
仮想プライベートクラウド（VPC）は、IPアドレス、サブネット、ルートテーブル、ファイアウォール、およびクラウドインフラストラクチャ内のゲートウェイに対する完全な制御を提供する論理的に隔離されたネットワークです。VPCは、コンピュート、ストレージ、およびコンテナサービスなどの仮想化リソースの安全でスケーラブルなデプロイメントを可能にします。
以下の表は、VPCの主要なコンポーネントを概説しています：
| コンポーネント | 説明 |
|---|---|
VPC |
ユーザー定義のIP CIDR範囲を持つトップレベルのネットワークスペース |
サブネット |
VPC IPスペースの細分化；パブリックまたはプライベートにすることができます |
ルートテーブル |
VPC内および外部のトラフィックルーティングルールを定義します |
インターネットゲートウェイ |
パブリックサブネットのためのインターネットへのアウトバウンドアクセスを可能にします |
NATゲートウェイ |
プライベートサブネットがインターネットにアクセスできるようにします（アウトバウンドのみ） |
セキュリティグループ |
インスタンスごとにインバウンドおよびアウトバウンドトラフィックを制御する仮想ファイアウォール |
VPCピアリング |
異なるVPCまたはオンプレミスネットワーク間のオプションのピアリングまたはハイブリッド接続 |
SUSE VirtualizationとKube-OVN統合アーキテクチャ
以下の図は、SUSE Virtualization内でVPC、サブネット、オーバーレイネットワーク、および仮想マシンがどのように論理的に接続されているかを示しています。このアーキテクチャは、インターネットに接続されたトラフィックと内部リソースを分離するために、パブリックおよびプライベートサブネットを含んでいます。さらに、このアーキテクチャは、クラスター全体でスケーラブルで隔離されたL3およびL2ネットワーク構造を可能にします。
[ VPC: vpc-1 ]
│
┌─────────────────────┴─────────────────────┐
│ │
[ Subnet: vswitch1-subnet ] [ Subnet: vswitch2-subnet ]
CIDR: 172.20.10.0/24 CIDR: 172.20.20.0/24
Gateway: 172.20.10.1 Gateway: 172.20.20.1
│ │
[ Overlay Network: vswitch1 ] [ Overlay Network: vswitch2 ]
│ │
┌────────┴────────┐ ┌────────┴────────┐
│ │ │ │
[VM: vm1-vswitch1] [VM: vm2-vswitch1] [VM: vm1-vswitch2]
IP: 172.20.10.X IP: 172.20.10.Y IP: 172.20.20.Z
| コンポーネント | プラットフォーム | 論理的責任 |
|---|---|---|
Kube-OVN |
最上位のL3ドメイン、サブネットグループを管理します。 |
|
Kube-OVN |
CIDR割り当て、ルーティング、ゲートウェイ、ファイアウォールルール |
|
SUSE Virtualization |
L2仮想スイッチ（OVSブリッジ）、サブネットにマッピングされています。 |
|
SUSE Virtualization |
コンピュートワークロードを実行し、オーバーレイネットワークに接続されています。 |
このアーキテクチャには、以下の主要な特性があります：
-
Kube-OVNはVPCとそのサブネットを作成します。
各サブネットにはCIDRとゲートウェイIPが含まれ、オーバーレイネットワーク（プロバイダーとして）にバインドされます。Kube-OVNは、サブネットとオーバーレイネットワークの間に一対一のマッピングを強制し、あいまいなルーティング、トラフィックの衝突、および分離の問題を回避します。
-
SUSE Virtualizationはオーバーレイネットワークを定義します。
各オーバーレイネットワークはKube-OVNのプロバイダーと見なされます。SUSE Virtualization UIでサブネットを作成するときは、*Subnet:Create*画面の*Provider*リスト（タイプ：
OverlayNetwork）でこれらのオーバーレイネットワークを選択できます。 -
SUSE Virtualizationはオーバーレイネットワークに接続された仮想マシンをプロビジョニングします。
各仮想マシンは、起動後にKube-OVN IPAMを使用してIPアドレスを要求します。仮想マシンは、関連するサブネットからIPアドレス、ゲートウェイ、およびルーティング情報を受け取ります。
-
Kube-OVNはすべてのL3ロジック（ルーティング、NAT、VPCピアリング、および分離）を処理します。
SUSE Virtualizationはコンピュートとネットワーク接続に純粋に焦点を当てています。ネットワークポリシーの適用、プライベートサブネット、およびNATエグレスはKube-OVNによって管理されます。
このアーキテクチャは以下の利点を提供します：
-
明確な役割の分離：SUSE Virtualizationは仮想化を処理し、Kube-OVNはSDNを処理します。
-
スケーラビリティ：新しいVPC、サブネット、およびピアリングはSUSE Virtualizationコアに変更を必要としません。
-
Kubernetesネイティブネットワーキング：Kube-OVNはKubernetesと密接に統合されており、CRD、ポリシーなどをサポートしています。
-
分離と監視：Kube-OVNを通じたIP、ACL、およびルーティングの集中管理が実現されています。
VPCおよびサブネットの設定。
VPC設定。
SUSE Virtualizationでは、仮想プライベートクラウド（VPC）はサブネットとトラフィックを管理および分離するのに役立つ論理ネットワークコンテナです。ルーティング、NAT、およびネットワークセグメンテーションを定義します。
SUSE Virtualizationは`ovn-cluster`という名前のデフォルトVPCと、内部Kube-OVN操作用の`ovn-default`および`join`という名前の2つの関連サブネットを提供します。*Virtual Private Cloud*画面で*Create*をクリックすることで追加のVPCを作成できます。
カスタムVPCを作成する際には、トラフィックを誘導するために定義されたルートに関連する設定を構成し、ローカルVPCとリモートVPC間の通信を可能にする接続を有効にする必要があります。以下の表は、*仮想プライベートクラウド*詳細画面の設定を概説しています：
| セクション | 設定 | 説明 |
|---|---|---|
一般情報 |
名前 |
VPCの名前 |
一般情報 |
説明 |
VPCの説明 |
静的ルート タブ |
CIDR |
ルートの宛先IPアドレス範囲（例： |
静的ルート タブ |
次のホップIP |
CIDRのトラフィックを転送するIPアドレス（例：ゲートウェイまたはルーターのIPアドレス） |
VPCピアリング タブ |
ローカル接続IP |
ピアリング接続に使用するローカルVPCのIPアドレス |
VPCピアリング タブ |
リモートVPC |
ローカルVPCとピアリングされているターゲットリモートVPC |
サブネット設定
各サブネットはCIDRブロックとゲートウェイを定義し、SUSE Virtualization オーバーレイネットワーク（仮想スイッチ）にマッピングされます。また、NATおよびアクセスルールの制御も含まれています。
サブネットを作成する際には、使用ケースに関連する設定を構成する必要があります。ほとんどの場合、CIDRブロック、ゲートウェイ、および*プロバイダー*を構成するだけで始めることができます。以下の表は、*サブネット*の詳細画面の設定を示しています：
| セクション | 設定 | 説明 |
|---|---|---|
一般情報 |
名前 |
サブネットの名前 |
一般情報 |
説明 |
サブネットの説明 |
Basic |
CIDRブロック |
サブネットに割り当てられたIPアドレス範囲（例えば、 |
基本 タブ |
プロトコル |
このサブネットで使用されるネットワークプロトコルのバージョン（IPv4またはIPv6） |
基本 タブ |
プロバイダ |
サブネットがバインドされているオーバーレイネットワーク（仮想スイッチ） |
基本 タブ |
仮想プライベートクラウド |
サブネットが属する仮想プライベートクラウド |
基本 タブ |
ゲートウェイ |
サブネット内の仮想マシンのデフォルトゲートウェイとして機能するIPアドレス |
基本 タブ |
プライベートサブネット |
サブネットへのアクセスを制限し、ネットワークの分離を確保する設定 |
基本 タブ |
サブネットを許可 |
プライベートサブネット が有効な場合にサブネットにアクセスできるCIDR |
基本 タブ |
除外IP |
仮想マシンに自動的に割り当てるべきでないIPアドレスのリスト |
作成された各サブネットには、サブネットからVPC外の宛先に向かうトラフィックのためにネットワークアドレス変換（NAT）を有効にする設定である<<`natOutgoing` setting,natOutgoing>>があります。デフォルトでこの設定はオフに設定されています。これを有効にするには、サブネットのYAML設定を編集し、値を`natOutgoing: true`に設定する必要があります。
デフォルトでは、異なるVPC内のサブネットは直接通信できません。それらの間で安全で制御された通信を可能にするには、VPCピアリング接続を確立する必要があります。それがないと、各VPC内のサブネットトラフィックは完全に分離されたままになります。
|
VPCピアリング接続はカスタムVPC間でのみ確立できます。 |
VPCの作成
VPCを作成して構成するために、以下の手順を実行してください。
-
kubeovn-operatorを有効にします。
kubeovn-operatorアドオンは、SUSE VirtualizationクラスターにKube-OVNをデプロイします。
-
作成する予定の各サブネットに対して、別々のオーバーレイネットワークを作成する必要があります。
-
VPCを作成します。
-
*ネットワーク → バーチャルプライベートクラウド*に移動し、*作成*をクリックします。
-
*バーチャルプライベートクラウド:作成*画面で、VPCの一意の名前を指定します。
-
［作成］をクリックします。
-
-
サブネットを作成します。
-
*ネットワーク → バーチャルプライベートクラウド*に移動します。
-
作成したVPCを見つけて、*サブネットを作成*をクリックします。
-
*サブネット:作成*画面で、環境に関連する設定を構成します。
各サブネットを専用のオーバーレイネットワークにリンクする必要があります。*プロバイダー*フィールドでは、SUSE Virtualization UIは他のサブネットにリンクされていないオーバーレイネットワークのみを表示し、自動的に1対1のマッピングを強制します。
-
*YAMLとして編集*をクリックします。
-
`spec`の下に`enableDHCP: true`を追加します。
これにより、サブネットに接続された仮想マシンが正しいデフォルトルートオプションを取得できるようになります。
-
［作成］をクリックします。
-
-
仮想マシンを作成します。
-
各仮想マシンに関連する設定を設定します。
*ネットワーク*タブで、*ネットワーク*フィールドに正しいオーバーレイネットワークを選択する必要があります。
-
［作成］をクリックします。
仮想マシンは、接続されているサブネットからIPアドレスを取得します。
-
*⋮ → YAMLを編集*を選択します。
-
`spec.domain.devices.interface.binding.name`の値を`managedtap`に変更します。
これにより、仮想マシンがKubeVirtのデフォルトDHCPサーバーを使用するのではなく、サブネットから正しいDHCPオプションを取得できるようになります。
このステップを実行しないと、仮想マシンにはデフォルトルートがありません。ゲストオペレーティングシステムでデフォルトルートが正しく構成されるまで、外部の宛先や異なるサブネット上の仮想マシンにアクセスしようとすると失敗します。
詳細については、オーバーレイネットワークの制限を参照してください。
-
各仮想マシンを再起動します。
-
サンプルVPC構成と検証
-
次の設定でオーバーレイネットワークを作成します:
-
名前:
vswitch1とvswitch2 -
タイプ:
OverlayNetwork
-
-
`vpc-1`という名前のVPCを作成します。
-
次の設定で`vpc-1`に2つのサブネットを作成します:
名前 CIDR プロバイダ ゲートウェイIP vswitch1-subnet172.20.10.0/24default/vswitch1172.20.10.1vswitch2-subnet172.20.20.0/24default/vswitch2172.20.20.1 -
次の設定で3つの仮想マシンを作成します:
-
名前:
vm1-vswitch1,vm2-vswitch1, およびvm1-vswitch2 -
Basics タブ
-
CPU:
1 -
Memory:
2
-
-
Volumes タブ
-
Image Volume:クラウドイメージ（例えば、
noble-server-cloudimg-amd64）
-
-
Networks タブ
-
Network:
default/vswitch1
-
-
Advanced Options タブ
users: ` `- name: ubuntu ` `groups: [ sudo ] ` `shell: /bin/bash ` `sudo: ALL=(ALL) NOPASSWD:ALL ` `lock\_passwd: false
仮想マシンが実行を開始すると、ノードはNTPサーバー
0.suse.pool.ntp.orgとIPアドレスを表示します。
-
-
vm1-vswitch1とvm1-vswitch2のシリアルコンソールを開き、次のコマンドを使用してそれぞれにデフォルトルートを追加します（存在しない場合）：-
vm1-vswitch1(172.20.10.6):#sudo ip route add default via 172.20.10.1 dev enp1s0
-
vm1-vswitch2(172.20.20.3):#sudo ip route add default via 172.20.20.1 dev enp1s0
仮想マシンが不明なネットワーク（ローカルサブネットにない）にトラフィックを送信したい場合、トラフィックは接続されたサブネットに設定された指定されたゲートウェイIPに転送される必要があります。この例では、
vm1-vswitch1は172.20.10.1経由でトラフィックを転送する必要があり、vm1-vswitch2は172.20.20.1経由でトラフィックを転送する必要があります。両方の仮想マシンはネットワークインタフェースenp1s0を使用します。
-
-
pingコマンドを使って接続性を確認します。-
vm1-vswitch1(172.20.10.6) を使用してvm1-vswitch2(172.20.20.3) に ping を実行します。 -
vm1-vswitch2(172.20.20.3) を使用してvm1-vswitch1(172.20.10.6) に ping を実行します。vm1-vswitch1とvm1-vswitch2は同じサブネット上にあるため、デフォルトルートの設定なしで相互に通信できます。ping コマンドを実行する前に仮想マシンにデフォルトルートが存在しない場合、コンソールにはメッセージ
ping: connect: が表示されます。ネットワークに到達できません。
-
プライベートサブネット設定
プライベートサブネット 設定がサブネットで有効になっている場合、デフォルトでは同じ VPC 内の他のサブネットと通信できません。クロスサブネットトラフィックは、他のサブネットの CIDR ブロックをプライベートサブネットの 許可されたサブネット リストに追加した場合にのみ許可されます。
プライベートサブネット 設定には以下の利点があります：
-
細かいネットワークセグメンテーション（マイクロセグメンテーション）
-
VPC 内での強化されたネットワーク隔離と潜在的な攻撃面の削減
-
VPC 内の機密または重要なリソースへの不正アクセスの防止
-
許可されたサブネット リストを介した制御された選択的クロスサブネット通信
サンプルプライベートサブネット検証
-
*ネットワーク → バーチャルプライベートクラウド*に移動します。
-
vswitch1-subnetを見つけて、次に ⋮ → 設定を編集 を選択します。 -
プライベートサブネット 設定を有効にします。
-
vm1-vswitch1(172.20.10.6) のシリアルコンソールを開き、次にvm1-vswitch2(172.20.20.3) に ping を実行します。ping の試行は失敗します。なぜなら
vm1-vswitch1は孤立しているからです。vswitch1-subnetに プライベートサブネット 設定を有効にすると、vm1-vswitch1は他のサブネットの仮想マシンと通信できなくなります。 -
バーチャルプライベートクラウド 画面に戻り、
vswitch1-subnetを見つけて、次に ⋮ → 設定を編集 を選択します。 -
172.20.20.0/24を 許可されたサブネット フィールドに追加します。 -
vm1-vswitch1(172.20.10.6) のシリアルコンソールを開き、次にvm1-vswitch2(172.20.20.3) に ping を送信します。ping の試行は成功しました。
natOutgoing 設定
natOutgoing 設定は、サブネットを出て VPC の外部に向かうトラフィックのためにネットワークアドレス変換 (NAT) を有効にします。デフォルトでこの設定はオフに設定されています。これを有効にするには、サブネットの YAML 設定を編集し、値を natOutgoing: true に設定する必要があります。
サンプル natOutgoing 設定と検証
-
オーバーレイネットワークを作成 するための設定は次のとおりです：
-
名前:
vswitch-external -
タイプ：
OverlayNetwork
-
-
ovn-clusterVPC で、次の設定のサブネットを作成します：-
名前:
external-subnet -
CIDR ブロック：
172.20.30.0/24 -
プロバイダー:
default/vswitch-external -
ゲートウェイ IP：
172.20.30.1
-
-
次の設定で仮想マシンを作成します：
-
名前:
vm-external -
Basics タブ
-
CPU:`1`
-
メモリ：
2
-
-
Volumes タブ
-
Image Volume:クラウドイメージ（例：
noble-server-cloudimg-amd64）
-
-
Networks タブ
-
ネットワーク:
default/vswitch-external
-
-
Advanced Options タブ
users: ` `- name: ubuntu ` `groups: [ sudo ] ` `shell: /bin/bash ` `sudo: ALL=(ALL) NOPASSWD:ALL ` `lock\_passwd: false
-
-
vm-external(172.20.30.2) のシリアルコンソールを開き、次に8.8.8.8に ping を送信します。コンソールにはメッセージ
ping: 接続:ネットワークに接続できません。 -
次のコマンドを使用してデフォルトルートを追加します：
#sudo ip route add default via 172.20.30.1 dev enp1s0
再度、pingの試行が失敗します。
-
プライベートクラウド 画面に移動します。
-
`外部サブネット`を見つけて、*⋮ → 設定*を選択します。
-
*YAMLとして編集*をクリックします。
-
`natOutgoing`フィールドを見つけて、値を`true`に変更します。
-
［保存］をクリックします。
-
vm-external(172.20.30.2) のシリアルコンソールを開き、次に8.8.8.8に ping を送信します。ping の試行は成功しました。
VPCピアリング
VPCピアリングは、異なるVPC内の仮想マシンが_プライベートIPアドレス_を使用して通信できるネットワーク接続です。
各VPCは、独自のCIDRブロック、ルーティングテーブル、および隔離境界を持つ別々のネットワークネームスペースです。VPCピアリングがない場合、仮想マシンは同じSUSE Virtualizationクラスター内にホストされていても隔離されます。ピアリング接続が確立されると、仮想マシンがプライベートに通信できるようにルーティングルールが自動的に更新されます。
VPCピアリングは次の利点を提供します：
-
VPCは論理的および管理的に隔離されたままです。これは、強力なネットワーク隔離とオプションの接続を必要とするマルチテナントセットアップに最適です。チーム、機能、または環境（例えば、開発と本番）によってワークロードを整理できます。
-
VPC間のトラフィックはパブリックインターネットを通過せず、露出を減らします。ルートテーブルやファイアウォールルールを使用して、ネットワークアクセスを厳密に制御することもできます。
-
トラフィックをインターナルクラウドネットワーク内に保つことは、パフォーマンスの向上だけでなく、コスト削減にもつながり、パブリックインターネットやVPNを利用する場合に比べて大きな利点を提供します。
次の図は、Kube-OVN内のVPCとサブネットがオーバーレイネットワークおよびSUSE Virtualization内の仮想マシンにどのようにマッピングされるかを示しています。このアーキテクチャにより、クラスター全体でスケーラブルで隔離されたL3およびL2ネットワーク構造を作成できます。
┌───────────────────────────────────────────┐
│ Kube-OVN │
│ (SDN Controller / IPAM) │
└───────────────────────────────────────────┘
│
┌──────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────┐
│ │ │
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ VPC: vpc-1 │ │VPC: vpcpeer-1│ ◀────────── peering ──────────▶ │VPC: vpcpeer-2│
└──────────────┘ └──────────────┘ └──────────────┘
│ │ │
▼ ▼ ▼
┌──────────────────────────────┐ ┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Subnet: vswitch1-subnet │ │ Subnet: vswitch3-subnet │ │ Subnet: vswitch4-subnet │
│ CIDR: 172.20.10.0/24 │ │ CIDR: 10.0.0.0/24 │ │ CIDR: 20.0.0.0/24 │
│ Gateway: 172.20.10.1 │ │ Gateway: 10.0.0.1 │ │ Gateway: 20.0.0.1 │
└──────────────────────────────┘ └──────────────────────────────┘ └──────────────────────────────┘
│ (1:1 mapping - Provider binding) │ │
▼ ▼ ▼
┌──────────────────────────────┐ ┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Overlay: vswitch1 │ │ Overlay: vswitch3 │ │ Overlay: vswitch4 │
│ Type: OverlayNetwork │ │ Type: OverlayNetwork │ │ Type: OverlayNetwork │
└──────────────────────────────┘ └──────────────────────────────┘ └──────────────────────────────┘
│ │ │
▼ ▼ ▼
┌──────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ VM: vm1-vswitch1 │ │ VM: vm1-vswitch3 │ │ VM: vm1-vswitch4 │
│ IP: 172.20.10.5 │ ◀ ──────── X ──────── ▶ │ IP: 10.0.0.2 │ ◀── Connected via ──▶ │ IP: 20.0.0.2 │
└──────────────────────┘ └──────────────────────┘ vswitch (overlay) └──────────────────────┘
▲
│
VM launched and managed by {harvester-product-name}
VPCピアリング構成の例
-
例1:成功したクロスVPC通信
VPC名 VPC CIDR サブネット 静的ルート vpcpeer-110.0.0.0/1610.0.0.0/2420.0.0.0/16 → 169.254.0.2vpcpeer-220.0.0.0/1620.0.0.0/2410.0.0.0/16 → 169.254.0.1両方のサブネットがそれぞれのVPC CIDR内にあるため、ルーティングは正しく機能し、VPC間の通信は成功します。
-
例2:ルーティング設定の問題によるVPC間通信の失敗
VPC名 VPC CIDR サブネット 静的ルート vpcpeer-110.0.0.0/1610.1.0.0/2420.0.0.0/16 → 169.254.0.2vpcpeer-220.0.0.0/1620.1.0.0/2410.0.0.0/16 → 169.254.0.1ターゲットサブネットのIPアドレス（例えば、
10.1.0.2`と`20.1.0.2）は、ルーティング設定によって_カバーされていない_ため、VPC間通信が失敗します。
|
次のことを確認します。
サブネットがVPC CIDRによってカバーされていない特定の範囲を使用している場合、関連する静的ルートはそのサブネットに到達できません。 |
VPCピアリングの前提条件と設定に関する詳細は、Kube-OVNのドキュメントのhttps://kubeovn.github.io/docs/v1.13.x/en/vpc/vpc-peering[VPCピアリング]を参照してください。
サンプルVPCピアリング設定と検証
-
2つのオーバーレイネットワークを作成し、次の設定を行います：
-
名前:
vswitch3`および`vswitch4 -
タイプ：
OverlayNetwork
-
-
2つのVPCを作成し、名前を`vpcpeer-1`および`vpcpeer-2`とします。
SUSE Virtualizationは、サブネット作成の準備が整った2つの孤立したネットワーク空間を作成します。
-
次の設定で各VPCに1つのサブネットを作成します：
VPC名 サブネット名 CIDRブロック プロバイダ ゲートウェイIP vpcpeer-1subnet110.0.0.0/24default/vswitch310.0.0.1vpcpeer-2subnet220.0.0.0/24default/vswitch420.0.0.1 -
両方のVPCの設定を編集します。
-
vpcpeer-1セクション 設定 値 VPC Peering タブ
ローカル接続IP
169.254.0.1/30VPC Peering タブ
リモートVPC
vpcpeer-2静的ルート タブ
CIDR
20.0.0.0/16静的ルート タブ
次のホップIP
169.254.0.2 -
vpcpeer-2セクション 設定 値 VPC Peering タブ
ローカル接続IP
169.254.0.2/30VPC Peering タブ
リモートVPC
vpcpeer-1静的ルート タブ
CIDR
10.0.0.0/16静的ルート タブ
次のホップIP
169.254.0.1
-
-
仮想マシンを作成します。
Unschedulableエラーは通常、メモリ不足を示します。新しい仮想マシンを作成する前に、他の仮想マシンを停止する必要があります。 -
vm1-vpcpeer1とvm1-vpcpeer2のシリアルコンソールを開き、次のコマンドを使用して（存在しない場合は）それぞれにデフォルトルートを追加してください。-
vm1-vpcpeer1(10.0.0.2)#sudo ip route add default via 10.0.0.1 dev enp1s0
-
vm1-vpcpeer2(20.0.0.2)#sudo ip route add default via 20.0.0.1 dev enp1s0
-
-
コマンド
pingを使用して、VPC間の通信をテストしてください。-
vm1-vpcpeer1(10.0.0.2) を使用してvm1-vpcpeer2(20.0.0.2) に ping を送信してください。 -
vm1-vpcpeer2(20.0.0.2) を使用してvm1-vpcpeer1(10.0.0.2) に ping を送信してください。異なるVPC内の仮想マシン間の通信は、トラフィックがリモートVPCに転送される方法を定義する静的ルートに依存しています。これらのルートが正しく機能するためには、静的ルートの宛先CIDRがリモートVPCのメインCIDR範囲内に含まれている必要があります。
-
ローカル接続IPおよびCIDR設定
| 質問 | 答え |
|---|---|
Local Connect IP の値はCIDRブロックですか？ |
はい（たとえば、 |
推奨されるサブネットサイズは何ですか？ |
|
プライベートアドレス（RFC 1918）はピアリングリンクに使用できますか？ |
お勧めしません |
`169.254.x.x`を使用する理由は？ |
リンクローカル、安全、インターネット経由ではルーティングされず、広く使用されています |
-
質問:*Local Connect IP* の値はCIDRブロックですか？
回答:はい。単一のIPアドレスの代わりにCIDRブロック（例えば、
169.254.0.1/30）を指定する必要があります。CIDRは、1つのIPアドレスがローカルVPCによって使用され、もう1つがリモートVPCによって使用される*ポイントツーポイントネットワーク*を定義します。例：
/30`ブロック（`169.254.0.0/30）IP Address 目的 169.254.0.0
ネットワークアドレス
169.254.0.1
VPC Aによって使用される
169.254.0.2
VPC Bによって使用される
169.254.0.3
ブロードキャスト（オプション）
-
質問:推奨されるサブネットサイズは何ですか？
回答：
/30`は*正確に2つの使用可能なIPアドレス*を提供し、ポイントツーポイントVPCピアリングの要件を満たします。より大きなブロック（例えば、/28`と`/29`）を使用する必要はなく、むしろ無駄と見なされることさえあります。CIDR 使用可能なIP 推奨ですか？ /302
はい
/296
いいえ
/2814
いいえ
-
質問:プライベートアドレスの代わりに`169.254.x.x/30`を使用する理由は？
回答：
169.254.0.0/16`はRFC 1918プライベートアドレス空間（`10.0.0.0/8,172.16.0.0/12`および`192.168.0.0/16）の*一部ではありません*。RFC 3927は、内部通信、自動IP設定、ポイントツーポイントルーティングを目的とした`169.254.0.0/16`を*リンクローカルアドレス空間*として定義しています。`169.254.x.x/30`には以下のような利点があります：
-
公共インターネットにルーティングできない
-
内部利用に安全です
-
AWSやAlibaba Cloudを含むクラウドプラットフォームで、VPCピアリングやメタデータアクセスなどの内部ネットワーキング目的で一般的に使用されています。
-