こんにちは！ネットワークの迷宮をパケットと共に歩む、技術メディア主筆のスペシャリストです。
リモートワークが当たり前になった昨今、「外から社内ネットワークに安全につなぐ」ための技術、SSL-VPNはもはやインフラエンジニアにとって避けては通れない必須科目になりました。
「VPNボタンをポチッと押せば繋がる」――ユーザーから見れば魔法のような仕組みですが、その裏側では、TLS（Transport Layer Security）というプロトコルが、非常に緻密で情熱的な「交渉」と「守護」を行っています。
今日は、SSL-VPNの心臓部である「TLSハンドシェイクプロトコル」と「TLSレコードプロトコル」について、難しい専門用語の壁をひょいと飛び越えて、郵便配達の流れに例えながら優しく紐解いていきましょう。
—
1. SSL-VPNの正体は「鉄壁の封筒」と「厳重な受付」
SSL-VPNを支えるTLSプロトコルは、大きく分けて2つの役割に分かれています。
1. TLSハンドシェイクプロトコル：これから通信を始める相手が本当に信頼できるか確認し、秘密の暗号ルールを決める「受付での挨拶と契約」の役割。
2. TLSレコードプロトコル：決まったルールに基づいて、実際のデータをバラバラに砕き、頑丈な封筒に入れて送り届ける「実際の配達」の役割。
この2つがタッグを組むことで、インターネットという「誰が盗み聞きしているかわからない公道」を、安全にパケットが駆け抜けることができるのです。
—
2. ハンドシェイクプロトコル：信頼を結ぶ「4つのステップ」
まずは「受付での契約」であるハンドシェイクを見ていきましょう。これは、あなた（クライアント）と会社にあるVPNゲートウェイ（サーバー）が、通信を始める前に行う儀式です。
① 「こんにちは！」と「使える言葉」の提示 (Client Hello)
まず、あなたのパソコンが「SSL-VPNを使いたいのですが、私はこの暗号の種類（暗号スイート）が使えます！」と、挨拶状を送ります。
② 「私はこれにします！」と「身分証明書」の提示 (Server Hello & Certificate)
VPNゲートウェイは、「じゃあ、この暗号方式でいきましょう。ちなみに私は本物の会社のサーバーですよ」と、サーバー証明書を提示します。これが郵便でいう「役所が発行した身分証」にあたります。
③ 「鍵」をこっそり共有する
お互いが納得したら、その場限りの「データの箱を開けるための共通の鍵」を作ります。このとき、第三者には絶対にバレないような数学的な魔法（公開鍵暗号）を使って、こっそり鍵の素を交換します。
④ 「準備完了！」の合図 (Finished)
最後に「これからは決めたルールで暗号化しますよ！」とお互いに確認して、ハンドシェイクは終了です。
—
3. レコードプロトコル：データを守る「運び屋」
ハンドシェイクで「鍵」と「ルール」が決まったら、いよいよデータの出番です。ここを担当するのがレコードプロトコルです。
レコードプロトコルは、あなたが送りたいデータ（メールやファイルの断片）を以下のように処理します。
1. 断片化（Fragmentation）: データを運びやすいサイズに小さく切り分けます。
2. 圧縮（Compression）: 必要に応じてサイズを縮めます（現在はセキュリティ上の理由で無効化されることが多いです）。
3. 認証と暗号化（MAC & Encryption）: データが途中で書き換えられていないかチェックする印（MAC）をつけ、ハンドシェイクで決めた鍵を使って、中身が絶対に見えないように「暗号の封筒」に閉じ込めます。
こうして作られた「TLSレコード」が、TCPパケットに乗ってインターネットへと放たれるのです。
—
4. 実務で役立つ設定の勘所
さて、ここからは少しだけ「現場のエンジニア」の視点に立ってみましょう。SSL-VPNを構築する際、私たちが最も頭を悩ませるのが「暗号スイート（Cipher Suite）」の選定です。
あまりに古い暗号を許可するとセキュリティに穴が開きますし、新しすぎると古い端末が繋がらなくなります。
以下に、一般的によく使われる「セキュアかつ標準的な設定例」を、Webサーバー（Nginx）をリバースプロキシとしてSSL-VPNの入り口にする場合を想定して記述します。
# SSL-VPNゲートウェイとしてのNginx設定例
server {
listen 443 ssl;
server_name vpn.example.com;
# 【重要】使用するTLSプロトコルのバージョンを指定
# TLS 1.0/1.1は脆弱性があるため、現代では 1.2 以上が必須です！
ssl_protocols TLSv1.2 TLSv1.3;
# 【重要】暗号スイートの選定
# 安全性が高く、かつ処理速度も速いものを優先的に並べます
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
# サーバー側で決めた暗号順序を優先させる設定
ssl_prefer_server_ciphers on;
# 【証明書の設定】
# ハンドシェイクで提示する「身分証明書」と「秘密鍵」のパス
ssl_certificate /etc/letsencrypt/live/vpn.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vpn.example.com/privkey.pem;
# セッション再開の設定（接続をスムーズにするための工夫）
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
location / {
# ここで社内アプリやVPNバックエンドへ転送
proxy_pass http://internal_app_server;
}
}パラメーターのポイント
ssl_protocols:TLSv1.2とTLSv1.3だけを許可するのが現在の鉄則です。ssl_ciphers: ここに並んでいる英単語の羅列は、「鍵交換はECDHEで、暗号化はAESのGCMモードで…」という「会話のルール」のセットリストです。
—
5. 現場でよくあるトラブル：なぜ繋がらない？
SSL-VPNの構築中、あるいは運用中に「繋がらない！」という悲鳴が聞こえてきたら、以下の2点をまず疑ってみてください。
A. 証明書の有効期限切れ（身分証の失効）
ハンドシェイクプロトコルにおいて、サーバーが提示した証明書の期限が切れていると、クライアント（PC）は「この相手は怪しい！」と判断して通信を拒否します。
ブラウザで https://... にアクセスしたときに「保護されていない通信」と出るアレです。
B. 暗号スイートの不一致（言葉が通じない）
古いOSのPCや古いスマホを使っている場合、サーバー側で「最新の強い暗号しか使わせない！」と厳しく設定しすぎると、お互いに使える暗号が見つからず、ハンドシェイクが失敗します。
Handshake Failure というエラーが出たときは、この「言葉のミスマッチ」を疑いましょう。
—
まとめ：パケットに愛着を持とう
SSL-VPNの世界は、一見すると複雑な数式や英語の羅列に見えるかもしれません。しかしその実態は、「まずは安全に挨拶をして（ハンドシェイク）」、「壊れないように丁寧に梱包して運ぶ（レコードプロトコル）」という、私たちの日常にある郵便や宅配便と何ら変わりない、とても人間味のある仕組みなのです。
もし設定に迷ったら、パケットが「今、受付で困っていないかな？」「封筒が破けていないかな？」と想像してみてください。その視点こそが、トラブルに強い一流のエンジニアへの第一歩です。
一歩ずつ、楽しみながら理解を深めていきましょう。あなたの構築するネットワークが、安全で快適なものになることを応援しています！
コメント