VPN for VPC の機能

IBM Cloud VPN for VPC サービスには、以下の機能が含まれています。

MD-5 および 認証アルゴリズム、2および5のDHグループ、および3-DES暗号化アルゴリズムは、2022年9月20日に非推奨となり、コンソールではサポートされなくなりました。 SHA-1

• 認証 - IBM Cloud VPN for VPC は、フェーズ 1 ピア認証用の事前共有鍵をサポートします。 両フェーズでサポートされている認証アルゴリズムには、 SHA-256、 SHA-384、 SHA-512 がある。

• 非活動ピア検出 - IPsec ピアの状態を検出する構成可能なメカニズム。

• Diffie-Hellman (DH) - VPN ピア間の共有秘密鍵を生成するためにフェーズ 1 で使用される鍵交換プロトコル。 オプションで、ユーザーはフェーズ 2 の IPsec ネゴシエーションのために Perfect Forward Secrecy (PFS) と DH グループを有効にすることができます。 IBM Cloud VPNfor VPCは、DHグループ14～24および31をサポートしています。

• 暗号化- IBM Cloud VPN for VPCは、 AES-128、 AES-192、 AES-256、IKEフェーズ1とフェーズ2の両方でデータ暗号化をサポートします。

• 高可用性 - IBM Cloud VPN for VPC は、アプライアンス・レベルの冗長性を提供するために 2 つの VPN デバイス上に構築されています。 ポリシー・ベース VPN は、アクティブ-スタンバイ・モードで稼働し、メンバー間で 1 つの VPN ゲートウェイ IP を共有します。一方、経路ベース VPN は、2 つの VPN ゲートウェイ IP を使用してアクティブ-アクティブの冗長性を提供します。

  静的経路ベース VPN は、アクティブ - アクティブ冗長モードでデプロイされます。 2 つの VPN トンネルがピア VPN ゲートウェイに接続されていますが、IBM ゲートウェイは常に、小さなパブリック IP を持つトンネルを 1 次出口パスとして使用します。 大きなパブリック IP を持つトンネルは、2 次出口パスです。 IBM VPC からオンプレミス・ネットワークへのトラフィックは、両方のトンネルがアクティブであれば、1 次出口パスを経由します。 1 次出口パスが無効になっている場合、トラフィックは 2 次出口パスを通過します。 オンプレミスの VPN ゲートウェイは、経路優先順位を使用して同じ優先パスを選択する必要があります。

• Internet Key Exchange (IKE) - IKE は、IPsec プロトコルの一部であり、VPN 接続の確立に使用されます。 IKE のフェーズ 1 では、VPN ピア同士で Diffie-Hellman (DH) の鍵交換を使用して、認証された安全な通信チャネルを作成します。 IKE フェーズ 2 では、ピアはフェーズ 1 のセキュア・チャネルを使用して、IPsec トンネルのパラメーターをネゴシエーションします。 IBM Cloud VPN for VPC は、IKEv1 (メインモード) と IKEv2 の両方をサポートします。 サポートされる組み合わせについては、ポリシーのネゴシエーションについてを参照してください。

• IPsec - デバイス間の安全な通信を提供するプロトコル・スイート。 IBM Cloud VPN のVPCでは、トンネルモードでIPsecのESP（Encapsulating Security Protocol）パケットのUDPカプセル化を使用し、認証とパケット全体の暗号化を提供します。

• モード - IBM Cloud VPN for VPC は、静的経路ベースの VPN モードとポリシー・ベースの VPN モードを提供します。 ポリシー・ベース VPN では、ネゴシエーションされた CIDR 範囲と一致するトラフィックが、VPN を通過します。 静的経路ベース VPN では、仮想トンネル・インターフェースが作成され、それらの論理インターフェースにカスタム経路を使用して転送されるトラフィックが、VPN を通過します。 どちらの VPN オプションも同じ機能を提供します。

• Perfect Forward Secrecy (PFS) - PFS は、DH で生成された鍵が IPsec の再ネゴシエーションで再度使用されることがないようにします。 鍵が盗まれても、保護されていたセキュリティー・アソシエーションの存続期間中の転送データにしかアクセスできません。

VPN ゲートウェイの概要

VPN を作成する前に、まず、VPN およびその他のリソースのために VPC と 1 つ以上のサブネットを作成する必要があります。

必須ではありませんが、少なくとも IP 16 個分のサブネット (接頭部が 28 以下) を VPN ゲートウェイの専用にすることをお勧めします。 その VPN サブネット内に追加のリソースをプロビジョンすることにした場合は、リカバリーおよび保守のタスクで VPN ゲートウェイに使用できる IP が常に 4 つ以上あることを確認してください。 VPN ゲートウェイに必要な 4 つの IP に加えて、サブネット内の最大 5 つの IP が内部ネットワーク用に予約されているため、サブネットの大きさが十分であることを確認してください。

VPN ゲートウェイを作成するには、以下の大まかな手順に従います。

1. VPNトラフィックを流すための ネットワークACLが 適切に設定されていることを確認する。

2. NAT トラバーサルがピア・デバイスでサポートされていて、ピア・デバイスで有効にされていることを確認します。 詳しくは、VPN ゲートウェイの制限を参照してください。

3. 計画時の考慮事項を確認し、VPN ゲートウェイを作成します。

4. VPN 接続を作成します。

   IBM Cloud VPN for VPC は、VPC ごとにゾーンごとに 1 つの経路ベース VPN のみをサポートします。

5. 静的経路ベース VPN の場合は、静的ルーティング用のルーティング・テーブルを作成または選択してから、「VPN 接続」タイプを使用して経路を作成します。

6. VPN トンネル経由でオンプレミスのネットワークに接続します。

7. ピア・ネットワーク上のデバイスにトンネル経由で ping またはデータ・トラフィックを送信して、VPN 接続が使用可能であることを検証します。

アーキテクチャー

以下の図は、複数のオンプレミス・ネットワークがある VPN セットアップの例を示しています。 この VPN はユーザーの VPC 内の 1 つのサブネットに構成されていますが、ゾーン内のすべてのサブネットのインスタンスで共有できます。 IKE ポリシーと IPsec ポリシーも、1 つ以上の VPN 接続で使用できます。

ポリシーのネゴシエーションについて

IKE ネゴシエーションの両方のフェーズにおいて、IPsec ピア間で、サポートするものとしてそれぞれに構成されているセキュリティー・パラメーターの候補を交換し、一連の構成について合意する必要があります。 カスタム IKE ポリシーおよび IPsec ポリシーにより、IBM Cloud VPN for VPC ユーザーは、このネゴシエーション中に使用されるこれらのセキュリティー・パラメーターを構成できます。

VPN 接続の構成に IKE ポリシーと IPsec ポリシーを使用することはオプションです。 ポリシーを選択しない場合は、オートネゴシエーション と呼ばれるプロセスによって、デフォルトのプロポーザルが自動的に選択されます。

このネゴシエーション・プロセスに関係する主なセキュリティー・パラメーターは、以下のとおりです。

• IKE のフェーズ
• 暗号化アルゴリズム
• 認証アルゴリズム
• Diffie-Hellman グループ (暗号鍵交換プロトコル)

IBM Cloud のオートネゴシエーションでは IKEv2 が使用されるため、オンプレミスのデバイスでも IKEv2 を使用する必要があります。 オンプレミスのデバイスが IKEv2 をサポートしていない場合は、カスタマイズした IKE ポリシーを使用してください。

VPN for VPC のユース・ケース

ユース・ケース 1: 1 つ以上のピア・ネットワークに関連付けられている同じタイプの単一リモート・ピア・デバイスへの VPN 接続

経路ベース VPN でもポリシー・ベース VPN でも、1 つ以上のネットワークに関連付けられている単一のリモート・ピア・デバイスにユーザーを接続できます。

このユース・ケースは、ポリシー・ベース VPN と経路ベース VPN の間の接続には適用されません。 詳しくは、既知の制限事項を参照してください。

ユース・ケース 2: 複数のリモート・ピア・デバイスへの VPN 接続

ポリシー・ベース VPN でも経路ベース VPN でも、複数の VPN 接続を使用して、別々の VPC/環境に関連付けられている複数のリモート・ピア・デバイスにユーザーを接続できます。

ユースケース3：FQDNを使用したVPNの詳細設定

以下のユース・ケースは、 IBM Cloud に VPC が 1 つあり、オンプレミス・サイトを単一の VPN ゲートウェイに接続することを希望するお客様を示しています。 オンプレミス・サイトの VPN ゲートウェイは NAT デバイスの背後にあり、パブリック IP アドレスを持っていません。 オンプレミス VPN ゲートウェイのローカル IKE ID は、そのゲートウェイが所有するプライベート IP アドレスです。 1 つの FQDN が NAT デバイスのパブリック IP アドレスに関連付けられています。

ユースケース4：ルートベースVPNのトラフィック分散

ルートベースVPNはバックエンドで2つのトンネルをアクティブにする。 両方のVPNトンネルが立ち上がっている場合、トンネル上のVPNトラフィックをルーティングするために使用されるのは1つのトンネルだけである。

VPNは、小さなパブリックIPを持つトンネルをプライマリ・イグレス・パスとして使用する。 プライマリのイグレスパスが無効になると、トラフィックはセカンダリパスを流れる。 トラフィックのルーティングに1つのトンネルしか使わない理由は、非対称ルーティングの問題を避けるためである。 以下の図は、デフォルトのコンフィギュレーションを示している。 宛先が 10.1.0.0/24 でネクストホップがVPN接続のルートを作成する場合、tunnel 1 と tunnel 2 の両方が稼働していれば、ルート作成のためにVPNアプライアンスのプライベートIP 10.254.0.2 が返されます。

仮想ネットワークインターフェース上のプロトコルステートフィルタリングは、非対称ルーティング問題に対処するオプションを提供する。 詳細については、プロトコル状態フィルタリングモード を参照のこと。

ルートベースVPNの接続を作成する際に、VPCルートのネクストホップがVPN接続である場合に、VPNゲートウェイ接続の Up トンネル間でトラフィックの分散を有効にできるようになりました。 このアクティブ／アクティブ冗長モードを実現するには、作成 または VPNゲートウェイへの接続の追加 のときに「トラフィックを分配する」機能を有効にする必要がある。

以下の図に示すように、トラフィックのイグレスは2つのトンネルに動的にルーティングされる。 トンネルが Up になると、プライベートIPアドレス 10.254.0.2 と 10.254.0.3 が返され、VPCネットワークサービスは2つのルートを作成する。 これらのルートは同じ優先順位を持っているため、トラフィックは動的に tunnel 1 と tunnel 2 に流れる。

です*

この機能を使用するには、オンプレミス・デバイスがより高いネットワーク・パフォーマンスを得るために非対称ルーティングをサポートする必要がある。 また、すべてのオンプレミスVPNゲートウェイがこのユースケースをサポートしているわけではないことに留意してください。 例えば、VPNトラフィックのイグジットとイングジットが異なるトンネルの場合、オンプレミスのVPNデバイスやファイアウォールによってトラフィックがブロックされる可能性がある。

関連リンク

以下のリンクは、IBM Cloud VPN for VPC に関する追加情報を提供します。

• VPN の CLI リファレンス
• VPN の API リファレンス
• VPN Terraform リファレンス
• VPC インフラストラクチャ サービスの IAM アクセスの管理
• Activity Tracker イベント
• VPN ゲートウェイについての FAQ
• VPN ゲートウェイのトラブルシューティング
• VPN ゲートウェイの割り当て量