IBM Cloud Docs
VPNサーバーのプランニング

VPNサーバーのプランニング

クライアントとサイト間の VPN サーバーを作成する前に、以下の考慮事項を確認してください。

スケーリングに関する考慮事項

集約帯域幅は、スタンドアロン VPN の場合は 600 Mbps、高可用性 VPN サーバーの場合は 1200 Mbps です。 アクティブ・クライアントの最大数は 2000 です。 より大きい帯域幅が必要な場合、または VPN サーバーに接続する必要があるクライアントがこれより多い場合は、同じ VPC、または異なるリージョンの異なる VPC に複数の VPN サーバーを作成できます。

既存の VPC 構成に関する考慮事項

クライアントからサービス・エンドポイントおよび IaaS エンドポイントにアクセスする必要があるかどうかを決定します。 これらのエンドポイントは、IBM Cloud プライベート・ネットワークを介して IBM Cloud サービスに安全に接続します。 これらのエンドポイントにアクセスする必要がある場合は、VPN サーバーのプロビジョン時に DNS サーバー・アドレス 161.26.0.10 および 161.26.0.11 を指定する必要があります。 詳細については、サービス・エンドポイントと IaaS エンドポイントを参照してください。

クライアントのプライベート DNS 名を解決する必要があるかどうかも決定する必要があります。IBM Cloud DNS Services は、VPC のユーザーにプライベート DNS を提供します。 これらのエンドポイントにアクセスする必要がある場合は、VPN サーバーのプロビジョン時に DNS サーバー・アドレス 161.26.0.7 および 161.26.0.8 を指定する必要があります。 詳細については、DNS Services についてを参照してください。

この DNS サーバーを指定する場合は、VPN サーバーのプロビジョン後に、宛先 161.26.0.0/16 および translate アクションを使用して VPN 経路を作成する必要もあります。

VPN サーバーのプロビジョニングに関する考慮事項

VPN サーバーのプロビジョニング時には、以下の点を考慮してください。

クライアント IPv4 アドレス・プール

VPN サーバーの作成時に、クライアント IPv4 アドレス・プール (CIDR 範囲) を求めるプロンプトが表示されます。 クライアントには、このアドレス・プールからのセッションの IP アドレスが割り当てられます。 クライアント IP プール・プロパティーは VPC アドレス接頭部とオーバーラップしてはならないことに注意してください。 クライアント IP プールが既存のアドレス接頭部とオーバーラップする場合、VPN サービスはクライアント IP アドレスを検証します。

以下の要件を確認してください。

  • 各アクティブ VPN クライアントには、構成可能な IP プールから IP アドレスが割り当てられます。 VPC 接頭部および個人のデバイスのローカル CIDR とオーバーラップしないように IP CIDR 範囲を慎重に選択する必要があります。
  • ユース・ケースによっては、クライアント IP プールとお客様のローカル・デバイス IP アドレスがオーバーラップしてはいけないものがあります。 クライアント IP プールは、宛先ネットワークとオーバーラップすることもできません。例えば、VPN サーバーを使用して IBM Cloud クラシック・ネットワークにアクセスする場合、クライアント IP は IBM Cloud クラシック・ネットワークとオーバーラップすることができません。
  • ブロック・サイズが少なくとも /22 (1024 個の空き IP アドレス) になるようにする必要があります。 最大数の同時接続を可能にするために必要な IP アドレス数の倍の数を含む CIDR ブロックを使用することが推奨されます。

サブネット: 高可用性モードとスタンドアロン・モードの比較

VPN サーバーの作成時に、高可用性モードかスタンドアロン・モードのいずれかを指定できます。

  • 高可用性モードを選択する場合は、ゾーンの異なる 2 つのサブネットにまたがって VPN サーバーをデプロイする必要があります。 このモードは、実稼働デプロイメントに使用します。 クライアントの VPN アクセスが重要なマルチゾーン・デプロイメントおよびソリューションに最適です。
  • スタンドアロン・モードを選択する場合は、VPN サーバーを単一のサブネットおよびゾーンにデプロイします。 このモードは、複数ゾーンの耐障害性が不要な非実稼働パイロット・デプロイメントで使用します。

VPN サーバー認証

プロビジョニング中に VPN サーバー証明書を指定する必要があります。 IBM Cloud Secrets Manager を使用して証明書を作成することも、独自のものを使用することもできる。

CLI または API を使用する場合は、証明書の CRN を指定する必要があります。 証明書 CRN を取得するには、『証明書の CRN を見つける』を参照してください。

VPN サーバーで使用しているものがユーザー ID とパスコード認証のみの場合は、公開鍵/秘密鍵と CA 証明書を含む VPN サーバー証明書を指定するだけで済みます。 VPN サービスが証明書インスタンスから公開鍵と秘密鍵を取得し、VPN サーバーに保管します。 この CA 証明書はクライアントのプロファイルにもコピーされ、これにより、クライアントが CA 証明書を使用して VPN サーバーを検証できるようになります。

証明書認証が有効になっている場合は、クライアント CA 証明書を指定する必要があります。 公開鍵と秘密鍵は必要ありません。 VPN サービスは Secrets Manager からクライアント CA 証明書を取得する。 続いて、クライアントが VPN サーバーとの接続時に公開鍵を提示し、VPN サーバーは CA 証明書を使用して公開鍵を検証します。

クライアントと VPN サーバーの証明書が同じ CA によって署名されている場合、管理者は VPN サーバーをプロビジョンするときに同じ証明書インスタンスを使用できます。

詳しくは、クライアントとサーバー間の認証のセットアップを参照してください。

VPN クライアント認証

VPN サーバー管理者は、VPN サーバーのプロビジョニング中に、認証方式を少なくとも 1 つ選択して構成する必要があります。 クライアント証明書、ユーザーIDとパスコードによるセキュリティ強化、または両方のタイプのクライアント認証を選択できます。

複数の VPN クライアントで 1 つのクライアント証明書を共有することができます。

クライアント証明書を使用する場合は、サーバー管理者から提供されるクライアント・プロファイルを編集して、クライアント証明書 (公開鍵とも呼ばれる) と秘密鍵を含める必要があります。 なお、「ユーザーIDとパスコード」によるクライアント認証のみを使用する場合は、クライアントプロファイルの変更は不要です。

クライアント認証にプライベート証明書を使用する場合、管理者はクライアント・プロファイルを変更する必要はありません。 代わりに、管理者は、マージされたプライベート証明書とすべての証明書の鍵を使用してクライアント・プロファイルをダウンロードすることも、プライベート証明書を選択し、マージされたプライベート証明書と選択された証明書の鍵を使用してクライアント・プロファイルをダウンロードすることもできます。 詳しくは、クライアント VPN 環境のセットアップと VPN サーバーへの接続を参照してください。

VPN ユーザーは、VPN サーバーへの接続にパスワードを直接使用することはありません。 ブラウザーを介して IBM アクセス・マネージャー (IAM) からパスコードを取得します。MFA が有効になっている場合、MFA の適用は常にブラウザーを介して実行されます。 ユーザーは、MFA の適用をブラウザーで実行できるよう MFA を適切に構成する必要があります。 ユーザーは、パスコードを取得した後、OpenVPN クライアントでパスコードを入力し、接続を開始します。

VPN サーバーは VPN クライアントからユーザー名とパスコードを受け取り、IAM 呼び出しを行い、IAM ポリシーを使用してパスコードと許可を検証します。

  • パスコードはワンタイムパスワードである。 ユーザーは、再接続が VPN サーバーによって開始された場合でも、再接続のためにパスコードを再生成する必要があります。
  • SoftLayer MFA の適用はブラウザーを介して行われないため、SoftLayer MFA はサポートされません。

ユーザー ID/パスコード認証を使用する場合、保守アクティビティーにより、ユーザーにはコードの取り出しと再入力による再認証が強制されます。 新しいコードを入力しないと、接続は復元されません。 これは、スタンドアロン・モードまたは HA モードの使用時に適用されます。

クライアント証明書失効リスト

オプションで、証明書失効リスト (CRL) をインポートすることができます。これは、認証局 (CA) によって取り消された証明書のタイム・スタンプ付きリストです。 証明書失効リスト (CRL) にある証明書は、有効期限は切れていない可能性がありますが、既にその証明書を発行した認証局に信頼されていません。 VPN クライアントは、このリストを使用してデジタル証明書を検証します。

CRL をインポートした後、VPN クライアントは、このリストを使用してデジタル証明書を検証します。 CRL はストリング (ファイルではない) としてシステムに保存されます。 後で CRL をダウンロードする必要がある場合は、<vpn_server_name>.pem. という名前に変更されます。

詳しくは、クライアントとサーバー間の認証のセットアップを参照してください。

トランスポート・プロトコル

トランスポート層は、1 つのデバイスのプロセスから別のデバイスのプロセスへのデータの配信を制御します。 トランスポート層プロトコルは、アプリケーション層プロトコルとネットワークによって提供されるサービスとの間の連絡係として機能します。 Client VPN for VPC は、以下のプロトコルをサポートします。

パフォーマンスを重視する場合は UDP が推奨されます。信頼性を重視する場合は TCP が推奨されます。

  • ユーザー・データグラム・プロトコル (UDP)

    ユーザー・データグラム・プロトコル (UDP) は、オーバーヘッドを最小限に抑えたシンプルで軽量のプロトコルです。 プロセスから小さなメッセージを送信する際に、信頼性を重視しない場合は、UDP を使用できます。 UDP を使用してメッセージを送信する際にかかる時間は、TCP を使用する場合に比べて大幅に短くて済みます。 ほとんどエラー・チェックは行わず、ホスト間の通信ではなくプロセス間の通信を提供することを除いては、IP サービスにメリットは付加されません。

  • 伝送制御プロトコル (TCP)

    伝送制御プロトコル (TCP) は、信頼性が高い代わりに複雑なトランスポート層プロトコルです。 TCP は、IP サービスにコネクション指向機能と信頼性を付加します。

    TCP は、1 つのホストから別のホストに送信され、データの重複や脱落のないデータ・ストリームの配信を保証するストリーム配信サービスです。 パケット転送は信頼性が低いため、パケット転送の信頼性を保証するために、肯定応答と再送信として知られる技法が使用されます。 この基本的な技法では、受信側はデータを受信したら、確認応答メッセージで応答する必要があります。

    送信側は、送信する各パケットのレコードを保持して、肯定応答を受信するまで次のパケットの送信を待機します。 また、送信側はパケットを送信してからの経過時間をタイマーで記録し、タイマーの期限が満了したらパケットを再送します。 このタイマーは、パケットの脱落や破損が起きた場合に必要になります。

フル・トンネル・モードと分割トンネル・モード

VPN 接続のセットアップ時に、インターネットを介した VPN サーバーへの暗号化トンネルが作成されます。 VPN 接続は、コンピューターには既存の LAN インターフェースに加えて、仮想ネットワーク・インターフェースとしても表示されます。 VPN トンネルの内側にある VPC 宛てのプライベート・トラフィックと、他のインターフェース (VPN トンネルの外側にある) を介したパブリック・トラフィック (インターネット・トラフィック) を送信することで、両方のインターフェースを同時に使用できるようになりました。 VPN インターフェースと他のインターフェースとの間でトラフィックが分割されている場合、スプリット・トンネリング は使用中であると見なされます。 スプリット・トンネリングが使用されていない場合、すべてのトラフィックが VPN インターフェースを使用するため、インターネット・トラフィックは VPN トンネルに送信されます。これが_フル・トンネル_です。

その他の考慮事項:

  • クライアントからの VPN トンネルを使用しないインターネット・アクセスでセキュリティー上の懸念がある場合は、フル・トンネル (デフォルト) モードを使用します。 フル・トンネルが必要になるのは通常、法規制上の標準に準拠させるためですが、このアプローチはコストがかかる場合があり、VPN サーバーの負荷も増大します。
  • スプリット・トンネル・モードでは、VPN サーバーから VPN クライアントに経路がプッシュされます。 これにより、OpenVPN クライアントは、どのトラフィックを VPN トンネルに送信するかを認識します。 経路を追加するときは、ルーティング・ループが発生しないように注意する必要があります。 例えば、VPN サーバーのパブリック IP アドレスが 3.3.3.3 の場合、経路 3.3.3.0/24 を追加することはできません。この経路は VPN トンネルを通過するべきではないトラフィックを 3.3.3.3 に送信するからです。 プライベート・サブネットは、VPC サブネット、CSE サブネット、オンプレミス・プライベート・サブネットなどの経路宛先としてのみ構成するのが理想的です。
  • VPN 経路は VPN クライアントにプッシュされます。 VPN クライアントに既に同じ宛先の経路がある場合、経路の「プッシュ」は失敗し、トラフィックは VPN サーバーに到達できません。 経路の競合に対処してから、VPN クライアントを再接続する必要があります。 よく問題が発生するのは、スプリット・トンネル・モードの VPN サーバーで宛先が 0.0.0.0/0 の VPN 経路を追加し、この経路を VPN クライアントにプッシュする必要がある場合です。 通常、VPN クライアントには宛先が 0.0.0.0/0 の経路が既に存在するため、この VPN 経路は VPN クライアント経路と競合します。 競合を回避するには、フル・トンネル・モードの VPN サーバーを使用するか、ホストの経路 0.0.0.0/0 を削除します。

どちらのトンネル・モードを選択する場合でも、API /vpn_servers/{id}/routes を使用して、VPN サーバーが VPN クライアントからトラフィックを転送する方法を定義する必要があります。 例えば、クライアントからのインターネット・トラフィックが VPN トンネルを経由するようにするには、VPN サービス経路 API を使用して 0.0.0.0/0 経路を構成する必要があります。

サポートされる VPN クライアント・ソフトウェア

ユーザーには、VPN クライアント・ソフトウェアを提供する必要があります。 以下のクライアント・ソフトウェア・バージョンの使用が検証されます。

  • macOS カタリナ以降の場合： OpenVPN Connect v3, OpenVPN Connect v2, and Tunnelblick 3.8.4
  • Windows 8 以降: OpenVPN Connect v3、 OpenVPN Connect v2
  • RHEL 7.x 以降： OpenVPN Connect v3, OpenVPN Connect v2, および OpenVPN コマンドラインクライアント (バージョン 2.4.4 以降)
  • Ubuntu 18.04 およびそれ以降： OpenVPN Connect v3, OpenVPN Connect v2, および OpenVPN コマンドラインクライアント（バージョン 2.4.10 以降）

VPN クライアント・ユーザーは、他の OpenVPN 2.4 対応のクライアント・ソフトウェアを選択できます。 ただし、リストされていないソフトウェアについては、動作が保証されていません。

IBM Power Virtual Servers: ワークスペースのデプロイメントを自動化

クライアントからサイトへの VPN 自動化プロジェクトを使用できます。このプロジェクトは、クライアントからサイトへの VPN サーバーを作成する Terraform モジュールを提供し、ユーザーがオンサイトまたはリモート・デバイスから Power Virtual Server ワークスペースに安全に接続できるようにします。 この自動化プロジェクトの Github リポジトリーは、 IBM にあります。 power-vpn-server Github リポジトリー。 このプロジェクトの README ファイル は、VPN サーバーを作成し、それを新規または既存の Power Virtual Server ワークスペースに接続して、 IBM Cloud Power インフラストラクチャーへのセキュアなアクセスを提供します。

Terraform を使用した VPN サーバーのセットアップ

Terraformを使ってVPNサーバーをセットアップするには、以下の手順に従ってください：

  1. IBM Cloud Secrets Manager のインスタンスをトライアルプランで作成します。

  2. サーバ証明書/鍵とクライアント証明書/鍵をローカルで生成し、 Secrets Manager インスタンスにインポートするか、 Secrets Manager サービスのプライベート証明書機能を使用して証明書/鍵を生成する。

    resource "ibm_resource_instance" "sec_mgr" {
  name              = "vpc-secmgr"
  service           = "secrets-manager"
  plan              = var.service_plan
  location          = var.region_name
  resource_group_id = data.ibm_resource_group.group.id

  timeouts {
   create = "30m"
   update = "30m"
   delete = "30m"
  }
}

resource "ibm_sm_secret_group" "sm_secret_group" {
  instance_id = ibm_resource_instance.sec_mgr[0].guid
  region      = var.region_name
  name        = "vpc-sec-group"
  description = "default secret group"
}

output "import_cert_server_crn" {
  value = ibm_sm_imported_certificate.sm_imported_certificate_server.crn
}

output "import_cert_client_crn" {
  value = ibm_sm_imported_certificate.sm_imported_certificate_client.crn
}

  3. サブネットを 1 つ持つ VPC を 1 つ作成します。

    resource "ibm_is_vpc" "vpc" {
  name = "vpc-vpnserver"
 }

resource "ibm_is_subnet" "subnet" {
  name                     = "mysubnet-tf"
  vpc                      = ibm_is_vpc.vpc.id
  zone                     = var.zone_name
  total_ipv4_address_count = 256
 }

  4. すべてのトラフィックを許可するインバウンド・ルールとアウトバウンド・ルールを持つセキュリティー・グループを作成します。

    resource "ibm_is_security_group" "sg_all" {
  name = "vpc-sg-all"
  vpc  = ibm_is_vpc.vpc.id
}

resource "ibm_is_security_group_rule" "sg_rule1" {
  group     = ibm_is_security_group.sg_all.id
  direction = "inbound"
  remote    = "0.0.0.0/0"
}

resource "ibm_is_security_group_rule" "sg_rule2" {
  group     = ibm_is_security_group.sg_all.id
  direction = "outbound"
  remote    = "0.0.0.0/0"
}

  5. Secrets Manager インスタンスのサブネット、セキュリティグループ、およびサーバー/クライアント証明書内に VPN サーバーを作成する。

    resource "ibm_is_vpn_server" "example" {
  certificate_crn = ibm_sm_imported_certificate.sm_imported_certificate_server.crn
client_authentication {
  method        = "certificate"
client_ca_crn = ibm_sm_imported_certificate.sm_imported_certificate_client.crn
}
 client_ip_pool         = "198.168.0.0/16"
 enable_split_tunneling = true
 name                   = "terry-vpn-server"
 port                   = 443
 protocol               = "tcp"
 subnets                = [ibm_is_subnet.subnet.id]
 security_groups        = [ibm_is_security_group.sg_all.id]
 }

resource "ibm_is_vpn_server_route" "cse1" {
  vpn_server  = ibm_is_vpn_server.example.id
  destination = "166.8.0.0/14"
  name        = "vpn-server-route-cse1"
 }

resource "ibm_is_vpn_server_route" "cse2" {
  vpn_server  = ibm_is_vpn_server.example.id
  destination = "161.26.0.0/16"
  name        = "vpn-server-route-cse2"
 }

  6. VPNクライアント・プロファイルをダウンロードし、クライアント・プロファイルにクライアント証明書とクライアント鍵を設定する。

    data "ibm_is_vpn_server_client_configuration" "my_vpn_client_conf" {
  vpn_server = ibm_is_vpn_server.example.id
}

resource "local_file" "my_vpn_client_conf" {
  content  = "${data.ibm_is_vpn_server_client_configuration.my_vpn_client_conf.vpn_server_client_configuration}\ncert ${path.cwd}/import_certs/client_cert.pem\nkey ${path.cwd}/import_certs/client_key.pem"
  filename = "my_vpn_server.ovpn"
}

    その後、ユーザーは、 OpenVPN クライアントで VPN クライアント・プロファイルを使用して、作成した VPN サーバーにクライアント・システムを接続できます。

詳細については、 IBM Terraform Registryを 参照のこと。