サイト間VPNゲートウェイに関する よくある質問
IBM Cloud® の VPN for VPC を使用していると、以下のよくある質問が生じる可能性があります。
IBM Cloud、VPCではどのような種類のVPN接続をサポートしていますか？
IBM Cloud は、VPC用に以下のタイプのVPNをサポートしています：
- サイト間VPN ：ネットワーク間の接続に使用される。
- クライアント・ツー・サイトVPN ：個人ユーザーのセキュアなリモート・アクセスに使用される。
VPC（サイト間）の IBM Cloud VPN とは何ですか？
IBM Cloud VPN for VPCは、 IBM Cloud Virtual Private Cloud (VPC)とオンプレミス環境などの他のプライベートネットワークとの間に、安全で暗号化された接続性を提供します。 インターネット上でIPsecトンネルを使用し、転送中のデータを保護する。 詳細については、 サイト間VPNゲートウェイ および IBM Cloud VPN for VPC製品ページをご覧ください。
VPN for VPC, Transit Gateway, Direct Link の違いは何ですか？
次の表は、 VPN for VPC、 Transit Gateway、 Direct Link の違いを示している：
| サービス | 目的 | 以下に最適 |
|---|---|---|
| VPN for VPC | インターネットによる安全な接続性 | ハイブリッドクラウド、バックアップリンク、迅速な展開 |
| Transit Gateway | VPC間ルーティング | マルチVPCオーケストレーション IBM Cloud |
| Direct Link | オンプレミスからVPCへの専用プライベート接続 | 広帯域、低遅延のプライベート接続 |
なぜクライアントからサイトへのVPNではなく、サイトからサイトへのVPNを使用する必要があるのですか？
サイト間VPNを使用して、 IBM Cloud VPC と他のプライベートネットワーク間のデータ転送を保護し、ハイブリッドクラウドアーキテクチャとネットワーク間通信をサポートします。 個人ユーザーが遠隔地から安全で暗号化されたアクセスが必要な場合は、クライアント・ツー・サイトVPNを使用します。これは、リモートワークのシナリオや第三者の請負業者に最適です。
IBM Cloud VPC、どのようなサイト間VPNをサポートしていますか？
IBM Cloud VPC は、以下のタイプのサイト間VPNをサポートしている：
典型的な IBM Cloud サイト間VPNの使用例とは？
IBM Cloud site-to-site VPN for VPC ハイブリッドクラウドの拡張、バックアップ接続、リージョン間VPC通信に役立つ。 サイト間 VPN の使用例を 参照。
サイト間 VPN for VPC、バックアップ接続として機能しますか？
そう、 VPN for VPC は、 Direct Link のバックアップとして、あるいは、 Transit Gateway と並ぶセカンダリー・コネクティビティとして一般的に使用されている。 高可用性 」を参照。
IBM Cloud サイト間VPNはどのように私のデータを保護しますか？
VPN for VPC 高度な IPsec/IKEv2 高度な暗号化アルゴリズムを使用し、転送中のデータの機密性と完全性を保証します。 政策交渉についてもっと知る
VPNはネットワーク速度に影響しますか？
VPNの暗号化はオーバーヘッドを最小限に抑える。 IBM Cloud VPNは、信頼性の高いパフォーマンスを実現するために最適化されますが、実際の速度はお客様のネットワーク状況や設定によって異なります。
IBM Cloud VPN 接続に関する問題のトラブルシューティング方法は？
IBM Cloud VPN 接続の問題をトラブルシューティングするには、VPNダッシュボードのトンネル・ステータスを確認し、ルートを検証し、アクセスおよびファイアウォール・ルールを見直します。 詳細については、 サイト間のトラブルシューティングを 参照してください。 IKE および IPsec ポリシーでネゴシエート、提案、および受信されたアルゴリズムに関する問題のトラブルシューティングについては、「 IPsec ログを確認するには?
VPNサービスが利用できない場合の通知はありますか？
VPNサービスが利用できないことを知るには、 IBM Cloud 標準のメンテナンスイベント通知プロセスを使用してください。 IBM Cloud ステータスのページを 参照。
VPCにサイト間VPNを設定するには、まず何から始めればよいですか？
VPCのサイト間VPNの設定を始めるには、VPNゲートウェイを作成する必要があります。 VPNゲートウェイの作成 」を参照してください。
IBM Cloud VPC、サイト間VPN接続はいくつまで設定できますか？
サイト間VPNの接続数を決定するには、 VPNクォータを 参照してください。
IBM Cloud site-to-site VPN for VPC の価格詳細はどこで確認できますか？
IBM Cloud サイト間 VPN for VPC の価格詳細については、 「価格」タブを ご覧ください。
IBM Cloud VPN、どのようなセキュリティのベストプラクティスに従うべきでしょうか？
強力な暗号化を使用し、定期的に設定を更新し、厳格なアクセス制御を適用する。
VPN ゲートウェイを作成するときに同時に VPN 接続を作成することはできますか?
IBM Cloud コンソールでは、ゲートウェイと接続を同時に作成できます。 API または CLI を使用する場合は、VPN ゲートウェイを作成した後で VPN 接続を作成する必要があります。
VPN 接続が関連付けられている VPN ゲートウェイを削除した場合、その接続はどうなりますか?
VPN 接続は VPN ゲートウェイと共に削除されます。
VPN ゲートウェイまたは VPN 接続を削除した場合、IKE ポリシーまたは IPsec ポリシーは削除されますか?
いいえ、IKEとIPsecポリシーは複数の接続に適用できるため、削除されません。
サイト間VPN接続におけるIKEとIPsecの暗号化アルゴリズムはどのように選択されますか？
IKE または IPsec ポリシーで複数のアルゴリズムを選択する場合、最終的な選択は、どちらの側がアルゴリズムを選択するか、およびアルゴリズムが評価される順序に依存します。 順序の違いは、異なる交渉結果につながる可能性がある。
- IBM Cloud がVPN接続を開始すると、設定された順序でアルゴリズムを送信し、最終的な選択はピアが行う。 例えば、 IBM Cloud が
aes128,aes256を提案し、ピア がaes256,aes128を提案した場合、ピアの実装によってはaes128またはaes256のいずれかが選択されるかもしれない。 - IBM Cloud がレスポンダーである場合、それ自身が設定した順番に基づいて、最初のマッチングアルゴリズ ムを選択する。 例えば、 IBM Cloud が
aes128,aes256で構成され、ピアからaes256,aes128が提案された場合、aes128が選択される。
一貫したアルゴリズム選択を保証するために、同一の IKE および IPsec アルゴリズムを構成し、 IBM Cloud VPN ゲートウェイとピアゲートウェイの両方で同じ優先順位を維持します。
IPsecのログを確認するには？
ネゴシエートされた、提案された、および受信されたアルゴリズムの IPsec ログを見るには、以下の手順に従う：
- まず、VPNインスタンスにロギング・インスタンスを設定する。 詳細については、 IBM Cloud Logs Routingサービスの設定を 参照してください。
- ロギングインスタンスをセットアップした後、VPNによって生成されるIPsecログエントリにアクセスして確認することができます。 ログのフォーマットと利用可能なフィールドについては、 VPN for VPC のログを 参照。
接続のデバッグでは、ピアから受信したプロポーザルに、 IBM 側の IKE および IPsec ポリシーと一致するアルゴリズムが少なくとも 1 つあることを確認する。 ピアと IBM Cloud コンフィギュレーションの間に一致するアルゴリズムが存在しない場合、接続の確立に失敗する。
VPN ゲートウェイが存在するサブネットを削除すると、そのゲートウェイはどうなりますか?
VPNゲートウェイを含む仮想サーバーインスタンスが存在する場合、サブネットは削除できません。
デフォルトの IKE ポリシーと IPsec ポリシーはありますか?
はい。 ポリシー ID (IKE または IPsec) を指定せずに VPN 接続を作成すると、オートネゴシエーションが使用されます。
VPN ゲートウェイをプロビジョニングするときにサブネットを選択する必要があるのはなぜですか?
IBM Cloud で VPN ゲートウェイをプロビジョニングする際にサブネットを選択する必要があります。これは、ゲートウェイが VPC サブネット内に配置されて接続を確立するためです。 ルート・ベースのVPNは、すべてのゾーンにまたがる接続をサポートできるが、ゲートウェイ自体は、高可用性と自動メンテナンスを提供するために、選択したサブネットに4つの利用可能なプライベートIPアドレスを必要とする。 VPNゲートウェイには、サイズ16の専用サブネットを使用し、サブネット・プレフィックスの長さが28より短いか等しいのがベストです。
VPN ゲートウェイのデプロイに使用したサブネットで ACL を使用する場合は、何をする必要がありますか?
管理トラフィックと VPN トンネル・トラフィックを許可するために、必ず ACL ルールを設定してください。 詳細については、 VPNで使用するネットワークACLの設定を 参照してください。
オンプレミスのプライベート・ネットワークと通信する必要があるサブネットで ACL を使用する場合は、何をする必要がありますか?
VPC 内の仮想サーバー・インスタンスとオンプレミスのプライベート・ネットワークの間のトラフィックを許可する ACL ルールを設定する必要があります。 詳しくは、 VPNで使用するACLの設定を 参照してください。
VPN for VPC では高可用性構成はサポートされますか?
はい。 VPN for VPC は、ポリシー・ベースのVPNではActive-Standby構成で、スタティック・ルート・ベースのVPNではActive-Active構成で、高可用性をサポートしています。
SSL VPN を利用できるプランはありますか?
いいえ。IPsec サイト間のみがサポートされています。
サイト間 VPNaaS のスループットに上限はありますか?
はい。スループットは、VPNモード、トラフィック分散、暗号化設定、計算能力、ネットワーク条件、ピアデバイスの容量など、さまざまな要因に依存します。 最適な条件下では、 _トラフィックの分散_オプションを有効にしてアクティブ・アクティブ・モードで展開したルートベースVPNは、両方のトンネルで最大2Gbpsの集約スループットをサポートできます（ IBM 社内のベンチマークテストに基づくもので、お客様の環境で保証される制限ではありません）。 VPNスループットの詳細については、 サイト間VPNのスループットとパフォーマンスの向上を 参照してください。
VPNaaS で事前共有鍵 (PSK) 認証と証明書ベースの IKE 認証はサポートされていますか?
PSK 認証のみがサポートされています。
VPN for VPC を IBM Cloud クラシック・インフラストラクチャーの VPN ゲートウェイとして使用できますか?
はい。 古典的なネットワークをVPCに接続する方法として推奨されるのは、. IBM Cloud Transit Gateway. クラシック・インフラストラクチャへのアクセスの設定 」を参照。
サイト間VPN間のリキーの衝突とは何ですか？
リキーの衝突は、両方のVPNピアが同時にリキーを開始しようとしたときに発生します。これは、ネゴシエーションが衝突したり、トンネルが不安定になったり、接続が切断されたりする原因になります。 この問題は、 IKEv1 でよく見られる。なぜなら、双方が一致した鍵の寿命を使わなければならず、プロトコルには衝突を処理するメカニズムが欠けているため、信頼性が低いからだ。 IKEv1 も古いので、できれば避けたい。 しかし、 IKEv2 は非対称的な鍵の寿命をサポートし、同時に行われる鍵の再取得を優雅に処理する。
IKEv1 を使用する場合は、鍵再設定が競合すると IKE/IPsec セキュリティー・アソシエーション (SA) が削除されます。 IKE/IPsec SA を再作成するには、接続管理状態を down に設定してから、再び up にします。 リキーの衝突を最小限に抑え、安定したパフォーマンスを維持するには、 IKEv2 を使用する。
ポリシー・ベースの VPN で VPC サイドからオンプレミス・サイドにすべてのトラフィックを送信するにはどうすればよいですか?
VPC側からオンプレミス側にすべてのトラフィックを送信するには、接続作成時にピアのCIDRを 0.0.0.0/0。
接続が正常に作成されると、VPNサービスは <VPN gateway private IP> ルートを通じてCIDR 0.0.0.0/0 をVPCのデフォルト・ルーティング・テーブルに追加します。 ただし、この新しい経路により、ルーティングの問題が発生する可能性があります。例えば、異なるサブネット内の仮想サーバーが相互に通信できない場合や、VPN ゲートウェイがオンプレミスの VPN ゲートウェイと通信しない場合などです。
ルーティングの問題のトラブルシューティングについては、「 VPNゲートウェイや仮想サーバーインスタンスが通信しないのですが？
スタティック・ルート・ベースとダイナミック・ルート・ベースのVPN接続タイプの違いは何ですか？
スタティック・ルーティング接続は、ルート広告にBGPを使用しないため、 Transit Gateway 、オンプレミス・ネットワークにルートを広告できない。 この接続では、すべてのルートを手動で作成し管理する必要があるのに対し、ダイナミック接続では、最初のプロビジョニングとアタッチメントの後、手動による設定は必要ない。
ルート・ベースVPNゲートウェイを作成する際、ダイナミック・ルーティングはサポートされていますか？
はい、ダイナミックVPN接続はルートベースVPNゲートウェイによってサポートされています。 ルートベースVPNを作成するには、 VPNゲートウェイの作成を 参照し、接続タイプにダイナミックを選択してください。
ダイナミック・ルーティング接続を機能させるには、 Transit Gateway
はい、ダイナミック・ルーティング接続を正しく機能させるには、 Transit Gateway 。 Transit Gateway がなければ、IPsec 接続が確立されていても、VPN ゲートウェイとオンプレミスネットワーク間の通信は機能しない。
なぜダイナミック・ルート・ベースの接続に Transit Gateway
Transit Gateway は、ネットワーク内のすべての接続の中心的なハブとして機能するため、ダイナミック・ルーティングには不可欠です。 Transit Gateway は、VPN 接続を含むすべてのスポークのルーティングを管理します。 Transit Gateway 、スポーク間のトラフィックを促進し、ルーティングするハブ Transit Gateway に依存しているため、スポークは互いに通信することができない。
ダイナミックルートベースのVPN接続で、複数のトランジットゲートウェイにVPNを接続できますか？
いいえ、各VPNゲートウェイは1つの Transit Gateway にのみ接続できます。
既存の Transit Gateway 、ダイナミックルーティング用のルートベースVPNに接続できますか？
はい、既存の Transit Gateway 、ダイナミックルーティング用のルートベースVPNにアタッチできます。 新たに Transit Gateway を作成する必要はない。
ASNとは何ですか？なぜダイナミック・ルーティングにASNが必要なのですか？
ASN（Autonomous System Number）は、BGP（Border Gateway Protocol）でAS（Autonomous System）を表すために使用される一意の識別子です。 IPsec接続におけるパブリックIPアドレスと同様の機能を持ち、ネットワーク内のデバイスを識別するためのキー属性として機能する。 ネットワーク内の各デバイスは特定のASNに割り当てられており、有効なASNがなければ、VPNゲートウェイはネットワーク内の他のデバイスとBGPセッションを正常に確立することができません。
アドバタイズドCIDRの用途は？
アドバタイズドCIDRは、VPNから到達可能で、オンプレミスのネットワークにアドバタイズされる静的IPアドレス範囲です。 これらのCIDRは、 Secrets Manager エンドポイントや Cloud Object Storage エンドポイントなど、 Transit Gateway に直接接続できないプライベート・エンドポイントに便利である。 これらのCIDRを IBM VPN、オンプレミスネットワークにアドバタイズすることで、オンプレミス環境内のあらゆるリソースがこれらのエンドポイントに接続できるようになる。
ダイナミック・ルート・ベースのVPN接続を作成する場合、ルートを設定する必要がありますか？
いいえ、ダイナミックルートベースのVPN接続を作成する際に、手動でルートを設定する必要はありません。 Transit Gateway に接続されたすべてのスポークは、自動的にオンプレミス・ネットワークに接続されます。
VPN for VPC は、動的なルートベースの接続で、VPN ピアごとにいくつのルートをサポートしていますか?
各 IBM VPN ゲートウェイは、ダイナミックルーティングセットアップにおいて 、各 VPN ピアに対して最大 120 本のルートをサポートします。 この制限を超えると、そのピアのBGPセッションは自動的にシャットダウンします。 セッションを復元するには、オンプレミスのピアネットワークからアドバタイズされるルートの数を120以下に減らし、 IBM Cloud、接続を切り替えてBGPセッションを再確立する必要があります。 さらに、VPNアプライアンスがピアの組み合わせで120以上のルートを受信した場合、アプライアンスは最初の120ルートだけをTransit Gateway転送します。 たとえば、2つのピアからそれぞれ70のルートがVPNアプライアンスに送信された場合、最初の120ルートだけがTransit Gateway伝搬されます。 120以上のルートが必要な場合は、VPNアプライアンスをさまざまなオンプレミス・デバイスに接続できます。 ただし、この構成では、VPNアプライアンスが異なるオンプレミス・デバイスに接続されている場合の高可用性やディザスタ・リカバリは保証されないことに留意してください。
IBM はデータ・プレーン VPN アプライアンスの四半期 ASV スキャンを実行しますか。
承認済みのスキャン・ベンダー (ASV) による四半期ごとのスキャンは、Payment Card Industry (PCI) Security Standards Council の要件です。 VPN データ・プレーン・アプライアンスの ASV スキャンは、もっぱらお客様の責任で行ってください。 IBM は、ASV を使用したデータ・プレーン・アプライアンスのスキャンを行いません。これらのスキャンは、カスタマー・ワークロードの機能とパフォーマンスに悪影響を及ぼす可能性があるためです。
VPCにVPNゲートウェイを使用している場合、どのようなメトリクスに課金されますか？
VPN ゲートウェイ料金の請求のために、毎月以下のメトリックが収集されます。
- VPN ゲートウェイのインスタンス時間: VPN ゲートウェイ・インスタンスが稼働している時間の長さ。
- VPN 接続時間: VPN ゲートウェイで各 VPN 接続が確立され、維持される時間の長さ。
- フローティングIP : VPNゲートウェイインスタンスで使用されるアクティブなフローティングIP アドレスの数。
VPNゲートウェイを使用する場合、VPCデータレートで課金されるすべてのアウトバウンド・パブリック・インターネット・トラフィックも課金されます。
トラフィックがルートベースVPNゲートウェイを経由しないのはどのような場合ですか？
VPN接続をネクストホップとしてVPCルートを構成した場合、以下の条件によりトラフィックが期待通りにルーティングされないことがあります：
- VPCインスタンスに関連付けられたセキュリティグループはトラフィックを許可しない。 さらに、インスタンスのサブネットまたはVPNゲートウェイに関連付けられたネットワークACLがトラフィックをブロックする。 セキュリティグループとACLが目的のトラフィックを許可していることを確認してください。 詳細については、 VPNで使用するネットワークACLの設定を 参照してください。
- トラフィックのソースIPが、VPNルートを含むルーティングテーブルに関連付けられたサブネットに属さない場合、VPNゲートウェイはトラフィックをドロップする。 例えば、 サブネットAのみに関連するVPCルーティング・テーブルで、ネクストホップがVPN接続であるルートを含むとします。 トラフィックがVPNゲートウェイに到達しても、 サブネットA またはそのルーティングテーブルにリンクされている他のサブネット以外のIPアドレスから発信されている場合、ゲートウェイはそのトラフィックを転送しない。