VPNゲートウェイの既知の問題

既知の問題とは、リリース前に修正されなかったが、リリースを遅らせるほど重大ではなかったバグや予期せぬ動作のことである。 これらの問題は、多くの場合、回避策とともにあなたに伝えられ、開発チームによって近いうちに解決されるよう優先順位が付けられます。

サイト間VPNゲートウェイに関する既知の問題は以下の通り：

• VPC用VPNゲートウェイは、 IPsec ESPパケットを UDP カプセル化したVPNパケットだけを受け入れる。 カプセル化セキュリティ・ペイロード（ESP） パケットは受け付けない。 NAT-T 機能がオンプレミス VPN デバイスで有効になっていることを確認します。 また、 IBM VPC NACLとピアネットワークの両方で、 UDP ポート 500 と 4500 が許可されていることを確認してください。

  NAT-T は、IPsec パケットを UDP でカプセル化することにより、VPN トラフィックが NAT デバイスを通過することを可能にする。 NAT-Tがないと、NATデバイスがESPトラフィックを適切に処理できないため、IPsecパケットがNATデバイスによってドロップされる可能性がある。 NATデバイス間で信頼性の高いVPN接続を実現するには、オンプレミスデバイスでNAT-Tを有効にする必要があります。

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

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

• Transit Gateway プレフィックスフィルタリングは現在、VPNゲートウェイではサポートされていません。

• ポリシーベースVPNとルートベースVPNを接続する場合(またはスタティックルートベースVPNとポリシーベースVPNを接続する場合)、双方で単一のネットワーク範囲のみを使用してください。 ポリシー・ベースVPNでは、関連するネットワークごとに1つのトンネルを使用するが、ルート・ベースVPNでは1つのトンネルしか必要としない。 左右の複数のネットワーク範囲に関連する異なるタイプのVPN間の接続は、1つのネットワーク範囲に対してのみ機能する可能性がある。

  

  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ゲートウェイがイングレスルーティングテーブルを通してルーティングされたトラフィックを受信した場合、ソースIPがルーティングテーブルにアタッチされているサブネット外にあるため、そのトラフィックはVPNトンネルに転送されない。

  VPNゲートウェイ接続をネクストホップとしてイングレスルーティングテーブルにルートを作成することはサポートされていません。

• VPNゲートウェイを作成する際に、ローカルとピアのIKE ID（アドレス、FQDN、またはホスト名）を設定することはオプションです。 ただし、ピアアドレスやFQDNを後で更新すると、VPN接続に影響が出る可能性があります：

  • ローカルIKE IDとピアIKE IDを指定しない場合、ゲートウェイは自動的にデフォルト値を使用します：VPNゲートウェイのパブリックIPがローカルIKE IDとして使用され、ピアゲートウェイのパブリックIPがピアIKE IDとして使用されます。 このデフォルト設定は、ピアアドレスが変更されても安定したVPN接続を維持するのに役立ちます。
  • ローカルとピアのIKE IDを明示的に設定すると、特定の値を固定することになる。 この場合、ピアアドレスまたはFQDNを更新すると、接続が切断されるのを避けるために、VPN接続を削除して再作成する必要があります。