トンネリングの魔術：パケットを二重に包み込む「個人向けVPN」のカプセル化エンジニアリング
やあ、よく来てくれた。
普段、Web APIの設計やクラウドのインフラ構築でバリバリとコードを書いている君なら、「VPN」という言葉を聞いて何を思い浮かべるだろうか？
「ああ、会社のイントラネットに接続するためのレガシーな仕組みでしょ？」
「リモートワークのときに、なんか遅くなるやつ」
もしそう思っているなら、今日の話を少し聞いてほしい。
実は、我々が普段何気なく使っている「個人向けVPN」の裏側では、現代のネットワークエンジニアリングの粋を集めた「パケットの変態的なラッピング技術」が使われている。
カフェのフリーWi-Fiで、隣の席の怪しい奴が君の通信をスニッフィングしようと待ち構えていたとする。彼に見えるのは、暗号化された意味不明なガーベッジデータだけだ。なぜそれが可能なのか？ 端末から送り出された素裸のIPパケットが、どのように「カプセル化（Tunnelling）」され、VPNサーバーという要塞まで安全に運ばれていくのか。
今回は、RFCの仕様から通信のシーケンス、そしてインフラエンジニアなら知っておくべきカプセル化の実務的な裏側まで、徹底的に解剖していこう。
—
1. なぜ「カプセル化」が必要なのか？ 〜境界防御の崩壊と仮想専用線〜
現代のWeb開発において、HTTPSによる暗号化はもはや常識だ。しかし、HTTPSが保護するのは「ブラウザとWebサーバー間（エンド・ツー・エンド）」のペイロード（中身）だけであり、パケットのヘッダー情報（宛先IPアドレスや送信元IPアドレス）は丸見えである。
ここにどんなリスクがあるか、想像できるかね？
通信先のIPアドレスが分かれば、君がどの企業のエンドポイントにアクセスしているか、あるいはどのパブリッククラウドのAPIを叩いているかが、途中のルーターやISP、あるいは同一セグメントの悪意ある第三者に筒抜けになる。
ここで登場するのが、個人向けVPNの基本アーキテクチャだ。
ユーザーのデバイスとVPNサーバーの間に「仮想的な専用線（トンネル）」を構築し、外部のネットワークからは中身が一切見えないカプセルで包み込んでしまう。この「包み込む」という物理的（概念的）なプロセスこそがカプセル化（Encapsulation）なのだ。
—
2. カプセル化の正体：IPパケットを別のIPパケットで「包む」
カプセル化の概念は非常にシンプルだが、ネットワーク層の挙動を理解していないとハマるポイントが多い。
基本原則として、カプセル化とは「あるプロトコルデータユニット（PDU）を、別のプロトコルデータユニットのデータム（ペイロード）として格納すること」を指す。
具体的に見てみよう。君のPCから宛先 8.8.8.8 に向けてHTTPリクエストを送る際、生成される元のパケット（Inner Packet）の構造はこうだ。
+-----------------------+---------------------------------------+
| Inner IP Header | Payload (TCP Segment + HTTP Request) |
| Src: 192.168.1.100 | (GET /index.html HTTP/1.1 ...) |
| Dst: 8.8.8.8 | |
+-----------------------+---------------------------------------+これをVPNクライアントソフト（WireGuardやOpenVPNなど）がキャッチすると、OSの仮想ネットワークインターフェース（tun0 など）を経由して、このパケット丸ごと別のパケットのペイロードとして包み込む。これが外側のパケット（Outer Packet）だ。
+-----------------------+-----------------------+-----------------------------------+
| Outer IP Header | UDP Header / ESP etc. | Inner IP Header + Payload |
| Src: 192.168.1.100 | (Encapsulation Meta) | Src: 192.168.1.100 |
| Dst: 203.0.113.50 | | Dst: 8.8.8.8 (Original Payload) |
+-----------------------+-----------------------+-----------------------------------+お気づきだろうか？
外側のIPヘッダーの宛先（Dst）は、元の宛先である 8.8.8.8 ではなく、VPNプロバイダが用意した終端サーバーのIPアドレス（例: 203.0.113.50）に書き換えられている。
これにより、途中のルーターは「おっ、このパケットは 203.0.113.50（VPNサーバー）宛てだな」としか思わず、中身の本当の宛先やデータは絶対に知ることができない。これがトンネリングのカラクリだ。
—
3. シーケンスで追う！VPNトンネル確立とデータ転送の全貌
では、実際にこのカプセル化されたパケットがネットワーク上をどのように流れているのか、ハンドシェイクからデータ転送までのシーケンスを追ってみよう。今回は、現代のモダンなVPNプロトコルとして主流になりつつある WireGuard（UDPベース） を念頭に置いて解説する。
[Client (PC)] [VPN Server]
| |
| --- 1. ハンドシェイク開始 (UDP / 51820) ----> |
| <--- 2. 鍵交換・認証応答 ------------------- |
| |
| (ここからトンネル確立・暗号化開始) |
| |
| --- 3. カプセル化パケット送信 (Outer UDP) -> |
| (中身: 宛先 8.8.8.8 の Inner IP) |
| |
| [パケットを剥離 / Decapsulation]
| [通常のIPルーティングでインターネットへ]
| |
| <--- 4. レスポンスパケット (Outer UDP) ----- |
| (VPNサーバーが代わりに受けてカプセル化) |
| |
| [パケットを剥離 / Decapsulation] |通信フローのポイント
1. ハンドシェイク: 初回接続時に暗号鍵の交換（Noise Protocol Frameworkなどを使用）を行い、セッションを確立する。
2. カプセル化と送信: アプリケーション層からのパケットを tun デバイスが受け取り、UDPパケットでラップしてVPNサーバーへ飛ばす。
3. サーバー側の処理（脱カプセル化 / Decapsulation）: VPNサーバーは届いたUDPパケットを剥ぎ取り（外側ヘータを破棄）、元のInner IPパケットを取り出して通常のインターネット空間へと送り出す。
4. 復路のルーティング: 外部サーバーからの応答は一度VPNサーバーに戻る。VPNサーバーは再びそれをカプセル化し、クライアントのデバイスへと折り返す。
—
4. 実務で知るべきパラメーターと「MTU問題（断片化の罠）」の回避
インフラエンジニアやバックエンドエンジニアとして、VPNやオーバーレイネットワークを扱う際、必ず直面するのがMTU（Maximum Transmission Unit）のオーバーヘッド問題だ。
インターネットの標準的なイーサネットのMTUは通常 1500バイト である。
しかし、IPパケットを別のパケットで包み込む（カプセル化する）ということは、外側の子細なヘッダー分だけ、一度に送れるペイロードのサイズ（MSS: Maximum Segment Size）が小さくなることを意味する。
例えば、IPsec（ESP）やOpenVPN（TCP/UDP + TLS）を使うと、暗号化アルゴリズムや認証タグ、カプセル化のヘッダーによって、数十バイトから百バイト近くが削られる。
[ 標準イーサネット MTU: 1500 Bytes ]
|<- IP Header(20) + TCP Header(20) + Data(1460) ->|
[ VPNカプセル化後 (例) ]
|<- 外側IP(20) + UDP(8) + WireGuard Header(32) + 内側IP(20) + TCP(20) + Data(1400) ->|もし、元のパケットが 1500バイト ギリギリのサイズで送られてきた場合、VPNのヘッダーが追加されることで合計サイズが 1500バイト を超過してしまう。
結果として、ルーターでIPフラグメンテーション（断片化）が発生し、パケットロスやスループットの著しい低下を招く。最悪の場合、一部のセキュリティアプライアンスが断片化パケットをドロップし、特定のWebサイトやAPIだけが無限ローディングになるという「原因特定が最高にめんどくさい障害」を引き起こす。
対策：MSS ClampingとPath MTU Discovery (PMTUD)
インフラ設定を行う際は、VPNインターフェース（またはルーター）側で以下のような対策を講じるのが定石だ。
- MSS Clampingの設定: TCPの初期SYNパケットの段階で、最大セグメントサイズを強制的に小さく（例:
1360や1400などに）書き換える。 - Path MTU Discovery (PMTUD) の有効化: ICMP（Type 3/Code 4: Fragmentation Needed）を適切にスルーさせ、通信経路全体の最適なMTUを動的に決定させる。
—
5. 実装例：Pythonによる「カプセル化・パケット処理」の概念コード
「理屈は分かったが、実際にパケットを包み込む処理はどう書くのか？」
ネットワークプログラミングの基礎として、Pythonの socket ライブラリを用いて、UDPパケットとしてデータを包んで送信する簡易的なカプセル化・送受信のモックコードを記述しよう。実務ではOSの tun/tap デバイスドライバとやり取りする部分だが、概念を掴むには十分だ。
import socket
# 設定情報
VPN_SERVER_IP = "203.0.113.50" # 外側の宛先（VPNサーバーのグローバルIP）
VPN_SERVER_PORT = 51820 # VPNのリスニングポート（例: WireGuard標準）
def encapsulate_and_send(inner_payload: bytes):
"""
【カプセル化のシミュレーション】
内側のペイロード（Inner Packet）をUDPのペイロードとして包み込み、
外側の宛先（VPNサーバー）へ送信する関数。
"""
# 1. ソケットの作成 (IPv4 / UDP)
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
# 2. カプセル化の実行（概念的処理）
# 実際のVPNでは、ここに暗号化レイヤーとカプセル化ヘッダーが付与される
outer_packet = inner_payload
print(f"[DEBUG] 元データサイズ: {len(inner_payload)} bytes")
print(f"[DEBUG] 外側パケットを構築し、宛先 {VPN_SERVER_IP}:{VPN_SERVER_PORT} へ送信します...")
# 3. 外側のパケットをネットワークへ送出
sock.sendto(outer_packet, (VPN_SERVER_IP, VPN_SERVER_PORT))
# 4. レスポンスの受信（脱カプセル化の前提）
data, addr = sock.recvfrom(2048)
print(f"[DEBUG] {addr} からカプセル化されたレスポンスを受信しました（サイズ: {len(data)} bytes）")
return data
except socket.error as e:
print(f"[ERROR] ネットワークソケットエラーが発生しました: {e}")
finally:
sock.close()
if __name__ == "__main__":
# テスト用の仮想的なHTTPリクエスト（Inner Packetに相当）
dummy_inner_packet = b"GET /api/v1/resource HTTP/1.1\r\nHost: api.example.com\r\n\r\n"
# 実行
response = encapsulate_and_send(dummy_inner_packet)このコードでは単純なソケット通信に見えるが、本番の個人向けVPNクライアントは、この裏側でOSの仮想NICを制御し、カーネル空間とユーザー空間を行き来しながら高速にパケットを暗号化・カプセル化している。
—
6. おわりに：エンジニアが個人向けVPNの仕組みを学ぶべき理由
「ただのセキュリティツール」として片付けられがちな個人向けVPNだが、その実態は、OSのネットワークスタック、IPルーティング、暗号理論、そしてパケットの魔術である「カプセル化」が凝縮された素晴らしい技術の塊だ。
Web APIの設計やマイクロサービスの通信基盤（Service MeshやSD-WAN、ゼロトラストネットワークアクセス：ZTNA）を構築する際、パケットがどこを通り、どのように包まれているかを想像できるか否かで、インフラ障害に直面したときのトラブルシューティングのスピードは桁違いに変わる。
「なぜこのトラフィックだけレイテンシが高いのか？」
「なぜMTUが原因でPOSTリクエストだけがタイムアウトするのか？」
その答えの多くは、今日話した「パケットが二重に包まれる世界」のどこかに隠されている。
さあ、次のデバッグでは、tcpdump や Wireshark を開いて、パケットの「皮」を一枚一枚めくってみようじゃないか。
コメント