ACM で発行したパブリック証明書で Client VPN を構築してみた
はじめに
みなさま Xin chao !
最近でこそお問い合わせは落ち着いてきましたが、昨今の社会的な事情から、リモートワーク環境を早期に整備することを求められた IT 管理者の方は多かったのではないでしょうか。 AWS では、AWS 上に構築したリソースに、または、Direct Connect 等を介してオンプレミス環境に、安全にアクセスするための手段として AWS Client VPN を提供しています。
OpenVPN をベースとしたクライアント VPN のマネージドサービスであり、VPN 基盤側の管理は AWS が代行してくれるため、IT 管理者は VPN クライアント側の整備に集中することができます。
Client VPN で忘れがちなこと
証明書の管理
Client VPN の認証方法には、以下の 3 つの方法があります (詳細については、公式ドキュメントをご参照ください)。
- Active Directory 認証 (ユーザーベース)
- 相互認証 (証明書ベース)
- シングルサインオン (SAML ベースのフェデレーション認証) (ユーザーベース)
相互認証 (証明書ベース) を使っていなければ証明書の管理なんて不要では？ と思うかもしれませんが、VPN クライアントの接続先となる Client VPN エンドポイントでも、証明書 (＝サーバー証明書) が使用されています。 Client VPN エンドポイントの作成手順にも、サーバー証明書 ARN の入力を求められることが記されています。
クライアント VPN エンドポイント - AWS VPN 管理者ガイド
したがって、相互認証 (証明書ベース) を使用していない環境でも、証明書の管理 (具体的には証明書の有効期限に基づいた証明書の更新) は必要になります。
できればサーバー証明書の有効期限とか更新とか考えたくない・・・
一般的に IT 管理者の方は忙しいので、証明書の有効期限を意識したり、新しい有効期限を持った証明書を作成したり、といったこと考えたくない！ という方も少なくないのではないでしょうか。
そんな悩みを少しだけ解決するために、今回は、ACM (＝AWS Certificate Manager) で発行したパブリック証明書を、Client VPN エンドポイントのサーバー証明書として使って、Client VPN 環境を構築してみたいと思います。
ACM で発行したパブリック証明書で Client VPN を構築してみる
構成図
今回構築するのは、以下のような環境です。 オンプレミス環境 (想定の VPC 上) のサーバーに対して、Direct Connect (想定の VPC Peering) を介して疎通確認してみます。
要件
想定する要件は以下の通りです。
- VPN クライアントはオンプレミス環境のサーバーにアクセスする
- Client VPN は Active Directory 認証を使用する
- Active Directory ドメインコントローラーはオンプレミス環境で稼働中のサーバーを利用する
- Client VPN エンドポイントで使用されるサーバー証明書は、有効期限を意識する必要がないよう自動的に更新されるようにする
前提
すでに以下の環境については構成済みの状態から始めます。
- オンプレミス環境想定の VPC および Active Directory ドメインコントローラー兼 DNS サーバー
- AD Connector 用のユーザー (権限をサービスアカウントに委任する - AWS Directory Service 管理者ガイド 参照)
- Client VPN エンドポイントを関連付けする VPC
- Direct Connect 想定の VPC Peering 接続
- VPC 間の通信に必要なルートテーブルの設定
- オンプレミス環境想定のサーバーで受信許可を行うためのセキュリティグループの設定
- パブリック証明書の発行に必要なドメインの取得およびパブリックホストゾーンの登録
ACM でパブリック証明書を発行する
CloudFront や ELB で使用する際と同じように、ACM マネジメントコンソールで証明書をリクエストします。
「パブリック証明書のリクエスト」を選択します。
証明書に付与する「ドメイン名」を入力します。 今回は取得済みのドメインを使った clientvpnendpoint.masawo.classmethod.info にしました。
証明書リクエストの検証方法を選択します。 人間によるアクションを極力少なくしたいため、今回は「DNS の検証」を選択しています。
タグは必要に応じて追加可能です。 今回は何も追加していません。
ドメイン名と検証方法を再度確認して、[確定とリクエスト] をクリックします。
この時点で、リクエストしたパブリック証明書はドメイン検証が完了していないため、"検証保留中" の状態になっています。 今回使用している masawo.classmethod.info は Route 53 でホストしているので、[Route 53 でのレコードの作成] をクリックし、DNS 検証に必要な CNAME レコードを自動的に作成します。 Route 53 でホストしていない場合は、コピペする等して必要な CNANE レコードを登録します。
Route 53 マネジメントコンソールで、ホストゾーンにドメイン検証用のレコードが正しく作成されたことを確認できました。
しばらくすると、リクエストしたパブリック証明書の検証状態が "成功" に変わります (今回の場合、検証用レコード作成後、数十秒で変わりました)。
以上で ACM によるパブリック証明書の発行が完了しました。 このパブリック証明書は、後の手順の Client VPN エンドポイントの作成に使用します。
AD Connector を作成する
Directory Service マネジメントコンソールで、Client VPN の Active Directory 認証に使用するための AD Connector を作成していきます。
「ディレクトリタイプ」は、「AD Connector」を選択します。
検証環境なので、「ディレクトリのサイズ」は「スモール」を選択しています。 実稼働環境では、実情に合わせて選択する必要があります。
AD Connector を配置する「VPC」「サブネット」を選択します。
オンプレミス環境の Active Directory の「ディレクトリの DNS 名」「ディレクトリの NetBIOS 名」「DNS IP アドレス」、さらに事前に用意しておいた AD Connector 用の「サービスアカウントのユーザー名」「サービスアカウントのパスワード」を入力します。
入力した内容を確認して、[ディレクトリの作成] をクリックします。
しばらく待って、「ステータス」が "作成中" → "アクティブ” になれば、AD Connector の作成は完了です。
Client VPN エンドポイントに付与するセキュリティグループを作成する
EC2 マネジメントコンソールで、Client VPN エンドポイントに付与するセキュリティグループを作成します。 「VPC」については、Client VPN エンドポイントを関連付ける VPC を選択します。
「インバウンドルール」には何も指定しません (仮に何らかのルールを登録しても、VPC 内のリソースや DX を介したオンプレミス環境等から VPN クライアントを宛先とした通信はできない仕様になっています)。 「アウトバウンドルール」については、今回はすべてのトラフィックを許可しています。
Client VPN エンドポイントを作成する
VPC マネジメントコンソールで、Client VPN エンドポイントを作成していきます。
Client VPN エンドポイントに付与する「名前タグ」、および、Client VPN エンドポイントに接続された VPN クライアントに付与する「クライアント IPv4 CIDR」を登録します。 CIDR は、VPN クライアントが通信する可能性のある宛先と重複しない /12 ～ /22 の IP アドレス範囲を指定します。 また、忘れがちな考慮事項として、想定する VPN クライアント最大同時接続数の 2 倍の数の IP アドレスが確保できる CIDR 範囲にすることが推奨されています。
クライアント VPN エンドポイントを作成するときは、クライアント CIDR 範囲を指定する必要があります。これは、/12 と /22 ネットマスクの間の IPv4 CIDR ブロックです。クライアント VPN エンドポイントへのそれぞれの VPN 接続には、クライアント CIDR 範囲から固有の IP アドレスが割り当てられます。クライアント CIDR 範囲内のアドレスの一部は、クライアント VPN エンドポイントの可用性モデルをサポートするためにも使用され、クライアントに割り当てることはできません。クライアント VPN エンドポイントの作成後にクライアント CIDR 範囲を変更することはできません。
一般に、クライアント VPN エンドポイントでサポートする予定の IP アドレス (つまり同時接続) の 2 倍の数を含むクライアント CIDR 範囲を指定することをお勧めします。
(クライアント VPN スケーリングに関する考慮事項 - AWS VPN 管理者ガイド より抜粋)
Client VPN エンドポイントで使用する「サーバー証明書 ARN」として、前の手順で作成した ACM パブリック証明書を選択します。
認証方法として「ユーザーベースの認証を使用」「Active Directory 認証」を選択し、「ディレクトリ ID」として前の手順で作成した AD Connector を選択します。
接続ログおよびクライアント接続ハンドラについては、今回はいずれも「いいえ」を選択しています。 実稼働環境では。接続ログを記録することを検討しましょう。
「その他のオプションパラメータ」を指定し、[クライアント VPN エンドポイントの作成] をクリックします。 それぞれ、実際の環境に合わせて設定する必要があります。
- DNS サーバー 1 IP アドレス ・・・ オンプレミス環境想定の DNS サーバーの IP アドレス
- スプリットトンネルを有効にする ・・・ ON (今回の環境では VPN クライアントとして使用している EC2 にインターネット経由でリモートデスクトップ接続する必要があるため有効にしています)
- VPC ID ・・・ Client VPN エンドポイントを関連付けする VPC を指定
- セキュリティグループ ID ・・・ 前の手順で作成したセキュリティグループを指定
- サービスポータルを有効にする ・・・ ON (今回の環境では設定ファイルを利用者側でダウンロードしてもらう想定のため有効にしています)
Client VPN エンドポイントが作成されましたが、この時点では、VPC に関連付けされていないため、"保留中" になっています。
[関連付け] をクリックします。
Client VPN エンドポイントを関連付けする「VPC」「サブネット」を選択し [関連付け] をクリックします。 実稼働環境では、AZ 障害と Client VPN 利用料金を考慮したうえで、複数のサブネットへの関連付けも検討しましょう。
"使用可能" になりました。
Client VPN エンドポイントを関連付けた VPC 以外の環境となるオンプレミス環境 (想定の VPC) への通信も必要なため、ルートテーブルの追加も行います。
「ルート送信先」にオンプレミス環境 (想定の VPC) CIDR を指定し、「ターゲット VPC サブネット ID」に Client VPN エンドポイントが関連付けられているサブネットを選択します。
オンプレミス環境 (想定の VPC) へのルートが作成されました。
さらに、オンプレミス環境 (想定の VPC) へのアクセス許可を与えるため、承認ルールの追加も行います。
「アクセスを有効にする送信先ネット」にオンプレミス環境 (想定の VPC) CIDR を指定し、「アクセスを付与する対象」として "すべてのユーザーにアクセスを許可する" を選択します。 実稼働環境では、必要に応じて "特定のアクセスグループのユーザーへのアクセスを許可する" を選択することも検討します。
承認ルールが追加されました。 ここまでの手順で、Client VPN エンドポイントの準備が整いました。
Client VPN クライアントの設定を行う
VPN クライアント (想定の EC2) に、VPN クライアントアプリのインストールを行います。 今回は、OpenVPN クライアント (ブログ執筆時点での最新バージョン 2.5.3) を使用しています。
クライアント設定ファイルをダウンロードするために、VPN クライアント (想定の EC2) から Client VPN セルフサービスポータルにアクセスします。 Client VPN セルフポータルの URL は、マネジメントコンソールの Client VPN エンドポイント概要欄で確認することができます。
Client VPN 接続時に使用する Active Directory ユーザー名とパスワードを入力しログインします。
[Download client configuration] をクリックして、クライアント設定ファイルをダウンロードします。
ダウンロードしたクライアント設定ファイルは、OpenVPN クライアントのインストールフォルダ配下の config フォルダにコピーします。
接続確認
VPN クライアント (想定の EC2) から接続します。
Active Directory ユーザー名とパスワードを入力し [OK] をクリックします。
無事接続できました！
オンプレミス環境想定の DNS サーバー対し PING を打ったところ、無事に疎通確認できました！
おわりに
Client VPN エンドポイントで使用するサーバー証明書は ACM でプロビジョニングする必要がある、という Client VPN の仕様から、アップロードした自己証明書だけでなく、きっと ACM で発行したパブリック証明書も使えるのだろうとは想像していましたが、実際に試したことはありませんでした。
ACM で発行したパブリック証明書＋DNS 検証であれば、検証用の CNAME レコードを消さない限り、証明書の有効期限が近づいた際も証明書の更新が自動で行われるので、証明書の有効期限切れにより Client VPN が利用できなくなるような事態を避けることができます。
一方で、それを目的に、相互認証 (証明書ベース) の利用を断念するというのは本末転倒だと思いますので、Client VPN に対する要件をよく検討したうえで、メリットがあるようであれば ACM で発行したパブリック証明書を活用する、という感じが良いのではないかと思います。
個人的には、手軽にサクっと Client VPN 環境を構築したい、という場合に活用していきたいと思います。
追伸) 7 月 7 日のクラスメソッド創立記念日にブログを書いてお祝い！ の流れに何とか乗れてよかった！
