「開発チームのメンバー全員にVPNアクセスを配布したいが、どこで設定すればいいのか分からない」
こうした課題を解決するのがAWS Client VPNだ。Site-to-Site VPNがオンプレミスのネットワーク全体をVPCに接続するのに対し、Client VPNはエンジニアのPCなど個々のデバイスからVPCへのリモートアクセスを実現する。
この記事では、Client VPNのエンドポイント設計・証明書の準備・ルーティング設定・動作確認まで実践的な手順を解説する。スプリットトンネルとフルトンネルの使い分け、マルチAZでの冗長設計ポイント、VPN接続後のDNS名前解決確認まで含めて解説するので、セキュアなリモートアクセス環境を設計する際の参考にしてほしい。動作確認は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互換)。
以下の表で2つの違いを整理しておこう。
| 項目 | Site-to-Site VPN | Client VPN |
|---|---|---|
| 接続単位 | 拠点(ネットワーク)単位 | デバイス(PC)単位 |
| プロトコル | IPsec | SSL/TLS(OpenVPN互換) |
| 主なユースケース | オフィス↔AWSのサーバー間通信 | リモートワーカーのVPC直接アクセス |
| クライアントソフト | 不要(ルーター設定のみ) | AWS VPN ClientまたはOpenVPN |
| 認証方式 | 事前共有鍵/証明書 | 証明書/AD/SAML2.0 |
・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
作成したサーバー証明書とCAのルート証明書をACMにインポートする。
# サーバー証明書を 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経由になる。
接続ログをCloudWatch Logsに記録するため、事前にロググループを作成しておく。
# CloudWatch Logs グループを事前に作成 aws logs create-log-group \ --log-group-name /aws/client-vpn \ --region ap-northeast-1
# 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=true,CloudwatchLogGroup=/aws/client-vpn,CloudwatchLogStream=connections \ --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
# Active Directory 認証の場合(ADグループ単位のアクセス制御) aws ec2 authorize-client-vpn-ingress \ --client-vpn-endpoint-id cvpn-endpoint-xxxxxxxxxxxxxxxxx \ --target-network-cidr 10.0.0.0/16 \ --access-group-id S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx \ --region ap-northeast-1
# 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 ~]$
3. VPC内の名前解決の確認
スプリットトンネルを使用している場合、VPN接続後にVPC内のプライベートDNS(例: ip-10-0-1-100.ap-northeast-1.compute.internal)が正しく解決されるかを確認しておくことを推奨する。VPCのDNS設定が有効になっていないと、EC2のプライベートDNS名でのアクセスが失敗する。# VPC の DNS 設定を確認(名前解決に必須の2項目) aws ec2 describe-vpc-attribute \ --vpc-id vpc-0123456789abcdef0 \ --attribute enableDnsHostnames \ --query "EnableDnsHostnames.Value" # → true であること aws ec2 describe-vpc-attribute \ --vpc-id vpc-0123456789abcdef0 \ --attribute enableDnsSupport \ --query "EnableDnsSupport.Value" # → true であること
aws ec2 modify-vpc-attribute \ --vpc-id vpc-0123456789abcdef0 \ --enable-dns-hostnames aws ec2 modify-vpc-attribute \ --vpc-id vpc-0123456789abcdef0 \ --enable-dns-support
マルチAZ冗長設計のポイント
Client VPNエンドポイントは、関連付けるサブネットのAZの数だけ冗長化される。2つのAZに関連付けておくと、一方のAZで障害が発生してもVPN接続が維持される。・2つ以上のAZのサブネットに関連付ける: ap-northeast-1aとap-northeast-1cのプライベートサブネットを指定する。1つのAZのみに関連付けた場合、そのAZで障害が発生するとVPN接続が全断する。本番環境では最低でも2AZ以上のサブネットを必ず指定すること。
・エンドポイントの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| +---------------+-----------+---------------+
# 現在の VPN 接続セッションを確認 aws ec2 describe-client-vpn-connections \ --client-vpn-endpoint-id cvpn-endpoint-xxxxxxxxxxxxxxxxx \ --query 'Connections[*].{User:Username,Status:Status.Code,IP:ClientIp}' \ --output table
トラブルシューティング
Client VPNのセットアップで詰まりやすいポイントをまとめた。1. 「TLS Error: TLS handshake failed」が出る
証明書の不一致またはCA証明書の指定ミスが原因であることが多い。サーバー証明書とクライアント証明書が同じCAで署名されているかを確認する。ACMにインポートした証明書のチェーン(`--certificate-chain`)がCA証明書(ca.crt)になっているかも確認が必要だ。証明書の有効期限が切れていないかも `aws acm describe-certificate` で確認しておこう。
# 証明書の有効期限とステータスを確認 aws acm describe-certificate \ --certificate-arn arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxx \ --query "Certificate.{Status:Status,NotAfter:NotAfter}" \ --output table
2. 接続はできるがEC2にpingが届かない
次の3点を順番に確認する。・認証ルール: 対象CIDRへのアクセス許可が登録されているか(`aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxx`)
・ルート: VPNルートテーブルにVPC CIDRへのルートが追加されているか(`aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxx`)
・セキュリティグループ: EC2のセキュリティグループがVPNクライアントCIDR(192.168.100.0/22)からのインバウンドを許可しているか
この3点のうち1つでも欠けていると通信は通らない。「つながらない」と感じた時は、認証ルール → ルート → SG の順に確認するとよい。
3. 接続後にVPC内の名前解決ができない
スプリットトンネルを使用している場合、VPN接続後もVPC内のDNSサーバー(VPC CIDR+2のアドレス、例:10.0.0.2)に到達できているか確認する。VPCのDNS設定(`enableDnsHostnames` と `enableDnsSupport`)が両方 `true` になっているかを確認する(前述「VPC内の名前解決の確認」を参照)。どちらか一方でも `false` の場合、EC2インスタンスのプライベートDNS名が解決できなくなる。
4. 接続に時間がかかる(タイムアウト)
エンドポイントの作成直後はステータスが「pending-associate」のため、「available」になるまで数分待つ必要がある。サブネットの関連付けにも数分かかる。`aws ec2 describe-client-vpn-endpoints` でステータスを確認してから接続を試みること。ポートの疎通確認には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 |
| 証明書の有効期限確認 | aws acm describe-certificate --certificate-arn arn:aws:acm:...:certificate/xxx |
| VPN接続セッションの確認 | aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id 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秒、解除もいつでも可。
登録無料・いつでも解除できます