制限

• VPC 用の VPN ゲートウェイは、 「IPsec ESP パケットの UDP カプセル化(UDP Encapsulation of IPsec ESP Packets)」 のみを使用する VPN パケットを受け入れます。 Encapsulating Security Payload(ESP) は受け入れられません。 NAT-T 機能がオンプレミス VPN デバイスで有効になっていることを確認します。 また、IBM VPC の NACL とピア・ネットワークの両方で UDP ポート 500 と 4500 が許可されていることも確認してください。

• IBM Cloud の VPN ゲートウェイまたはオンプレミスのデバイスのどちらかに、複数のネットワーク、サブネット、またはその両方が関連付けられている場合に、ポリシー・ベースの VPN と経路ベースの VPN を混用することは避けてください。 ポリシー・ベースの VPN では、ターゲットのネットワーク範囲ごとにトンネルが作成されます。 一方、経路ベースの VPN では、すべてが 1 つのトンネルでピア・デバイスに転送されます。 したがって、複数のネットワーク範囲が構成されている場合は、1 つのネットワーク範囲を関連付けた 1 つのトンネルしか確立できません。 連続する複数のサブネットを 1 つのスーパーセット CIDR に集約することが、この制限に対する有効な回避策です。

• VPN ゲートウェイ接続のピアのサブネットがオーバーラップしていてはいけません。

• ポリシー・ベースの VPN を経路ベースのピア (またはポリシー・ベースのピアを使用する静的経路ベース VPN) と接続する場合は、両側に単一のネットワーク範囲のみを使用してください。 ポリシー・ベースの VPN では、関連付けたネットワークごとに 1 つのトンネルが使用されます。 一方、経路ベースの VPN では、必要なトンネルは 1 つだけです。 したがって、どちらかの側に複数のネットワーク範囲が関連付けられている状況で、タイプの異なる VPN 同士を接続した場合は、単一のネットワーク範囲しか使用できない接続になります。

  

  VPNタイプ混在の使用例

  可能であれば、連続する複数のサブネットは、VPN の構成で 1 つのネットワーク範囲に集約してください。 例えば、サブネット 192.168.0.0/24 と 192.168.1.0/24 は、VPN またはルーティングの構成では 192.168.0.0/23 と定義できます。

• IBM Cloud のポリシー・ベースの VPN ゲートウェイは、プロビジョニング時に選択したサブネットに関連付けられているゾーンに置かれます。 VPN ゲートウェイは、その同じゾーンの VPC の仮想サーバー・インスタンスにのみ機能します。 そのため、他のゾーンのインスタンスで、この VPN ゲートウェイを使用してオンプレミスのプライベート・ネットワークと通信することはできません。 ゾーン障害に対する耐障害性のためには、VPN ゲートウェイをゾーンごとに 1 つデプロイする必要があります。

• IBM Cloud の経路ベースの VPN ゲートウェイは、プロビジョニング時に選択したサブネットに関連付けられているゾーンに置かれます。 VPN ゲートウェイは、同じゾーンの VPC の仮想サーバー・インスタンスにのみ使用することをお勧めします。 他のゾーンのインスタンスで、経路ベースの VPN ゲートウェイを使用してオンプレミスのプライベート・ネットワークと通信することもできますが、これはお勧めしません。 ゾーン障害に対する耐障害性のためには、VPN ゲートウェイをゾーンごとに 1 つデプロイする必要があります。

• サイト間 IPsec VPN 接続を構成して最適化すると、ネットワーク・パフォーマンスの問題が発生する可能性があります。この問題の 1 つは、最大伝送単位 (MTU) と最大セグメント・サイズ (MSS) のクランプに関連しています。 詳しくは、 IBM サイト間 VPN 最大伝送単位(MTU)クランプ を参照してください。

• 経路のネクスト・ホップが VPN ゲートウェイ接続である場合、この経路は出口ルーティング・テーブルに存在している必要があります。つまり、経路テーブルは VPC サブネットに関連付けられている必要があります。 さらに、VPN ゲートウェイは、トラフィックを VPN トンネルに転送するときに、このトラフィックの送信元 IP がルーティング・テーブルに接続されているサブネット内にあるかどうかも検査します。 送信元 IP がルーティング・テーブルに接続されたサブネット内にない場合、トラフィックは暗号化されず、VPN トンネルを介してピア・ゲートウェイに転送されません。 例えば、VPN ゲートウェイが Ingress ルーティング・テーブルを介してルーティングされたトラフィックを受信した場合、その送信元 IP がルーティング・テーブルに接続されたサブネット内にないため、このトラフィックは VPN トンネルに転送されません。

  ネクスト・ホップが VPN ゲートウェイ接続である Ingress ルーティング・テーブルでの経路の作成はサポートされていません。

既知の問題

VPN ゲートウェイ接続の peer.address または peer.fqdn の更新-VPN ゲートウェイ接続の作成時に local.ike_identities プロパティーおよび peer.ike_identity プロパティーが明示的に設定されていない場合、 VPN ゲートウェイ接続を更新 し、 peer.address または peer.fqdn のいずれかを指定すると、プロパティー値は変更されずに、更新された値と一致するように変更されます。 逆に、VPN ゲートウェイ接続の作成時に local.ike_identities プロパティーと peer.ike_identity プロパティーが明示的に設定されている場合は、VPN ゲートウェイ接続を削除せずに値を変更することはできません。

交通規制の配布

トラフィックを分散する場合、ピア・ゲートウェイは等コスト・マルチパス・ルーティング（ECMP）をサポートできなければならない。 さらに、ピアゲートウェイによっては、ECMPを有効にするために特定のコンフィギュレーションが必要な場合がある。 詳細については、ルートベースVPNのトラフィックを分散する ユースケースを参照してください。