トップ > AWS Client VPN > AWS Client VPNを分かりやすく解説してみる

AWS Client VPNを分かりやすく解説してみる

AWS Client VPN
記事タイトルとURLをコピーする

技術一課の杉村です。AWS Client VPN が東京リージョンにやってきました。

AWS Client VPN がアジアパシフィック (ムンバイ) と アジアパシフィック (東京) の 各AWS リージョンで利用可能に

特にエンタープライズのお客様にとっては、社内のシステムとリモートにいるクライアントPCを繋ぐいわゆるクライアントVPNはなじみ深いものです。

「ふむ、AWS Client VPNが東京リージョンに来たのか。検証しとくか！」と思いたちいざ触ってみると、初見では結構わかりづらい部分がありました。一度理解してしまえば簡単にクライアントVPNを実現できますので、AWS Client VPNの概念、そして実際の設定手順を解説してみたいと思います。

1. ざっくりポイント

AWS Client VPN のポイントを記載します。

  • VPC上に Client VPN Endpoint を作成することで、クライアント（普通のPCなど）とVPCの間でVPNを張ることができる
  • OpenVPN （オープンソースのVPNソフトウェア）を利用
  • 認証には “Active Directoryによるアカウント管理“, “サーバ証明書・クライアント証明書による相互認証“, “その両方” を利用できる
    • Active Directory認証では AWS Directory Serviceを利用。オンプレのADと連携したい場合は AD Connectorを噛ませることで可能
  • 利用料金は「(A) Client VPN Endpoint に関連付けられているサブネットの数 × 利用時間(hrs)」と「(B) アクティブなクライアント接続の数 × 利用時間(hrs)」に対して発生
    • 基本料金(A)と接続時間に応じた従量料金(B)のようなイメージ
    • AWS VPN の料金

2. AWS Client VPN のアーキテクチャ（構成図）

2. AWS Client VPN のアーキテクチャ（構成図）
証明書を利用した「相互認証」の場合を記載しています。

Client VPN Endpoint (①)を作成し、VPCのサブネット（1つまたは複数）に紐づけます。

認証に利用するサーバ証明書・クライアント証明書を AWS Certificate Manager (②)、通称 ACM に登録しておきます。
クライアント(③)にはOpenVPNクライアントをインストールし、クライアント証明書を配置します。

Client VPN Endpointの設定時にクライアントに割り当てるIPアドレスレンジを予めCIDR形式で指定するのですが「/22」以上の割り当てが必須です。（1022ホスト分ですね）

VPN接続が確立されると、クライアントPCはVPCのネットワークの一員として組み込まれ、プライベートIPが割り当てられます。VPC上のNAT Gatewayやプロキシサーバ、セキュリティ系の仮想アプラインスを通じてインターネットにアクセスさせることも可能です。

なおClient VPN経由でVPC内のリソースにアクセスするとき、接続元IPはClient VPN EndpointのENIのものになります。つまりクライアントからの通信は Client VPN Endpoint でいったんNATされているということ。SG設計にてポイントになります。

AWS Client VPN の構成要素の詳細な解説は、下記をご参照ください。
Client VPN のコンポーネント

3. セットアップしてみる

今回は証明書を利用した相互認証のパターンでセットアップしてみます。（Active Directory認証のパターンは、また後日検証してみます）

3-1. サーバ証明書・クライアント証明書の作成

下記の手順で、簡単にオリジナルのサーバ証明書・クライアント証明書が作成できました。
クライアント認証と認可
私は、Windows PCを利用していますので検証用AWSアカウントのEC2(Amazon Linux 2)で上記手順を実施しました。

上記の証明書作成作業をVPN接続を実施するクライアントPCとは別のマシン上で行う場合（今回の私がそうですね）、証明書および秘密鍵ファイル（上記ドキュメントではclient1.domain.tld.crtおよびclient1.domain.tld.key）はクライアントPCにセキュアな方法で転送しておいてください。

また、作成したサーバ証明書・クライアント証明書を AWS Certification Manager (ACM)に登録する必要があります。
前述の公式ドキュメントではAWS CLIを利用していますが、AWSマネジメントコンソールを利用してGUIでも簡単にインポートができます。（作成した証明書本体と、秘密鍵をテキスト情報で入力します。）
AWSマネジメントコンソールを利用した証明書のACMへのインポートの方法は、下記の弊社ブログをご参照ください。

blog.serverworks.co.jp

3-2. Client VPN Endpoint の作成

AWSマネジメントコンソールにログインし下記の手順で Client VPN Endpoint を作成します。おなじみの「VPC」の画面から作成できます。
ステップ 2: Client VPN エンドポイントを作成する

f:id:cmpokuma:20200507180120j:plain

エンドポイントの管理用の名前を決めたり、クライアントに割り当てるIPアドレスのCIDRを入力します。
利用するサーバ証明書・クライアント証明書を選択します。（ACMに登録された証明書を選択することができます）

クライアント接続のログを CloudWatch Logs に残すかどうかも選択できます。予め CloudWatch Logs にてロググループ、ログストリームを作成しておく必要があります。（詳細は割愛）

またオプションパラメータとしてクライアントが使用するDNSサーバやTLSセッションにTCP/UDPのどちらを利用するかを選択することができます。（今回はデフォルトのまま）

なお Client VPN Endpoint を作成した時点ではまだ利用料金は発生しません。
次の 3-3 でサブネットに紐づけた時点で、前述の料金(A)が発生し始めます。

3-3. Client VPN Endpoint をVPCのサブネットに紐づける

紐づけたサブネットに Client VPN Endpoint のENIが作成されます。ENIが作成された時点で料金が発生します。
ステップ 3: クライアントの VPN 接続を有効にする

f:id:cmpokuma:20200507180832j:plain

ここで関連付けるサブネットは、1つでも複数でも構いませんが、複数のサブネットを紐づけると、紐づけた数だけの料金（前述の(A)です）が発生します。

複数紐づける理由は可用性のためです。アベイラビリティゾーン(AZ)障害などで一つのサブネットが利用不可になってもクライアントからの接続が利用できるようにするためです。そのため複数紐づける場合には、それらのサブネットは別々のAZに属している必要があります。

サブネットを紐づけると Client VPN Endpoint には自動的にそのVPCのデフォルトセキュリティグループがアタッチされます。
別のセキュリティグループをアタッチすることで Client VPN Endpoint から VPC 内の別の ENI へのアクセス制御ができます。

f:id:cmpokuma:20200507181016j:plain

重要なことに、クライアントPCからVPN経由でVPC内のリソース等にアクセスすると接続元IPアドレスは Client VPN Endpoint になっています（NATされている）。接続先リソースのセキュリティグループ設計は、それを考慮する必要があります。

3-4. クライアントのアクセスの「承認」

これだけではまだ、クライアントPCからVPCへは通信できません。
クライアントPCからVPC内のどのIPレンジへの通信を許可するか、CIDR形式で許可します。
ステップ 4: クライアントのネットワークへのアクセスを承認する

f:id:cmpokuma:20200507181426j:plain

マネジメントコンソールで当該 Client VPN Endpoint を選択し”認証”タブを選択すると、クライアントPCから接続可能な接続先一覧が表示され、許可を追加することができます。
デフォルトではどのCIDRも許可されていないので、接続先を追加します。
VPC内の特定のCIDRのみを許可すれば、クライアントPCからはその範囲までにしかアクセスできません。

もしNAT Gatewayや仮想アプライアンス経由でインターネットに出ることを許可したければ、0.0.0.0/0への通信を許可する必要があります。（インターネットへ抜ける方法については、それ以外にも設定が必要ですがそれは次の項）

3-5. 追加のネットワークへのアクセスを有効にする（追加設定）

Client VPN Endpoint には「ルートテーブル」の設定があります。
ステップ 5: (オプション) 追加のネットワークへのアクセスを有効にする

クライアントPCからVPC内にだけ通信するだけであればデフォルト設定でOKなので、追加設定は不要です。
クライアントPCから「NAT Gateway経由でインターネットに接続させる」あるいは「VPC Peering経由で別のVPCに接続させる」などのルートを設定したいときだけ、追加設定が必要です。

f:id:cmpokuma:20200507181636j:plain

Client VPN Endpoint のルートテーブルの概念はちょっと理解が難しいので例で説明します。

Client VPN Endpoint のルートテーブルのレコード追加時には「宛先のCIDR」「ターゲットサブネット」の2つを指定します。
“宛先のCIDR=0.0.0.0/0, ターゲットサブネット=subnet-01234567890abcdef” を追加したとしましょう。

この場合、クライアントPCがVPN経由で インターネット上のWebサーバに接続しようしてVPN経由でパケットが Client VPN Endpoint にまで到達すると、その後パケットは subnet-01234567890abcdef を経由して、そのサブネットのルートテーブルに従います。
subnet-01234567890abcdef のルートテーブルに「0.0.0.0/0 -> NAT Gateway」というルートがあれば、NAT Gateway経由でインターネットに接続しにいきます。あるいは「0.0.0.0/0 -> 仮想アプライアンスのENI」というルートも可能です。

また「0.0.0.0/0 -> Internet Gateway」というルートも可能のようですが、VPCの設定で「パブリック IPv4 アドレスの自動割り当て : true」である必要があります。これは Client VPN Endpoint のENIがパブリックIPを持つ必要があるからでしょう。

（デフォルトでは Client VPN Endpoint にサブネットを紐づけた時点で “宛先のCIDR=<対象VPCのCIDR>, ターゲットサブネット=<紐づけたサブネット>” が作成され、VPC内にのみ接続させる場合はこれで十分）

つまり Client VPN Endpoint のルートテーブルは、宛先CIDRごとにパケットが経由するサブネットを定義するものと理解できます。
ただし、ターゲットサブネットは手順3-3で関連付けた「関連付けられたサブネット」の中からしか設定することができません。

もう一例、クライアントVPN→ Client VPN Endpoint → VPC-A → VPC Peering → VPC-B という経路を設定することを考えます。

Client VPN Endpoint のルートテーブルに “宛先のCIDR=＜VPC-BのCIDR＞, ターゲットサブネット=＜VPC-BへのVPC Peeringへのルートを持つサブネット＞” と設定すればよいわけです。

3-6. クライアント用のVPN Endpoint設定をDLする

クライアント用のVPN Endpoint設定をDLして、クライアントソフトに設定します。
ステップ 6: Client VPN エンドポイントの設定ファイルをダウンロードする

f:id:cmpokuma:20200507181953j:plain

マネジメントコンソールで当該 Client VPN Endpoint を選択し、上部に表示される青い「クライアント設定のダウンロード」ボタンを押せばDLできます。
「.ovpn」という拡張子の設定ファイルをクライアントPCにダウンロードします。

.ovpn設定ファイル、クライアント証明書、証明書の秘密鍵をクライアントソフトの設定ファイル用フォルダに配置します。

この.ovpnファイルはテキストなので、普通のテキストエディタで開くことができます。ファイルの末尾に以下を追記します。

cert ＜クライアント証明書へのファイルパス＞
key ＜証明書の秘密鍵へのファイルパス＞

以下は例ですが、Windows PCがクライアントの場合、以下のようになります。\（バックスラッシュ）はエスケープする必要があるので2つ繋げています。

cert C:\\Users\\username\\OpenVPN\\config\\client1.domain.tld.crt
key C:\\Users\\username\\OpenVPN\\config\\client1.domain.tld.key

これで晴れて設定完了です。
クライアントソフトで接続を確立してみましょう。VPC内のリソースに接続できるはずです。

「接続」タブでクライアント接続の履歴を確認できます。

f:id:cmpokuma:20200507182339j:plain

4. いろいろな経路設定

4-1. Client VPNの要素の整理

ここまでの設定手順では、いろいろな要素… ルートテーブルや承認設定、関連付けサブネットなどが出てきて、少し混乱しているかもしれません。
改めて整理をしてみます。

「サブネットの関連付け」
→VPCのどのサブネットに Client VPN Endpoint 用のENIを作成するかを指定するものです。可用性のために複数のAZのサブネットに指定することができます。（ただし1つのAZにつき1サブネットまで）

「承認」
→クライアントがどのIPレンジに接続できるか許可するものです。

「セキュリティグループ」
→ Client VPN Endpoint 用のENIにアタッチするSGです。クライアントからの通信は Client VPN Endpoint のENIでNATされるのでこのSGを接続元として、接続先のSGで制御することができます。

「 Client VPN Endpoint のルートテーブル」
→通信先の経路(CIDR)ごとに、経由するサブネットを指定するものです。ただし経由するサブネットは「サブネットの関連付け」で関連付けられたサブネットの中から選ぶことになります。例えば、0.0.0.0/0のターゲットサブネットとして0.0.0.0/0->NAT Gatewayというルートを持つサブネットを指定すれば、クライアントはNAT Gatewayからインターネットへ出られます。

4-2. 例:クライアントからVPN経由・NAT Gateway経由でインターネットに出られる設定

「サブネットの関連付け」で Client VPN Endpoint とVPCのどれかのサブネットを関連付けます。ただしそのサブネットは0.0.0.0/0->NAT Gatewayというルートを持っています。

「承認」で0.0.0.0/0を承認します。

「セキュリティグループ」にて、0.0.0.0/0に対するアウトバウンド通信が許可されたSGをアタッチします。

「 Client VPN Endpoint のルートテーブル」で、0.0.0.0/0のターゲットサブネットとして先ほど関連付けたサブネットを指定します。

4-3. 例: クライアントからVPC Peering経由で他VPCに接続する設定

「サブネットの関連付け」で Client VPN Endpoint とVPCのどれかのサブネットを関連付けます。ただしそのサブネットはVPC Peeringへのルートを持っています。

「承認」で他VPCのCIDRを承認します。

「セキュリティグループ」にて、他VPCのCIDRに対するアウトバウンド通信が許可されたSGをアタッチします。

「 Client VPN Endpoint のルートテーブル」で、＜他VPCのCIDR＞のターゲットサブネットとして先ほど関連付けたサブネットを指定します。

5. 制限事項

Client VPN機能の制約事項は以下に記載されています。
Client VPN の制約事項

重要なものを抜粋します。

クライアント CIDR 範囲は、関連付けられたサブネットが配置されている VPC のローカル CIDR、または Client VPN エンドポイントのルートテーブルに手動で追加されたルートと重複することはできません。

→ Client VPN Endpoint の作成時に指定するクライアントのCIDR範囲は、VPCとかぶってはいけません。VPC Peering経由で他VPCなどに接続させる場合は、そことかぶってもいけません。
→ なおクライアントのCIDRが 192.168.x.x/16で、VPCが10.x.x.x/16など、被っていなければクラスがまたがっていてもOKです。

上記ドキュメントに記載されていない制限事項として、以下も確認できました。

  • 1つの Client VPN Endpoint に複数のクライアント証明書を登録することはできない
    • ただし作成時に登録したクライアント証明書と同一の認証機関 (発行者)から発行された証明書であれば、ACM にアップロードすることなく利用可能…これをもって証明書を追加できる
  • Client VPN Endpoint に登録したクライアント証明書を入れ替える（置き換える）ことはできない
    • ただしクライアント証明書失効リスト（いわゆるCRL）は設定可能
    • 前述の証明書追加方法とあわせて、置き換えのように利用可能

6. 最後に

私が初めて AWS Client VPN を検証したときになかなか仕様が理解できなかったため、他の方に参考になるよう解説・参考したものになります。とくにターゲットネットワーク・ルート・承認ルール・セキュリティグループ・NATの仕様…という部分が分かりづらかったため、整理してみた次第です。

今回は証明書を利用した相互認証の方法を紹介しましたが、そのうちActive Directory認証も検証してみたいと思います。

杉村 勇馬 (記事一覧)

サーバーワークス → 株式会社G-gen 執行役員CTO

2021 Japan APN Ambassadors / 2021 APN All AWS Certifications Engineers

マルチAWSアカウント管理運用やネットワーク関係のAWSサービスに関するブログ記事を過去に執筆。

2021年09月から株式会社G-genに出向、Google Cloud(GCP)が専門に。G-genでもGoogle Cloud (GCP) の技術ブログを執筆中。