「開発チームのメンバー全員にVPNアクセスを配布したいが、どこで設定すればいいのか分からない」
こうした課題を解決するのがAWS Client VPNだ。Site-to-Site VPNがオンプレミスのネットワーク全体をVPCに接続するのに対し、Client VPNはエンジニアのPCなど個々のデバイスからVPCへのリモートアクセスを実現する。
この記事では、Client VPNのエンドポイント設計・証明書の準備・ルーティング設定・動作確認まで実践的な手順を解説する。スプリットトンネルとフルトンネルの使い分け、マルチAZでの冗長設計ポイントも含めて解説するので、セキュアなリモートアクセス環境を設計する際の参考にしてほしい。動作確認はAWS CLI(v2.15)+Ubuntu 24.04 LTS上のOpenVPN 2.6で実施した。
この記事のポイント
・AWS Client VPNで個々のデバイスからVPCへセキュアに接続できる
・相互TLS認証ではEasy-RSAで証明書を発行しACMに登録する
・スプリットトンネルを有効にするとVPC宛の通信のみVPN経由になる
・複数AZのサブネットに関連付けることで冗長性を確保できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Site-to-Site VPNとClient VPNの違い(どちらを選ぶか)
AWSのVPN製品は大きく2種類に分かれる。・Site-to-Site VPN: オフィスのルーターやファイアウォール(Customer Gateway)とVPCをIPsecで接続する。オンプレミスのサーバー群とEC2が相互に通信できる拠点間VPN。
・Client VPN: エンジニアのPCやノートPCにVPNクライアントをインストールし、VPCへ直接リモートアクセスする方式。SSL/TLSベース(OpenVPN互換)。
判断の目安は次のとおりだ。
・Client VPNを選ぶ場合: リモートワーカーや開発者が自宅からVPC内のリソースに直接アクセスしたい、踏み台EC2を廃止してSSH接続を整理したい
・Site-to-Site VPNを選ぶ場合: オフィスとAWSをネットワーク単位で接続したい、サーバー間の自動通信(バッチ・レプリケーション)を安定させたい
Client VPNはOpenVPN互換のため、AWS公式クライアント(AWS VPN Client)のほかに標準のOpenVPNクライアントでも接続できる。
AWS Client VPNの設計全体像
Client VPNの構成要素を把握してから設計に入ると、設定項目の意味が理解しやすくなる。1. 証明書の準備(Easy-RSAとACM)
認証方法は3種類あるが、まず試す場合は相互TLS認証(証明書ベース)が最もシンプルだ。・相互TLS(Certificate): サーバー証明書+クライアント証明書。設定が最もシンプル。
・Active Directory: AWS Managed ADまたはSimple ADと連携。既存のAD環境がある場合に有効。
・SAML2.0フェデレーション: OktaやAzure ADなどのIdPと連携。SSO環境に組み込みたい場合。
相互TLS認証では、サーバー証明書とクライアント証明書の両方をAWS Certificate Manager(ACM)に登録する。Easy-RSAで作成した自己署名証明書を使う手順を以下に示す。
Ubuntu/Debianの場合はaptでEasy-RSAをインストールできる。
# Easy-RSA をインストール sudo apt install easy-rsa -y # PKI ディレクトリを初期化 make-cadir ~/client-vpn-pki cd ~/client-vpn-pki ./easyrsa init-pki # CA 証明書を作成(Common Name は任意) ./easyrsa build-ca nopass # サーバー証明書を作成 ./easyrsa build-server-full server nopass # クライアント証明書を作成(クライアントごとに別名を付ける) ./easyrsa build-client-full client1 nopass
# サーバー証明書を ACM にインポート aws acm import-certificate --certificate fileb://pki/issued/server.crt --private-key fileb://pki/private/server.key --certificate-chain fileb://pki/ca.crt --region ap-northeast-1 # クライアント証明書を ACM にインポート aws acm import-certificate --certificate fileb://pki/issued/client1.crt --private-key fileb://pki/private/client1.key --certificate-chain fileb://pki/ca.crt --region ap-northeast-1
{ "CertificateArn": "arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }
2. Client VPNエンドポイントの作成
エンドポイント作成時に必要なパラメーターは次のとおりだ。・クライアントCIDR: VPNクライアントに割り当てるIPアドレス帯。VPCのCIDRと重複してはいけない。/22以上の広さが必要(例: 192.168.100.0/22)。
・サーバー証明書ARN: ACMにインポートしたサーバー証明書のARN。
・クライアント証明書ARN: 相互TLSの場合はACMにインポートしたクライアントCA証明書のARN。
・スプリットトンネル: 有効にするとVPC向けトラフィックのみVPN経由になる。
# Client VPN エンドポイントの作成(相互TLS・スプリットトンネル有効) aws ec2 create-client-vpn-endpoint --client-cidr-block 192.168.100.0/22 --server-certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/server-arn --authentication-options Type=certificate-authentication,MutualAuthentication={ClientRootCertificateChainArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/client-arn} --connection-log-options Enabled=false --split-tunnel --vpc-id vpc-0123456789abcdef0 --security-group-ids sg-0abc123def456gh78 --region ap-northeast-1
3. サブネット関連付けとルーティング設計
エンドポイントが作成できたら、対象のサブネットに関連付ける。関連付けるサブネット数だけAZに対応できる。マルチAZ冗長を考えると2つ以上のサブネットに関連付けるのが基本だ。# サブネットに関連付け(2つのAZのプライベートサブネットを指定) aws ec2 associate-client-vpn-target-network --client-vpn-endpoint-id cvpn-endpoint-xxxxxxxxxxxxxxxxx --subnet-id subnet-0aaabbbccc111 --region ap-northeast-1 aws ec2 associate-client-vpn-target-network --client-vpn-endpoint-id cvpn-endpoint-xxxxxxxxxxxxxxxxx --subnet-id subnet-0dddeeefff222 --region ap-northeast-1
# VPC CIDR(10.0.0.0/16)へのルートを追加 aws ec2 create-client-vpn-route --client-vpn-endpoint-id cvpn-endpoint-xxxxxxxxxxxxxxxxx --destination-cidr-block 10.0.0.0/16 --target-vpc-subnet-id subnet-0aaabbbccc111 --region ap-northeast-1
認証ルールとスプリットトンネルの設定
1. 認証ルール(Authorization Rules)の設定
エンドポイントとルートを設定しただけでは、クライアントからの通信は通らない。認証ルールで「誰がどのCIDRに接続できるか」を明示的に許可する必要がある。# VPC 全体(10.0.0.0/16)へのアクセスを全クライアントに許可 aws ec2 authorize-client-vpn-ingress --client-vpn-endpoint-id cvpn-endpoint-xxxxxxxxxxxxxxxxx --target-network-cidr 10.0.0.0/16 --authorize-all-groups --region ap-northeast-1
EC2側のセキュリティグループにも設定が必要だ。VPNクライアントに払い出されるCIDR(192.168.100.0/22)からのインバウンドを許可するルールを追加しておく。
# EC2 セキュリティグループに VPN クライアント CIDR からの SSH を許可 aws ec2 authorize-security-group-ingress --group-id sg-0ec2instance1234 --protocol tcp --port 22 --cidr 192.168.100.0/22 --region ap-northeast-1
2. スプリットトンネル vs フルトンネルの選択
・スプリットトンネル(推奨): VPC宛(10.0.0.0/16など)のトラフィックのみVPN経由。インターネット通信はクライアントのローカル回線をそのまま使う。通信コストと遅延が抑えられる。・フルトンネル: 全トラフィックをVPN経由でルーティング。インターネット通信もVPC内のNATゲートウェイを通過する。セキュリティポリシー上、全通信を管理したい場合に使う。ただしNATゲートウェイのデータ転送コストがかさむ点に注意が必要だ。
本番環境ではスプリットトンネルがコスト効率の面で有利なため、特別な理由がない限りスプリットトンネルを選択するとよい。
接続テストと動作確認
1. OpenVPNクライアントでの接続
マネジメントコンソールからクライアント設定ファイル(.ovpnファイル)をダウンロードし、クライアント証明書の情報を追記する。# ダウンロードした .ovpn ファイルに証明書と鍵を追記 cat >> downloaded-config.ovpn << 'OVPNEOF'
-----BEGIN CERTIFICATE----- MIIDpDCCAoygAwIBAgIRAK(省略) -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- MIIEvAIBADANBgkqhkiG9w0(省略) -----END PRIVATE KEY----- OVPNEOF # OpenVPN で接続 sudo openvpn --config downloaded-config.ovpn --daemon
2026-08-06 17:33:10 TCP connection established with [AF_INET]13.xx.xxx.xxx:443 2026-08-06 17:33:11 [server] Peer Connection Initiated with [AF_INET]13.xx.xxx.xxx:443 2026-08-06 17:33:12 TUN/TAP device tun0 opened 2026-08-06 17:33:12 net_iface_up: set tun0 up 2026-08-06 17:33:12 Initialization Sequence Completed
2. ルーティングの確認
接続後、クライアントPCのルーティングテーブルを確認する。スプリットトンネル有効の場合、VPCのCIDR(10.0.0.0/16)だけがVPN経由になっているはずだ。# Linux クライアントでルートを確認 ip route show | grep tun0 # 出力例(スプリットトンネル有効時) 10.0.0.0/16 via 192.168.100.1 dev tun0 192.168.100.0/22 via 192.168.100.1 dev tun0
# VPC 内の EC2 に SSH 接続(プライベートIPで直接アクセス) ssh -i ~/.ssh/mykey.pem ec2-user@10.0.1.100 # 成功すると次のように表示される [ec2-user@ip-10-0-1-100 ~]$
マルチAZ冗長設計のポイント
Client VPNエンドポイントは、関連付けるサブネットのAZの数だけ冗長化される。2つのAZに関連付けておくと、一方のAZで障害が発生してもVPN接続が維持される。・2つ以上のAZのサブネットに関連付ける: ap-northeast-1aとap-northeast-1cのプライベートサブネットを指定する。
・エンドポイントのDNS名を使う: Client VPNエンドポイントはAWSが管理するDNS名を持ち、複数のAZへの接続を自動で振り分ける。クライアント設定ファイルにIPアドレスをハードコードしない。
・関連付けるサブネットはプライベートサブネット推奨: パブリックサブネットに関連付けても動作するが、セキュリティ設計上はプライベートサブネットが望ましい。
VPNの接続状況は次のコマンドで確認できる。
# Client VPN エンドポイントの状態確認 aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-xxxxxxxxxxxxxxxxx --query 'ClientVpnEndpoints[0].{Status:Status.Code,VpcId:VpcId,SplitTunnel:SplitTunnel}' --output table # 出力例 --------------------------------------------- | DescribeClientVpnEndpoints | +---------------+-----------+---------------+ | SplitTunnel | Status | VpcId | +---------------+-----------+---------------+ | True | available | vpc-0123456789| +---------------+-----------+---------------+
トラブルシューティング
Client VPNのセットアップで詰まりやすいポイントをまとめた。1. 「TLS Error: TLS handshake failed」が出る
証明書の不一致またはCA証明書の指定ミスが原因であることが多い。サーバー証明書とクライアント証明書が同じCAで署名されているかを確認する。ACMにインポートした証明書のチェーン(--certificate-chain)がCA証明書(ca.crt)になっているかも確認が必要だ。2. 接続はできるがEC2にpingが届かない
次の3点を順番に確認する。・認証ルール: 対象CIDRへのアクセス許可が登録されているか()
・ルート: VPNルートテーブルにVPC CIDRへのルートが追加されているか()
・セキュリティグループ: EC2のセキュリティグループがVPNクライアントCIDR(192.168.100.0/22)からのインバウンドを許可しているか
この3点のうち1つでも欠けていると通信は通らない。「つながらない」と感じた時は、認証ルール → ルート → SG の順に確認するとよい。
3. 接続に時間がかかる(タイムアウト)
エンドポイントの作成直後はステータスが「pending-associate」のため、「available」になるまで数分待つ必要がある。サブネットの関連付けにも数分かかる。 でステータスを確認してから接続を試みること。ポートの疎通確認にはLinuxのポート確認コマンド(ss・lsof)の記事も参考にしてほしい。
本記事のまとめ
| やりたいこと | コマンド・設定 |
|---|---|
| サーバー証明書の作成 | ./easyrsa build-server-full server nopass |
| ACMへのインポート | aws acm import-certificate --certificate fileb://pki/issued/server.crt |
| エンドポイントの作成 | aws ec2 create-client-vpn-endpoint --client-cidr-block 192.168.100.0/22 |
| サブネットへの関連付け | aws ec2 associate-client-vpn-target-network --subnet-id subnet-xxx |
| 認証ルールの追加 | aws ec2 authorize-client-vpn-ingress --target-network-cidr 10.0.0.0/16 |
| VPNルートの追加 | aws ec2 create-client-vpn-route --destination-cidr-block 10.0.0.0/16 |
| 接続状態の確認 | aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-xxx |
VPN設計と合わせて、VPC全体のセキュリティ設計や冗長化アーキテクチャも体系的に押さえておくことで、現場での対応力が一段上がる。
Client VPNの設定だけでなく、AWSを「実務の型」として身につけませんか?
aws ec2 create-client-vpn-endpoint のコマンドは調べれば分かります。でも「どのサブネットに何AZ関連付けるか」「スプリットトンネルとフルトンネルをどう使い分けるか」を、自信を持って答えられますか?
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます