OpenVPNでプライベートAWSリソースへ安全にアクセスする方法【実践ガイド】

本記事は、Pluralsightの新コース「Connecting On-prem Resources to your AWS Infrastructure」の一部を基に再構成したものです。

Amazon Web Services（AWS）上で稼働しているリソースに接続したい場面はありませんか？公開EC2インスタンスへのSSHアクセスやS3データの暗号化だけなら、実用上十分に安全と言えます。しかし、バックエンドのRDSデータベースインスタンスへの接続や、一般公開していないAWS上のデータを扱う場合はどうでしょう？管理者がこうしたリソースを外部から遮断する理由はさまざまですが、必要なときにアクセスできなければ意味がありません。

そこで、リソースを守るACLやセキュリティグループを迂回しつつ、安全かつ信頼性の高いアクセス手段が必要になります。前述のコースで紹介している解決策の一つがDirect Connectですが、その価格設定が企業の予算を圧迫するようであれば、何らかのVPNトンネルが有効な代替案となるでしょう。

Virtual Private Network（VPN）とは？

VPNは、制限されたネットワーク活動の許可や匿名ブラウジングによく使われる技術です。しかし、本記事のテーマはそれではありません。

VPNとは、公衆ネットワークを経由して2つの拠点間でデータを安全にやり取りするためのポイント・ツー・ポイント接続です。事実上、地理的に離れた2つのプライベートサイトを1つのプライベートネットワークとして統合するトンネルを設計できます。今回の文脈では、ローカルオフィスのネットワークと、プライベートリソースをホストしているAWS VPCを接続することを指します。

この接続を実現する方法は2つあります。

• AWS Virtual Private Gateway上に構築されたマネージド型VPN接続を利用する
• 自前のVPNを構築する

本記事では、後者のDIY方式に焦点を当てます。

OpenVPN Access Server

名前の通り、OpenVPNはオープンソースプロジェクトであり、無料のコミュニティエディションをダウンロードして自分のVPNサーバーをセットアップすることも常に可能です。しかし、OpenVPN社はAWSとの親和性に優れた統合機能と自動設定ツールを最初から備えた、専用設計の「OpenVPN Access Server」をEC2 AMIとして提供しています。

筆者が見る限り、AMIをAWS VPC内で起動し、制御されたリモート接続を受け入れる形で構成するのが、この目的を達成するための事実上の「正攻法」になっています。

コストはどれくらいでしょうか？テスト目的だけで、同時に2つ以上の接続でVPNを使用する予定がないのであれば、AMI自体は無料です。EC2インスタンスの通常料金は別途発生しますが、アカウントがまだ無料利用枠（Free Tier）の対象であれば、それも無料で済みます。

VPNを実際の本番環境で稼働させる段階になると、必要な同時接続数に応じてライセンスを購入することになります。詳細は公式のライセンスページをご確認ください。

このガイドで行うこと

• OpenVPN Access ServerがプリインストールされたUbuntu AMIを選択し、VPC内にプロビジョニングして起動する
• SSHでサーバーにアクセスし、VPNを設定する
• 管理者ユーザーをセットアップする
• ローカルマシンをOpenVPNクライアントとして設定し、AWS VPC内のプライベートインスタンスに接続する

準備はいいですか？

OpenVPN Access Serverの起動

EC2ダッシュボードから、正しいAWSリージョンにいることを確認したうえで、VPNサーバーとして機能するインスタンスを起動します。クイックスタートAMIを使う代わりに、「AWS Marketplace」タブをクリックし、「openvpn access server」と検索します。OpenVPNは、接続可能なクライアント数が段階的に増えるライセンスに紐づいた複数の公式イメージを提供しています。

今回は「Bring Your Own License（BYOL）」方式のUbuntuイメージを採用します。先に触れた通り、今回の作業ではライセンスは実際には不要です。

AMIを選択するとポップアップが表示され、各インスタンスタイプとEBSストレージの選択肢における1時間あたりのコストがわかります。ただしこれらは通常のAWSインフラ費用のみで、ライセンス料は含まれていません。

インスタンスタイプは無料利用枠に収まるようt2.microにダウングレードします。負荷の高い本番サーバーであれば、もう少しスペックが必要になるかもしれません。

数分後に同じサブネット内で2つ目のインスタンスを起動する予定があるため、「Configure Instance Details」ページで例えば「us-east-1b」を選択し、後のために控えておきます。

次のセキュリティグループページこそ、OpenVPN AMI設定の真価が発揮される場所です。必要なポートがすべて開放されたセキュリティグループが提示されます。ポート22はサーバーへのSSHトラフィック用、943は管理GUIへのアクセス用、443はTLS暗号化HTTPトラフィック用、そして1194はOpenVPNが着信クライアント接続を待ち受けるポートです。

注意： 可能であれば、これらのルールを厳格化し、正当な会社のIPアドレス範囲からのリクエストのみを受け付けるようにするのが通常は良いプラクティスですが、短期間のテストであればこのままで問題ありません。

ここから設定内容を確認し、SSH暗号化キーが登録されていることを確かめて、起動を実行します。

インスタンスの起動後、重要なログイン情報——SSHでサーバーにログインするユーザーアカウントが「openvpnas」であることなど——とクイックスタートガイドが表示されます。同じ情報へのリンクを含むメールも届きます。

EC2インスタンスコンソールに戻ると、新しいマシンの起動が完了するのを待つ間に、パブリックIPアドレスが表示されています。もし将来的にインスタンスを再起動した場合、同じIPアドレスが再び割り当てられる保証はなく、それが原因で混乱が生じる可能性があります。そこで、インスタンスにElastic IPを割り当てておくのが賢明です。

そのためには、「Elastic IPs」をクリックし、「Allocate new address」を選択します。新しいアドレスを控えてページを閉じます。次に、そのアドレスを選択した状態で「Actions」→「Associate Address」をクリックします。「Instance」ボックスをクリックすると、便利なタグ付きのOpenVPNインスタンスが一覧に表示されます。それを選択して「Associate」をクリックすれば完了です。以降、これがサーバーへアクセスするための恒久的なパブリックIPとなります。

サーバーへのアクセス

このインスタンス用に設定したキーペアを指定したSSHコマンドの一部として、パブリックIPアドレスをターミナルに貼り付けます。

ssh -i KeyPairName.pem openvpnas@<PublicIPAddress>

WindowsやmacOSからアクセスする場合、手順が多少異なるかもしれませんが、公式ドキュメントに必要な情報はすべて記載されています。

ただし、Instancesコンソールを離れる前に、もう一つ重要な操作を行います。OpenVPNインスタンスを選択し、「Actions」→「Networking」→「Change Source/Dest checking」をクリックして、このチェックが無効になっていることを確認してください。これを怠ると、ほぼ何も機能しません。

次にSSHセッションに移ります。セッション開始直後にOpenVPNのEULA使用許諾契約が表示され、続いてセットアップウィザードが始まります。後で設定を変更したくなった場合は、次のコマンドでウィザードを再実行できます。

sudo ovpn-init — ec2.

ウィザードのデフォルト値のほとんどはそのまま問題ありませんが、何が行われているのか簡単に説明しておきましょう。質問項目と、必要に応じた補足コメントは以下の通りです。

primary Access Server node? yes [バックアップやフェイルオーバーノードを構築する場合はnoと答えます]
specify the network interface and IP address to be used by the Admin Web UI [1 — 全インターフェース対象。後で静的IPに変更可能]
specify the port number for the Admin Web UI [デフォルト]
specify the TCP port number for the OpenVPN Daemon [デフォルト]
Should client traffic be routed by default through the VPN? [no — 今回構築するのはこの種のVPNではありません。目的はリモートクライアントをVPCへ安全に接続することだけです。DNSトラフィックについても同様です]
Should client DNS traffic be routed by default through the VPN? [no]
Use local authentication via internal DB? [no — 有用な場合もありますが、ここではシンプルさのためLinux/AWS認証を使用します]
Should private subnets be accessible to clients by default? [yes — それこそがVPNの目的なのですから]
login to the Admin UI as “openvpn”? [yes]
Provide OpenVPN Access Server license key [テスト用途では不要]

ウィザードが完了すると接続情報がいくつか表示され、ネットワークタイムデーモンNTPのインストールを勧められます。このUbuntuマシンではNTPがデフォルトでインストールされ稼働しているため、対応は不要です。

先に述べたように、Web GUIにログインできるようopenvpnユーザーにパスワードを設定する必要があります。passwdコマンドをsudoで実行します。

sudo passwd openvpn

以上でサーバー側の作業はすべて完了です。次に、ブラウザでWeb GUIにログインします。サーバーのパブリックIPアドレスにセキュアなhttpsプレフィックスを付け、末尾に/adminを加えたURLにアクセスします。

https://<PublicIPAddress>/admin

証明書機関（CA）が発行したものではなく自己署名証明書を使用しているため、「接続がプライベートではありません」という警告が表示されます。

私たちの場合これは問題ありません。VPNを公開する相手は社内の限られたユーザーだけであり、彼らは私たちの証明書を信頼できるはずだからです。警告をクリックして進み、サインインしてEULAに同意しましょう。

時間があれば、OpenVPN管理コンソールが提供する機能を自分でいろいろと探索してみてください。

VPNクライアントの設定

続いて、先ほど案内されたWebアクセスアドレス（今度は/adminを付けずに）を開き、クライアントUIページにアクセスします。ここは単なるログイン画面で、先ほどと同じopenvpnユーザーで認証できます（新しいユーザーは管理コンソール側でいつでも作成できます）。

ログイン画面の背後にあるのは、各プラットフォーム向けOpenVPNクライアントアプリのインストール手順へのリンク集だけです。ただし最後のリンクだけは「Yourself（自分自身）」という名前になっています。

このリンクをクリックすると、client.ovpnというファイルのダウンロードと保存を求められます。このファイルには、サーバーに一致する設定情報と、認証に使用する実際のキーが含まれています。このファイルが悪意ある第三者の手に渡らないよう、必ず慎重に取り扱ってください。暗号化されていない接続経由での平文メール送信などは論外です。

ファイルをローカルで開いて中身をコピーします。次に、ローカルネットワーク内のLinux仮想マシン上のシェルで、client.ovpnという新しいファイルを作成し、コピーした内容を貼り付けます。先ほどクライアントUIの「OpenVPN for Linux」リンクを開いていれば、追加で必要な作業はAptパッケージマネージャーによるOpenVPNのインストールだけだと分かったはずです（CentOSやRed HatマシンならYum）。コマンド1つで完了します。終われば準備万端です。

nano client.ovpn
sudo apt update
sudo apt install openvpn

次にVPN接続を開きます。root権限（sudo）で、configフラグに先ほど作成したclient.ovpn設定ファイルを指定してopenvpnコマンドを実行します。

sudo openvpn — config client.ovpn

認証を求められたら、openvpnアカウントとサーバー上で作成したパスワードを使用します。

次に、ローカルクライアントでもう1つのシェルセッションを開き、OpenVPNサーバーのプライベートIPアドレスを使ってSSH接続を試みます。VPN接続が正常に機能していなければ不可能な操作です。

その前に、ip aコマンドを実行して、このマシンでアクティブなすべてのネットワークインターフェースを確認しておきましょう。

ip a

ローカルネットワークのインターフェースに加えて、tun0という名前のインターフェースが表示されるはずです。これはOpenVPNによって作成されたもので、通常172.16.x.xの範囲内にあります。

プライベートキー（当然ローカルに存在している必要があります）とサーバーのプライベートIPアドレスを使って、リモートサーバーにSSH接続します。成功すれば、あなたのVPNは完成です！

ssh -i KeyPairName.pem openvpnas@<PrivateIPAddress>

最後に、現在の設定のままVPN経由でAmazon VPC内の他のプライベートリソースにもアクセスできることを実証してみましょう。これは例えば、VPC内で稼働している公開できないデータベースインスタンスがある場合などに非常に役立ちます。

標準的なUbuntu EC2インスタンスを起動しますが、パブリックIPは割り当てません。話を簡単にするため、OpenVPNサーバーと同じus-east-1bサブネットを指定します。セキュリティグループはポート22経由のSSHアクセスのみを許可し、それ以外は一切許可しない設定にします。

起動が完了したら、そのプライベートIPアドレスを控えて、ローカルクライアントに戻ります。インスタンスが完全に起動したことを確認したら、同じプライベートキー、「ubuntu」ユーザー名（通常のUbuntu EC2インスタンスのデフォルト）、そして先ほどコピーしたプライベートアドレスを使ってSSH接続します。

成功しましたか？これで、AWSのプライベートリソースへの完全に構成されたVPN接続が手に入りました。この瞬間を噛みしめてください。

使用が終わったら、すべてのサーバーを停止し、Elastic IPアドレスを解放することをお忘れなく。不必要なコストを発生させたくはないはずです。

本記事は、Pluralsightの新コース「Connecting On-prem Resources to your AWS Infrastructure」の一部を基にしています。筆者のBootstrap ITサイトにはさらに多くのコンテンツがあります。著書『Linux in Action』へのリンクや、2時間超の動画と『Linux in Action』本文約40%で構成されるハイブリッドコース「Linux in Motion」などもぜひご覧ください。