マルチゾーン・クラスターからのアウトバウンド VPN 接続を 1 つ構成する

マルチゾーン・クラスターに strongSwan VPN サービスを構成する最もシンプルな方法は、クラスター内のすべてのアベイラビリティー・ゾーンのさまざまなワーカー・ノード間をフローティングする単一のアウトバウンド VPN 接続を使用する方法です。

VPN 接続がマルチゾーン・クラスターからのアウトバウンド接続である場合、必要な strongSwan デプロイメントは 1 つのみです。 ワーカー・ノードが削除されたりワーカー・ノードでダウン時間が発生したりすると、kubelet は VPN ポッドを新しいワーカー・ノードにスケジュールし直します。 アベイラビリティー・ゾーンで障害が発生した場合、kubelet は、VPN ポッドを別のゾーンの新しいワーカー・ノードにスケジュールを変更します。

1. strongSwan VPN の Helm チャートを 1 つ構成します。 このセクションの手順に従う場合は、必ず次の設定を指定してください。

   • ipsec.auto: start に変更します。 クラスターからのアウトバウンド接続になります。
   • loadBalancerIP: IP アドレスを指定しないでください。 この設定は空白にしておきます。
   • zoneLoadBalancer: ワーカー・ノードがある各ゾーンのパブリック・ロード・バランサーの IP アドレスを指定します。 使用可能なパブリック IP アドレスを確認したり、使用されている IP アドレスを解放したりできます。 strongSwan VPN ポッドはどのゾーンのワーカー・ノードにもスケジュールされる可能性があるので、この IP のリストを指定することで、どのゾーンに VPN ポッドがスケジュールされてもロード・バランサー IP を使用できるようにします。
   • connectUsingLoadBalancerIP: true に設定します。 strongSwan VPN ポッドがワーカー・ノードにスケジュールされると、strongSwan サービスは同じゾーンのロード・バランサーの IP アドレスを選択し、その IP を使用してアウトバウンド接続を確立します。
   • local.id: リモート VPN エンドポイントが対応できる固定値を指定します。 リモート VPN エンドポイントで、local.id オプション (ipsec.conf の leftid 値) を VPN IPSec トンネルのパブリック IP アドレスに設定する必要がある場合は、local.id を %loadBalancerIP に設定します。 この値は、ipsec.conf の leftid 値を、接続に使用されるロード・バランサーの IP アドレスに自動的に構成します。
   • オプション: enableSingleSourceIP を true に設定して、各ゾーンの単一 IP アドレスの背後にあるすべてのクラスター IP アドレスを非表示にします。 このオプションによって、リモート・ネットワークからクラスターへのすべての接続が許可されなくなるため、非常に安全な VPN 接続の構成が提供されます。 また、local.subnet を %zoneSubnet 変数に設定し、local.zoneSubnet を使用してクラスターの各ゾーンの /32 サブネットとして IP アドレスを指定する必要もあります。

2. リモートのネットワーク・ファイアウォールで、zoneLoadBalancer 設定に指定したパブリック IP アドレスからの着信 IPSec VPN接続を許可します。

3. リモートの VPN エンドポイントを、zoneLoadBalancer 設定に指定した各ロード・バランサー IP からの着信 VPN 接続を許可するように構成します。

マルチゾーン・クラスターへのインバウンド VPN 接続を 1 つ構成する

着信 VPN 接続が必要で、障害検出時にはリモートの VPN エンドポイントが自動で別の IP に VPN 接続を再確立できる場合は、クラスター内のすべてのアベイラビリティー・ゾーンのさまざまなワーカー・ノード間をフローティングする単一のインバウンド VPN 接続を使用できます。

リモートの VPN エンドポイントは、すべてのゾーンのすべての strongSwan ロード・バランサーに VPN 接続を確立できます。 着信要求は、VPN ポッドがどのゾーンに存在していようと、特定の VPN ポッドに送信されます。 VPN ポッドからの応答は、元のロード・バランサーを介してリモートの VPN エンドポイントに送り返されます。 この方法では、ワーカー・ノードが削除されたりワーカー・ノードでダウン時間が発生したりすると kubelet が VPN ポッドを新しいワーカー・ノードにスケジュールし直すので、高可用性が保証されます。 また、アベイラビリティー・ゾーンで障害が発生した場合でも、リモートの VPN エンドポイントが別のゾーンのロード・バランサーの IP アドレスに VPN 接続を再確立するので、VPN ポッドにアクセスすることができます。

1. strongSwan VPN の Helm チャートを 1 つ構成します。 このセクションの手順に従う場合は、必ず次の設定を指定してください。

   • ipsec.auto: add に変更します。 クラスターへのインバウンド接続になります。
   • loadBalancerIP: IP アドレスを指定しないでください。 この設定は空白にしておきます。
   • zoneLoadBalancer: ワーカー・ノードがある各ゾーンのパブリック・ロード・バランサーの IP アドレスを指定します。 使用可能なパブリック IP アドレスを確認したり、使用されている IP アドレスを解放したりできます。
   • local.id: リモート VPN エンドポイントで、local.id オプション (ipsec.conf の leftid 値) を VPN IPSec トンネルのパブリック IP アドレスに設定する必要がある場合は、local.id を %loadBalancerIP に設定します。 この値は、ipsec.conf の leftid 値を、接続に使用されるロード・バランサーの IP アドレスに自動的に構成します。

2. リモートのネットワーク・ファイアウォールで、zoneLoadBalancer 設定で指定したパブリック IP アドレスへの発信 IPSec VPN 接続を許可します。

マルチゾーン・クラスターの各ゾーンにインバウンド VPN 接続を構成する

着信 VPN 接続が必要で、リモート VPN エンドポイントが別の IP への VPN 接続を再確立できない場合は、各ゾーンに別個の strongSwan VPN サービスをデプロイする必要があります。

すべてのゾーンのロード・バランサーに個々に VPN 接続を確立するようにリモートの VPN エンドポイントを更新する必要があります。 さらに、それらの VPN 接続がどれも固有になるように、リモートの VPN エンドポイントにゾーン別の設定を構成する必要があります。 これらの複数の着信 VPN 接続がアクティブなままであることを確認します。

各 Helm チャートをデプロイすると、それぞれの strongSwan VPN デプロイメントが、適切なゾーンの Kubernetes ロード・バランサー・サービスとして始動します。 そのパブリック IP への着信要求は、同じゾーンに割り振られている VPN ポッドに転送されます。 ゾーンで障害が発生した場合、他のゾーンで確立されている VPN 接続は影響を受けません。

1. 各ゾーンに strongSwan VPN の Helm チャートを構成します。 このセクションの手順に従う場合は、必ず次の設定を指定してください。

   • loadBalancerIP: この strongSwan サービスをデプロイするゾーンのパブリック・ロード・バランサーの IP アドレスを指定します。 使用可能なパブリック IP アドレスを確認したり、使用されている IP アドレスを解放したりできます。
   • zoneSelector: VPN ポッドをスケジュールするゾーンを指定します。
   • VPN 経由でアクセス可能にするリソースによっては、zoneSpecificRoutes、remoteSubnetNAT、localSubnetNAT、enableSingleSourceIP などの追加設定が必要になる場合があります。 詳しくは、次の手順を参照してください。

2. 各 VPN 接続が固有になるように、VPN トンネルの両側にゾーン別の設定を構成します。 VPN 経由でアクセス可能にするリソースに応じて、接続を区別するための方法には次の 2 つがあります。

   • クラスター内のポッドがリモートのオンプレミス・ネットワーク上のサービスにアクセスする必要がある場合
     • zoneSpecificRoutes: true に設定します。 この設定は、VPN接続をクラスタ内の単一のゾーン領域に制限する。 特定のゾーン内のポッドは、その特定のゾーン用にセットアップされた VPN 接続のみを使用します。 この方法では、マルチゾーン・クラスターで複数の VPN をサポートするために必要になる strongSwan ポッドの数が減ります。また、VPN トラフィックが現在のゾーンのワーカー・ノードにしか転送されないので、VPN のパフォーマンスが向上します。さらに、各ゾーンの VPN 接続が、他のゾーンの VPN 接続、ポッドのクラッシュ、ゾーン障害の影響を受けなくなります。 remoteSubnetNAT を構成する必要はありません。 zoneSpecificRoutes 設定を使用する場合は、ルーティングがゾーンごとにセットアップされるので、複数の VPN に同じ remote.subnet を指定できます。
     • enableSingleSourceIP: true に設定し、local.subnet に単一の /32 IP アドレスを設定します。 この設定の組み合わせにより、単一の /32 IP アドレスの背後にあるすべてのクラスター・プライベート IP アドレスが非表示になります。 この固有の /32 IP アドレスにより、リモートのオンプレミス・ネットワークは、要求を開始したクラスター内の正しいポッドに正しい VPN 接続を介して応答を送り返すことができます。 local.subnet オプションに設定する単一の /32 IP アドレスは、各 strongSwan VPN 構成内で固有でなければならないことに注意してください。
   • リモートのオンプレミス・ネットワーク内のアプリケーションがクラスター内のサービスにアクセスする必要がある場合
     • localSubnetNAT: オンプレミスのリモート・ネットワーク内のアプリケーションが、クラスターとの間でトラフィックを送受信するために特定の VPN 接続を選択できることを確認します。 各 strongSwan Helm 構成で、リモートのオンプレミス・アプリケーションからアクセスできるクラスター・リソースを、localSubnetNAT を使用して一意に識別します。 リモートのオンプレミス・ネットワークからクラスターへの複数の VPN が確立されるため、オンプレミス・ネットワーク上のアプリケーションにロジックを追加して、クラスター内のサービスにアクセスするときに使用する VPN を選択できるようにする必要があります。 各 strongSwan VPN 構成の localSubnetNAT に構成した内容に応じて、クラスター内のサービスに複数の異なるサブネットからアクセスできることに注意してください。
     • remoteSubnetNAT: クラスター内のポッドが同じ VPN 接続を使用してトラフィックをリモート・ネットワークに返すようにします。 各 strongSwan デプロイメント・ファイルで、remoteSubnetNAT 設定を使用して、リモートのオンプレミス・サブネットを固有のサブネットにマップします。 クラスター内のポッドによって VPN 固有の remoteSubnetNAT から受信されたトラフィックは、その同じ VPN 固有の remoteSubnetNAT に送信され、その後、同じ VPN 接続を介して送り返されます。
   • クラスター内のポッドがリモートのオンプレミス・ネットワーク上のサービスにアクセスする必要があり、リモートのオンプレミス・ネットワーク内のアプリケーションがクラスター内のサービスにアクセスする必要がある場合は、2 番目の黒丸にリストされている localSubnetNAT と remoteSubnetNAT の設定を構成します。 クラスター内のポッドがリモートのオンプレミス・ネットワークへの要求を開始する場合は、リモートのオンプレミス・ネットワーク上のサービスにアクセスするために使用する VPN 接続を選択できるように、ポッドにロジックを追加する必要があることに注意してください。

3. リモートの VPN エンドポイント・ソフトウェアを、すべてのゾーンのロード・バランサー IP に個々に VPN 接続を確立するように構成します。

ステップ 1: strongSwan Helm チャートの取得

Helm をインストールし、strongSwan Helm チャートを取得して、設定可能な構成を確認します。

1. こちらの手順に従って、バージョン 3 の Helm クライアントをローカル・マシンにインストールします。

2. ローカル YAML ファイル内に strongSwan Helm chart のデフォルトの構成設定を保存します。

   helm show values iks-charts/strongswan > config.yaml
   

3. config.yaml ファイルを開きます。

ステップ 2: 基本 IPSec 設定の構成

VPN 接続の確立を制御するには、以下の基本 IPSec 設定を変更します。

各設定の詳細については、Helm チャートの config.yaml ファイル内で提供される資料をお読みください。

1. オンプレミスの VPN トンネル・エンドポイントで、接続を初期化するためのプロトコルとして ikev2 がサポートされていない場合は、ipsec.keyexchange の値を ikev1 に変更します。
2. オンプレミスの VPN トンネル・エンドポイントで接続に使用する ESP 暗号化と認証のアルゴリズムのリストに ipsec.esp を設定します。
   • ipsec.keyexchange が ikev1 に設定されている場合、この設定値の指定は必須です。
   • ipsec.keyexchange が ikev2 に設定されている場合、この設定値の指定は任意です。
   • この設定をブランクにしておくと、デフォルトの strongSwan アルゴリズム aes128-sha1,3des-sha1 が接続に使用されます。
3. オンプレミスの VPN トンネル・エンドポイントで接続に使用する IKE/ISAKMP SA 暗号化と認証のアルゴリズムのリストに ipsec.ike を設定します。 アルゴリズムは、encryption-integrity[-prf]-dhgroup の形式で固有にする必要があります。
   • ipsec.keyexchange が ikev1 に設定されている場合、この設定値の指定は必須です。
   • ipsec.keyexchange が ikev2 に設定されている場合、この設定値の指定は任意です。
   • この設定をブランクにしておくと、デフォルトの strongSwan アルゴリズム aes128-sha1-modp2048,3des-sha1-modp1536 が接続に使用されます。
4. local.id の値を VPN トンネル・エンドポイントで使用されるローカル Red Hat OpenShift クラスター側の識別に使用する任意のストリングに変更します。 デフォルトは ibm-cloud です。 一部の VPN 実装では、ローカル・エンドポイントのパブリック IP アドレスを使用する必要があります。
5. remote.id の値を VPN トンネル・エンドポイントで使用されるリモート・オンプレミス側の識別に使用する任意のストリングに変更します。 デフォルトは on-prem です。 一部の VPN 実装では、リモート・エンドポイントのパブリック IP アドレスを使用する必要があります。
6. preshared.secret の値を、オンプレミスの VPN トンネル・エンドポイント・ゲートウェイで接続に使用される事前共有シークレットに変更します。 この値は ipsec.secrets に保管されます。
7. オプション: remote.privateIPtoPing を Helm 接続検証テストの一部として ping するリモート・サブネット内の任意のプライベート IP アドレスに設定します。

ステップ 3: インバウンドまたはアウトバウンド VPN 接続の選択

strongSwan VPN 接続を構成する場合、VPN 接続をクラスターへのインバウンドにするか、またはクラスターからのアウトバウンドにするかを選択します。

インバウンド

リモート・ネットワークからのオンプレミス VPN エンドポイントが VPN 接続を開始し、クラスターが接続を listen します。

アウトバウンド

クラスターが VPN 接続を開始し、リモート・ネットワークからのオンプレミス VPN エンドポイントが接続を listen します。

インバウンド VPN 接続を確立するには、以下の設定を変更します。

1. ipsec.auto が add に設定されていることを確認します。
2. オプション: loadBalancerIP を strongSwan VPN サービスのポータブル・パブリック IP アドレスに設定します。 IP アドレスを指定すると、オンプレミス・ファイアウォールの通過を許可する IP アドレスを指定する必要がある場合など、安定した IP アドレスが必要な場合に役立ちます。 クラスターに 1 つ以上の使用可能なパブリック・ロード・バランサー IP アドレスがなければなりません。 使用可能なパブリック IP アドレスを確認したり、 使用されている IP アドレスを解放したりできます。
   • この設定をブランクのままにすると、使用可能なポータブル・パブリック IP アドレスの 1 つが使用されます。
   • オンプレミス VPN エンドポイントのクラスター VPN エンドポイントに対して選択したパブリック IP アドレス、または割り当てられたパブリック IP アドレスを構成する必要もあります。

アウトバウンド VPN 接続を確立するには、以下の設定を変更します。

1. ipsec.auto を start に変更します。
2. remote.gateway をリモート・ネットワーク内のオンプレミス VPN エンドポイントのパブリック IP アドレスに設定します。
3. クラスター VPN エンドポイントの IP アドレスについて、以下のいずれかのオプションを選択します。

   • クラスタのプライベートゲートウェイのパブリックIPアドレス ：ワーカーノードがプライベートVLANのみに接続されている場合、アウトバウンドVPNリクエストはプライベートゲートウェイを経由してインターネットに到達します。 専用ゲートウェイのパブリック IP アドレスが VPN 接続に使用されます。

   • strongSwan ポッドが実行されるワーカー・ノードのパブリック IP アドレス: strongSwan ポッドが実行されるワーカー・ノードがパブリック VLAN に接続されている場合、ワーカー・ノードのパブリック IP アドレスが VPN 接続に使用されます。

     • strongSwan ポッドが削除され、クラスター内の別のワーカー・ノードにスケジュール変更された場合は、VPN のパブリック IP アドレスは変更されます。 リモート・ネットワークのオンプレミス VPN エンドポイントは、いずれのクラスター・ワーカー・ノードのパブリック IP アドレスでも VPN 接続が確立されることを許可する必要があります。
     • リモート VP エンドポイントが複数のパブリック IP アドレスからの VPN 接続を処理できない場合は、strongSwan VPN ポッドのデプロイ先のノードを制限します。 nodeSelector を特定のワーカー・ノードまたはワーカー・ノード・ラベルの IP アドレスに設定します。 例えば、kubernetes.io/hostname: 10.232.xx.xx という値を指定すると、そのワーカー・ノードにのみ VPN ポッドのデプロイが許可されます。 strongswan: vpn という値を指定すると、そのラベルのワーカー・ノードで実行するように VPN ポッドを制限できます。 任意のワーカー・ノード・ラベルを使用できます。 異なる Helm チャート・デプロイメントで異なるワーカー・ノードを使用できるようにするには、strongswan: <release_name> を使用します。 高可用性のためには、少なくとも 2 つのワーカー・ノードを選択します。

   • strongSwan サービスのパブリック IP アドレス: strongSwan VPN サービスの IP アドレスを使用して接続を確立するには、connectUsingLoadBalancerIP を true に設定します。 strongSwan サービス IP アドレスは、loadBalancerIP 設定で指定できるポータブル・パブリック IP アドレスか、サービスに自動的に割り当てられる使用可能なポータブル・パブリック IP アドレスのいずれかです。

     • loadBalancerIP 設定を使用して IP アドレスを選択する場合、クラスターに 1 つ以上の使用可能なパブリック・ロード・バランサー IP アドレスがなければなりません。 使用可能なパブリック IP アドレスを確認したり、使用されている IP アドレスを解放したりできます。
     • すべてのクラスター・ワーカー・ノードは、同じパブリック VLAN 上になければなりません。 あるいは、nodeSelector 設定を使用して、VPN ポッドを loadBalancerIP と同じパブリック VLAN 上のワーカー・ノードにデプロイする必要があります。
     • connectUsingLoadBalancerIP が true に設定されていて、ipsec.keyexchange が ikev1 に設定されている場合、enableServiceSourceIP を true に設定する必要があります。

ステップ 4: VPN 接続を介したクラスター・リソースへのアクセス

VPN 接続を介してリモート・ネットワークがアクセスできるクラスター・リソースを決定します。

1. 1 つ以上のクラスター・サブネットの CIDR を local.subnet 設定に追加します。 オンプレミス VPN エンドポイントでローカル・サブネット CIDR を構成する必要があります。 以下のサブネットをこのリストに含めることができます。

   • Kubernetes ポッドのサブネット CIDR: 172.30.0.0/16。 すべてのクラスター・ポッドと、remote.subnet 設定でリストに入れたリモート・ネットワーク・サブネットのあらゆるホストの間で、双方向通信が使用可能になります。 セキュリティー上の理由から remote.subnet ホストがクラスター・ポッドにアクセスできないようにする必要がある場合は、Kubernetes ポッドのサブネットを local.subnet 設定に追加しないでください。
   • Kubernetes サービスのサブネット CIDR: 172.21.0.0/16。 サービス IP アドレスは、単一 IP の背後にある複数のワーカー・ノードにデプロイされている複数のアプリ・ポッドを公開する方法を提供します。
   • アプリがプライベート・ネットワークに NodePort サービスまたはプライベート Ingress ALB を使用して公開される場合は、ワーカー・ノードのプライベート・サブネット CIDR を追加します。 ibmcloud oc worker <cluster_name> を実行して、ワーカーのプライベート IP アドレスの最初の 3 オクテットを取得します。 例えば、それが 10.176.48.xx の場合は 10.176.48 をメモします。 次に、コマンド ibmcloud sl subnet list | grep <xxx.yyy.zzz> を実行して、<xxx.yyy.zz> を先ほど取得したオクテットに置き換えて、ワーカーのプライベート・サブネット CIDR を取得します。 注: ワーカー・ノードが新規プライベート・サブネットに追加された場合は、新規のプライベート・サブネット CIDR を local.subnet 設定およびオンプレミス VPN エンドポイントに追加する必要があります。 その後、VPN 接続を再始動する必要があります。
   • プライベート・ネットワークに LoadBalancer サービスによって公開されるアプリがある場合は、クラスターのプライベート・ユーザー管理サブネット CIDR を追加します。 これらの値を見つけるには、ibmcloud oc cluster get --cluster <cluster_name> --show-resources を実行します。 VLAN セクションで、Public 値が false の CIDR を見つけます。 注: ipsec.keyexchange が ikev1 に設定されている場合、指定できるサブネットは 1 つだけです。 ただし、localSubnetNAT 設定を使用して、複数のクラスター・サブネットを単一のサブネットに結合することができます。

2. オプション: localSubnetNAT 設定を使用して、クラスター・サブネットを再マップします。 サブネットのネットワーク・アドレス変換 (NAT) は、クラスター・ネットワークとオンプレミス・リモート・ネットワークの間のサブネット競合の回避策になります。 NAT を使用して、クラスターのプライベート・ローカル IP サブネット、ポッド・サブネット (172.30.0.0/16)、またはポッド・サービス・サブネット (172.21.0.0/16) を、異なるプライベート・サブネットに再マップすることができます。 VPN トンネルでは、元のサブネットではなく、再マップされた IP サブネットが認識されます。 再マッピングは、VPN トンネルを介してパケットが送信される前だけでなく、VPN トンネルからパケットが到着した後も行われます。 再マップされたサブネットと再マップされていないサブネットの両方を同時に VPN を介して公開できます。 NAT を有効にするには、サブネット全体を追加するか、個々の IP アドレスを追加します。

   • サブネット全体を 10.171.42.0/24=10.10.10.0/24 という形式で追加した場合、再マップは 1-to-1 です。内部ネットワーク・サブネット内のすべての IP アドレスが外部ネットワーク・サブネットにマップされ、その逆も同様です。
   • 個々の IP アドレスを 10.171.42.17/32=10.10.10.2/32,10.171.42.29/32=10.10.10.3/32 の形式で追加する場合、それらの内部 IP アドレスのみが、指定した外部 IP アドレスにマップされます。

3. バージョン 2.2.0 以降の strongSwan Helm チャートのオプション: enableSingleSourceIP を true に設定して、単一の IP アドレスの背後にあるすべてのクラスター IP アドレスを非表示にします。 このオプションによって、リモート・ネットワークからクラスターへのすべての接続が許可されなくなるため、非常に安全な VPN 接続の構成が提供されます。

   • この設定では、VPN 接続を経由するすべてのデータ・フローは、VPN 接続がクラスターまたはリモート・ネットワークから確立されているかどうかに関係なく、アウトバウンドでなければなりません。
   • strongSwan を単一ゾーン・クラスターにインストールする場合は、local.subnet に /32 サブネットとして 1 つの IP アドレスのみを設定する必要があります。 複数ゾーン・クラスターに strongSwan をインストールする場合、local.subnet に %zoneSubnet 変数を設定し、local.zoneSubnet を使用してクラスターの各ゾーンの /32 サブネットとして IP アドレスを指定する必要があります。

4. バージョン 2.2.0 以降の strongSwan Helm チャートのオプション: localNonClusterSubnet 設定を使用して、strongSwan サービスで、リモート・ネットワークからの着信要求をクラスター外部にあるサービスに経路指定できるようにします。

   • 非クラスター・サービスは、同じプライベート・ネットワークにあるか、またはワーカー・ノードから到達可能なプライベート・ネットワークに存在する必要があります。
   • 非クラスター・ワーカー・ノードは、VPN 接続を介してリモート・ネットワークへのトラフィックを開始することはできませんが、非クラスター・ノードを、リモート・ネットワークからの着信要求のターゲットにすることができます。
   • local.subnet 設定の非クラスター・サブネットの CIDR をリストする必要があります。

ステップ 5: VPN 接続を介したリモート・ネットワーク・リソースへのアクセス

VPN 接続を介してクラスターがアクセスできるリモート・ネットワーク・リソースを決定します。

1. 1 つ以上のオンプレミス・プライベート・サブネットの CIDR を remote.subnet 設定に追加します。 注: ipsec.keyexchange が ikev1 に設定されている場合、指定できるサブネットは 1 つだけです。
2. バージョン 2.2.0 以降の strongSwan Helm チャートのオプション: remoteSubnetNAT 設定を使用して、リモート・ネットワーク・サブネットを再マップします。 サブネットのネットワーク・アドレス変換 (NAT) は、クラスター・ネットワークとオンプレミス・リモート・ネットワークの間のサブネット競合の回避策になります。 NAT を使用して、リモート・ネットワークの IP サブネットを、異なるプライベート・サブネットに再マップすることができます。 再マップは、VPN トンネル経由でパケットが送信される前に行われます。 クラスター内のポッドは、元のサブネットではなく、再マップされた IP サブネットを認識します。 ポッドが VPN トンネル経由でデータを戻す前に、再マップされた IP サブネットは、リモート・ネットワークで使用されている実際のサブネットに戻されます。 再マップされたサブネットと再マップされていないサブネットの両方を同時に VPN を介して公開できます。

ステップ 6 (オプション): Slack Web フック統合によるモニターの有効化

strongSwan VPN の状況をモニターするには、VPN 接続メッセージを Slack チャネルに自動的に通知する Web フックをセットアップします。

1. Slack ワークスペースにサインインします。

2. Incoming WebHooks アプリのページにアクセスする。

3. **「インストールの要求 (Request to Install)」**をクリックします。 このアプリが Slack セットアップに表示されない場合は、Slack ワークスペースの所有者に連絡してください。

4. インストールの要求が承認されたら、**「構成の追加 (Add Configuration)」**をクリックします。

5. VPN メッセージの送信先にする Slack チャネルを選択するか、新規チャネルを作成します。

6. 生成された Web フックURL をコピーします。 URL の形式は、以下のようになります。

   https://hooks.slack.com/services/A1AA11A1A/AAA1AAA1A/a1aaaaAAAaAaAAAaaaaaAaAA
   

7. Slack Web フックがインストールされたことを確認するには、次のコマンドを実行してテスト・メッセージを Web フックURL に送信します。

   curl -X POST -H 'Content-type: application/json' -d '{"text":"VPN test message"}' <webhook_URL>
   

8. 選択した Slack チャネルにアクセスして、テスト・メッセージが成功したことを確認します。

9. Helm チャートの config.yaml ファイルで、VPN 接続をモニターするための Web フックを構成します。

   1. monitoring.enable を true に変更します。
   2. VPN 接続を介して到達できることを確認するリモート・サブネットのプライベート IP アドレスまたは HTTP エンドポイントを、monitoring.privateIPs または monitoring.httpEndpoints に追加します。 例えば、remote.privateIPtoPing 設定の IP を monitoring.privateIPs に追加したりします。
   3. Web フックURL を monitoring.slackWebhook に追加します。
   4. 必要に応じて、他のオプションの monitoring 設定を変更します。

ステップ 7: Helm チャートのデプロイ

先ほど選択した構成を使用して、strongSwan Helm チャートをクラスターにデプロイします。

1. 詳細設定を構成する必要がある場合は、Helm チャートの設定ごとに提供されている資料に従ってください。

2. 更新した config.yaml ファイルを保存します。

3. 更新した config.yaml ファイルと共に Helm chart をクラスターにインストールします。

   単一のクラスター内に複数の VPN デプロイメントがある場合は、vpn よりもわかりやすいリリース名を選択して、名前の競合を回避し、デプロイメントを区別できます。 切り捨てられないように、リリース名は 35 文字以下に制限してください。

   helm install vpn iks-charts/strongswan -f config.yaml
   

4. チャートのデプロイメント状況を確認します。 チャートの準備が整うと、出力に近い STATUS フィールドの値が DEPLOYED になる。

   helm status vpn
   

5. チャートをデプロイしたら、config.yaml ファイルで更新した設定が使用されたことを確認します。

   helm get values vpn
   

過去 6 カ月にリリースされたバージョンの strongSwan Helm チャートだけがサポートされています。 最新の機能やセキュリティー・フィックスを使用するために、常に strongSwan Helm チャートをアップグレードしてください。

名前空間による strongSwan VPN トラフィックの制限

単一テナント・クラスターまたはマルチテナント・クラスターを使用している場合、VPN トラフィックを特定の名前空間内のポッドのみに制限できます。

例えば、特定の名前空間 my-secure-namespace のポッドにのみ、VPN 経由でデータを送受信させるとします。 kube-system、ibm-system、default などの他の名前空間内のポッドが、オンプレミス・ネットワークにアクセスしないようにします。 VPN トラフィックを my-secure-namespace のみに制限するには、Calico グローバル・ネットワーク・ポリシーを作成します。

このソリューションを利用する前に、以下の考慮事項と制限事項を確認してください。

• 指定された名前空間に strongSwan Helm チャートをデプロイする必要はありません。 strongSwan VPN ポッドと routes デーモン・セットは kube-system または他の任意の名前空間にデプロイできます。 指定した名前空間に strongSwan VPN をデプロイしていない場合、vpn-strongswan-ping-remote-ip-1 Helm テストには失格します。 この失格は予期されるものであり、許容できます。 このテストでは、リモート・サブネットに直接アクセスできる名前空間にないポッドから、オンプレミス VPN ゲートウェイの remote.privateIPtoPing プライベート IP アドレスを ping します。 しかし、VPN ポッドは、リモート・サブネットへの経路を持つ名前空間のポッドにトラフィックを転送できるので、トラフィックは正常に流されます。 VPN の状態が ESTABLISHED のままであれば、指定した名前空間のポッドは VPN 経由で接続できます。

• 以下の手順の Calico グローバル・ネットワーク・ポリシーでは、ホスト・ネットワーキングを使用する Kubernetes ポッドが VPN を介してデータを送受信することを妨げることはありません。 ポッドにホスト・ネットワーキングが構成されている場合、そのポッドで実行されるアプリは、そのポッドが存在するワーカー・ノードのネットワーク・インターフェースで listen できます。 このようなホスト・ネットワーキング・ポッドは、どの名前空間にも存在する可能性があります。 どのポッドにホスト・ネットワーキングがあるかを判別するには、oc get pods --all-namespaces -o wide を実行し、172.30.0.0/16 ポッドの IP アドレスがないポッドを探します。 ホスト・ネットワーキング・ポッドに VPN 経由のデータの送受信を行わせないためには、values.yaml デプロイメント・ファイルにオプション local.subnet: 172.30.0.0/16 および enablePodSNAT: false を設定します。 これらの構成設定により、VPN 接続を介してリモート・ネットワークにすべての Kubernetes ポッドが公開されます。 ただし、指定した安全な名前空間に配置されたポッドにのみ、VPN 経由で到達できます。

開始前に

• strongSwan Helm チャートをデプロイし、VPN 接続が正しく機能していることを確認します。
• Calico CLI をインストールして構成します。

VPN トラフィックを特定の名前空間に制限するには、以下のようにします。

1. allow-non-vpn-outbound.yaml という名前の Calico グローバル・ネットワーク・ポリシーを作成します。 このポリシーは、strongSwan VPN でアクセスするリモート・サブネットを除くすべての宛先に引き続きアウトバウンド・トラフィックを送信することを、すべての名前空間に許可します。 <remote.subnet> を、Helm values.yaml 構成ファイルで指定した remote.subnet に置き換えます。 複数のリモート・サブネットを指定するには、 Calico のドキュメントを参照してください。

   apiVersion: projectcalico.org/v3
   kind: GlobalNetworkPolicy
   metadata:
     name: allow-non-vpn-outbound
   spec:
     selector: has(projectcalico.org/namespace)
     egress:
     - action: Allow
       destination:
         notNets:
         - <remote.subnet>
     order: 900
     types:
     - Egress
   

2. ポリシーを適用します。

   calicoctl apply -f allow-non-vpn-outbound.yaml --config=filepath/calicoctl.cfg
   

3. allow-vpn-from-namespace.yaml という名前の別の Calico グローバル・ネットワーク・ポリシーを作成します。 このポリシーは、strongSwan VPN でアクセスするリモート・サブネットにアウトバウンド・トラフィックを送信することを、指定した名前空間だけに許可します。 <namespace> を VPN にアクセスできる名前空間に置き換え、<remote.subnet> を Helm values.yaml 構成ファイルで指定した remote.subnet に置き換えます。 複数のネームスペースやリモート・サブネットを指定するには、 Calico のドキュメントを参照してください。

   apiVersion: projectcalico.org/v3
   kind: GlobalNetworkPolicy
   metadata:
     name: allow-vpn-from-namespace
   spec:
     selector: projectcalico.org/namespace == "<namespace>"
     egress:
     - action: Allow
       destination:
         nets:
         - <remote.subnet>
   order: 900
   types:
     - Egress
   

4. ポリシーを適用します。

   calicoctl apply -f allow-vpn-from-namespace.yaml --config=filepath/calicoctl.cfg
   

5. クラスター内にグローバル・ネットワーク・ポリシーが作成されていることを確認します。

   calicoctl get GlobalNetworkPolicy -o wide --config=filepath/calicoctl.cfg
   

ワーカー・ノードによる strongSwan VPN トラフィックの制限

マルチテナント・クラスターに複数の strongSwan VPN デプロイメントがある場合、各デプロイメントの VPN トラフィックを、各テナント専用の特定のワーカー・ノードに制限できます。

strongSwan Helm チャートをデプロイすると、strongSwan VPN デプロイメントが作成されます。 strongSwan VPN ポッドは、テイントが適用されていないワーカー・ノードにデプロイされます。 さらに、Kubernetes デーモン・セットが作成されます。 このデーモン・セットは、テイントが適用されていないクラスター内のすべてワーカー・ノードに、各リモート・サブネットへの経路を自動的に構成します。 strongSwan VPN ポッドは、ワーカー・ノード上のそれらの経路を使用して、オンプレミス・ネットワーク内のリモート・サブネットに要求を転送します。

テイントが適用されたノードには経路は構成されません。ただし、そのテイントが tolerations ファイルの value.yaml 設定に指定されている場合は別です。 ワーカー・ノードにテイントを適用することで、それらのワーカーに VPN 経路が構成されることを防止できます。 そして、テイントを適用したワーカーに許可する VPN デプロイメントについてのみ、tolerations 設定にそのテイントを指定できます。 これにより、特定のテナントの Helm チャート・デプロイメントの strongSwan VPN ポッドは、そのテナントのワーカー・ノード上の経路のみを使用して、VPN 接続でリモート・サブネットにトラフィックを転送するようになります。

このソリューションを利用する前に、以下の考慮事項と制限事項を確認してください。

• デフォルトでは、Kubernetes は、テイントが適用されていない、使用可能なワーカー・ノードにアプリ・ポッドを配置します。 このソリューションを正しく機能させるには、まず、各テナントのアプリ・ポッドが、そのテナント用のテイントが適用された正しいワーカーにのみデプロイされるようにする必要があります。 さらに、テイントが適用されたワーカー・ノードに、そのノードへのアプリ・ポッドの配置を許容する容認も設定されていなければなりません。 テイントとトレランスの詳細については、 Kubernetes のドキュメントを参照。
• テイントが適用されていない共有ノードにはどのテナントもアプリ・ポッドを配置できないので、クラスター・リソースの利用状況が最適でない可能性があります。

ワーカー・ノードによって strongSwan VPN トラフィックを制限するための次の手順では、例として、6 つのワーカー・ノードが存在するマルチテナント Red Hat OpenShift on IBM Cloud クラスターを使用する状況を想定します。 クラスターはテナント A とテナント B をサポートします。 以下の方法でワーカー・ノードにテイントを適用します。

• 2 つのワーカー・ノードに、テナント A のポッドのみがスケジュールされるようにするテイントを適用します。
• 2 つのワーカー・ノードに、テナント B のポッドのみがスケジュールされるようにするテイントを適用します。
• 2 つのワーカー・ノードにはテイントを適用しません。strongSwan VPN ポッドとロード・バランサー IP を実行するために、少なくとも 2 つのワーカー・ノードが必要であるからです。

各テナント用にテイントを適用したノードに VPN トラフィックを制限するには、以下のようにします。

1. この例のテナント A 専用のワーカーにのみ VPN トラフィックを制限するために、テナント A の strongSwan Helm チャートの toleration ファイルに以下の values.yaml を指定します。

   tolerations:
       - key: dedicated
   operator: "Equal"
   value: "tenantA"
   effect: "NoSchedule"
   

   この toleration により、route デーモン・セットは、dedicated="tenantA" テイントが適用された 2 つのワーカー・ノードと、テイントが適用されていない 2 つのワーカー・ノードで実行できるようになります。 このデプロイメントの strongSwan VPN ポッドは、テイントが適用されていない 2 つのワーカー・ノードで実行されます。

2. この例のテナント B 専用のワーカーにのみ VPN トラフィックを制限するために、テナント B の strongSwan Helm チャートの toleration ファイルに以下の values.yaml を指定します。

   tolerations:
       - key: dedicated
   operator: "Equal"
   value: "tenantB"
   effect: "NoSchedule"
   

   この toleration により、route デーモン・セットは、dedicated="tenantB" テイントが適用された 2 つのワーカー・ノードと、テイントが適用されていない 2 つのワーカー・ノードで実行できるようになります。 このデプロイメントの strongSwan VPN ポッドも、テイントが適用されていない 2 つのワーカー・ノードで実行されます。