はじめに：カフェのWi-Fiで「パケット」を覗き見られた夜
夜な夜なおしゃれなカフェでMacを開き、APIのレスポンスを睨みながらコードを叩く——エンジニアなら誰もが一度は経験する光景だろう。だが、その背後で何が起きているか意識したことはあるだろうか？暗号化されていない公共Wi-Fiの電波は、空中をむき出しの状態で飛び交っている。そこに悪意あるプレイヤーがWi-Fiスニッファーを仕掛けていれば、あなたが叩いているAPIのリクエストパラメータや、セッションCookieは丸見えだ。
ここで「個人向けVPN」を有効にした瞬間、あなたのPCとVPNサーバーの間には強固な暗号化トンネルが構築される。怪しい無線APから見れば、通信相手はVPNサーバーのエンドポイントIPアドレスだけになり、中身は完全にブラックボックス化する。
だが、ここで少し立ち止まってインフラエンジニアとしての好奇心を働かせてほしい。
「私のOS（LinuxやmacOS）の上で、ユーザー空間で動くVPNアプリと、カーネル空間のネットワークスタックは、一体どうやってパケットのキャッチボールをしているのか？」
今回は、このマジックの正体である仮想ネットワークインターフェース（TUN/TAPデバイス）のOSレベルでの挙動を、パケットの生々しい動きと共に解き明かしていく。API設計やインフラ運用に携わるあなたなら、この「パケットの旅路」を知ることで、ネットワークトラブル時の嗅覚が一段と鋭くなるはずだ。
—
1. カーネル空間とユーザー空間の架け橋：TUNとTAPの正体
VPNクライアントソフト（WireGuard、OpenVPN、あるいは各種プロプライエタリなツール）は、基本的にOSの「ユーザー空間」で動作するユーザープロセスにすぎない。しかし、OSのルーティングテーブルを書き換え、あらゆるネットワークパケットをインターセプトして暗号化・カプセル化するためには、カーネルのネットワークスタックと深く連携する必要がある。
ここで登場するのが、OSカーネルが提供する仮想的なネットワークデバイス、TUNとTAPだ。
TUN（L3トンネリング）
- 動作レイヤー: OSI参照モデルの第3層（ネットワーク層）。
- 扱うデータ: Ethernetヘッダーを含まない、生の下りIPパケット（IPv4/IPv6）。
- 用途: IPベースのVPN（OpenVPNのTUNモード、WireGuardなど）。ルーティングの制御がシンプルで、インターネット上の大部分のVPNで採用されている。
TAP（L2トンネリング）
- 動作レイヤー: OSI参照モデルの第2層（データリンク層）。
- 扱うデータ: MACアドレスやEthernetヘッダーを含むイーサネットフレーム。
- 用途: 拠点間接続（L2ブリッジ）や、仮想マシン（KVM/QEMU）のブリッジ接続など、同一セグメントにいるかのように振る舞わせたい場合。
実務のWebインフラやクラウド環境（AWSのVPN接続など）では、圧倒的にレイヤー3のTUNデバイスを扱う機会が多い。今回は、このTUNデバイスがカーネルとユーザー空間の間でどうパケットをバトンタッチしているのか、その実体を深掘りする。
—
2. TUNデバイスの内部動作とパケットのライフサイクル
TUNデバイスは、Linuxカーネル内では /dev/net/tun というキャラクタデバイス（擬似的なファイル）として存在する。VPNクライアントはこのファイルディスクリプタに対して read() や write() を行うことで、仮想インターフェースに出入りするパケットを読み書きする。
[ ユーザーアプリ (curl等) ]
│
▼ (ソケット通信)
[ OSカーネル空間: ネットワークスタック ]
│
▼ (ルーティング判定: 宛先がVPNならTUNへ)
[ 仮想デバイス: tun0 (TUNデバイス) ]
│
├─ ( read() で取得 ) ──► [ VPNクライアント (ユーザー空間) ]
│ │ (暗号化 / UDPカプセル化)
│ ▼
│ [ 物理NIC (eth0/wlan0) ]
│ │
│ ▼ (インターネット経由)
│ [ VPNゲートウェイ ]
│
└─ ( write() で書込 ) ◄── [ 暗号化パケットの復号 ]パケットが流れる実際のシーケンス
1. アプリの送出: あなたが書いたPythonスクリプトやcurlコマンドが、APIサーバー（例: https://api.example.com/v1/data）へリクエストを飛ばす。
2. カーネルのルーティング: OSのカーネルはルーティングテーブルを参照し、デフォルトゲートウェイとして設定されたTUNインターフェース（例: tun0）へパケットを流し込む。
3. ユーザー空間への引き渡し: VPNクライアントプロセスは、select()やepoll()を使って /dev/net/tun を監視しており、データが来ると read() システムコールで生のIPパケットをごっそり吸い上げる。
4. カプセル化と暗号化: VPNクライアントは、そのIPパケットをまるごとペイロードとして暗号化し、新たにUDPヘッダー（WireGuardの場合）などを付与して外側のパケットを作る。
5. 物理NICからの送出: 暗号化されたパケットは、通常の物理インターフェース（eth0やwlan0）を経由して実世界のルーターへと羽ばたいていく。
受信時はこの逆のルートを辿る。VPNサーバーから届いた暗号化パケットを物理NICが受け取り、VPNクライアントが復号し、write() システムコールで tun0 に書き戻すことで、カーネルは「外から正規のIPパケットが届いた」と勘違いして処理を続けるのだ。
—
3. 実践：Linux環境でのTUNデバイスの手動構築とパケットキャプチャ
百聞は一見に如かず。実際にLinux（UbuntuやDebian系を想定）のコマンドを叩いて、純粋なTUNデバイスを手動で生やし、OSがどう反応するかを確かめてみよう。VPNソフトを使わずとも、OSの標準機能だけでTUNの挙動は再現できる。
ステップ1: TUNデバイスの作成とIPアドレスの付与
以下のコマンドをroot権限（または sudo）で実行する。ここでは tun0 という名前の仮想インターフェースを掘る。
# 1. iproute2を使用して tun0 という名前のTUNデバイスを作成
sudo ip tuntap add dev tun0 mode tun
# 2. 作成したTUNデバイスにIPアドレスを割り当てる（VPNのクライアント側IPを想定）
sudo ip addr add 10.8.0.2/24 dev tun0
# 3. インターフェースをUP状態にする
sudo ip link set dev tun0 upこの状態で ip a を叩くと、見事に tun0 が現れ、指定した 10.8.0.2 がバインドされていることが確認できる。
ステップ2: ルーティングテーブルの確認とパケットの行方
次に、ルーティングテーブルを見てみよう。
ip route showもしデフォルトルートをこの tun0 に向けたい場合は以下のように設定する（※実環境で安易にやるとネットから遮断されるので注意）。
# すべてのトラフィックを tun0 経由にする（テスト時は注意）
sudo ip route add default dev tun0ここで、バックグラウンドで簡単なPythonスクリプトを動かし、/dev/net/tun から生パケットをリード（読み取り）してみよう。
import os
import fcntl
import struct
# TUNデバイスを操作するためのioctl定数
TUNSETIFF = 0x400454ca
IFF_TUN = 0x0001
IFF_NO_PI = 0x1000
def create_tun(dev_name="tun0"):
# /dev/net/tun キャラクターデバイスを開く
tun_fd = os.open("/dev/net/tun", os.O_RDWR)
# ioctlを使ってインターフェース名とフラグを設定
#ifr = [名前(16バイト)] + [フラグ(2バイト)]
ifr = struct.pack("16sH", dev_name.encode('utf-8'), IFF_TUN | IFF_NO_PI)
fcntl.ioctl(tun_fd, TUNSETIFF, ifr)
print(f"[*] 仮想インターフェース {dev_name} をオープンしました (FD: {tun_fd})")
return tun_fd
if __name__ == "__main__":
# 事前に `ip tuntap add dev tun0 mode tun` 等を行っておくこと
try:
fd = create_tun("tun0")
print("[*] パケットの待ち受けを開始します... (Ctrl+Cで終了)")
while True:
# カーネルから送られてくる生IPパケットを読み込む（最大2048バイト）
packet = os.read(fd, 2048)
print(f"[+] キャプチャしたパケットのサイズ: {len(packet)} バイト")
# 本来のVPNクライアントなら、ここでパケットを暗号化してソケットへ流す
except KeyboardInterrupt:
print("\n[*] 終了します。")
os.close(fd)このスクリプトを実行した状態で、別のターミナルから ping 10.8.0.1 などを実行してみると、Pythonスクリプト側でカーネルから流れてきた生IPパケットのバイナリをリアルタイムにキャッチできることが確認できるはずだ。これが、VPNアプリの心臓部である。
—
4. インフラ・開発現場でのトラブルシューティングTips
実務において、VPN接続が絡むインフラの構築や、社内API・セキュアなマイクロサービス間通信のデバッグでは、このTUN/TAPやルーティングの仕組みを知っているかどうかで復旧スピードが桁違いに変わる。
1. MTU（Maximum Transmission Unit）の断片化問題に泣かされたら
VPNを挟むと、通常のイーサネットフレーム（通常MTU 1500バイト）にVPNヘッダー（UDPヘッダー、暗号化オーバーヘッド等）が追加されるため、物理NICのMTUを超えてしまうことがある。
- 現象: 「特定の大きなJSONレスポンスを返すAPIだけタイムアウトする」「
curlだと途中からレスポンスがピタッと止まる（Path MTU Discoveryのブラックホール問題）」 - 対策: VPNクライアント側やインターフェースのMTUを適切に下げる（例:
MTU 1380や1400に設定する）。
# 手動で tun0 のMTUを調整する場合
sudo ip link set dev tun0 mtu 13802. ルーティングの優先度（スプリットトンネリング vs フルートンネリング）
すべてのトラフィックをVPN経由にする「フルートンネリング」か、社内ドメインや特定プライベートIPのみをVPNに流す「スプリットトンネリング」かによって、OSのルーティングテーブルの設計が変わる。
- APIクライアントから社内APIへリクエストが飛ばないときは、
ip route get <APIサーバーのIP>を実行し、意図したtun0インターフェースを経由しているかを必ず確認すること。
—
おわりに：パケットの旅路を見極める眼を持て
今回は、個人向けVPNや企業向けセキュアアクセスを支える裏方、仮想ネットワークインターフェース（TUN/TAP）のOSレベルの動作について解説した。
普段私たちが何気なく叩いている curl や requests.get()、あるいはブラウザからのHTTPSリクエストは、OSのカーネルとユーザー空間の境界線で、こうした仮想デバイスを巧みに経由しながら暗号化され、世界中を駆け巡っている。
「なぜこのAPIリクエストがタイムアウトするのか」「なぜこのパケットはVPNに乗らないのか」。そう壁にぶぶつかった時、この記事で紹介したパケットのライフサイクルやカーネルとユーザー空間のやり取りを思い出してほしい。泥臭いパケットの足跡を追う眼力こそが、シニアなインフラエンジニア、そして信頼されるWebエンジニアの最大の武器となるのだから。
コメント