パケットの重みを感じろ：VPNベンチマークとスループット限界突破のアーキテクチャ
ネットワークエンジニアなら誰もが一度は経験するだろう。社内インフラやクラウド環境へのリモートアクセス、あるいはプライバシー保護のために張ったVPN。接続した瞬間に体感できる「あの絶妙なモッサリ感」、そしてブラウザの描画がコンマ数秒遅れるフラストレーション。
「暗号化しているのだから遅くなって当然」――そんな思考停止の言い訳を、我々インフラアーキテクトやテックリードが許すわけにはいかない。
個人向けVPNであれ、エンタープライズの拠点間接続であれ、VPNの本質は「信頼性の低い物理ネットワーク上に、論理的な高セキュリティ空間を強制構築する」ことにある。しかし、パケットをカプセル化し、暗号化し、海を越えた遠隔のVPNサーバーへと流し込むプロセスは、物理法則とプロトコルスタックのオーバーヘッドという容赦ない現実を我々に突きつける。
今回は、VPNのスループット低下を引き起こす真のボトルネックをパケットレベルで暴き、Linuxカーネルのチューニングから暗号化アルゴリズムの選定、そしてRTT（往復遅延時間）の極限圧縮に至るまで、実戦で使える最適化の全手法を解説しよう。
—
1. VPNベンチマークの前提：パケットはどこで削られているのか？
ベンチマークを始める前に、我々が測定しようとしている「遅延」と「スループット低下」の発生源を正確に把握する必要がある。パケットキャプチャを覗けば、そこには明確な犯人が映し出されている。
物理的距離と光速の壁
東京から西海岸のVPNサーバーを経由する場合、光ファイバー中継網を進む光の速度と、経由するルーターのホップ数によって、物理的なRTTの下限が決まる。こればかりは如何ともしがたいが、BGPルートの最適化や近傍エッジサーバーの選択で最小化することは可能だ。
カプセル化によるMTUの肥大化とフラグメンテーション
例えば、標準的なEthernetのMTU（Maximum Transmission Unit）は 1500 バイトだ。ここにWireGuardやOpenVPN（UDP/TCP）のカプセル化ヘッダーが付与されると、外側のパケットサイズが 1500 バイトを超過する。
結果として、ルーターやカーネルでIPフラグメンテーションが発生し、パケットロス時の再送効率が劇的に悪化する。この「Path MTU Discovery (PMTUD)」の失敗やブラックホール問題は、スループット急落の主原因の一つだ。
暗号化処理のCPUオーバーヘッド
AES-250-GCMやChaCha20-Poly1305といった暗号アルゴリズムは、現代のCPUではAES-NIなどのハードウェアアクセラレーションにより高速化されているが、それでもコンテキストスイッチとメモリコピーのコストは無視できない。
—
2. 正確なベンチマーク測定手法：iperf3とWiresharkによる実測
感覚的な「遅滞感」を排し、定量的なボトルネックを特定するためには、iperf3 を用いたスループット・Jitter・パケットロスの測定が不可欠だ。
サーバー側とクライアント側の基本測定
まずは、VPNトンネルを張った状態、そして張っていない状態（ネイティブ）の双方でベースラインを測定する。
# 【サーバー側（VPN終端または対向ホスト）で実行】
# デフォルトポート52840でiperf3サーバーを常駐させる
iperf3 -s
# 【クライアント側で実行】
# 30秒間、TCPスループットを測定する（-P 4 でパラレルストリームを有効化）
iperf3 -c <VPN_SERVER_IP> -t 30 -P 4パケットロスとUDPスループットの測定
リアルタイム性の高い通信（音声・動画・ゲーム等）ではUDP性能が重要になる。以下のコマンドで帯域を制限しつつ、パケットロス率を観測する。
# 50Mbpsの帯域を指定してUDPパケットを流す
iperf3 -c <VPN_SERVER_IP> -u -b 50M -t 15ここで取得した結果と、Wireshark または tcpdump でキャプチャした TCP Window Size や Retransmissions の数値を照らし合わせることで、どこでパケットが詰まっているかが一目瞭然となる。
—
3. カーネルパラメータのチューニング：TCPバッファとBBRの導入
デフォルトのLinuxカーネル（UbuntuやDebianなど）は、一般的なオフィス環境やWebブラウジングを想定した保守的な設定になっている。大容量・高遅延のVPN環境で限界のスループットを引き出すには、/etc/sysctl.conf を直接叩き直す必要がある。
sysctlによるネットワークバッファの極限拡張
以下の設定を /etc/sysctl.d/99-vpn-optimization.conf として配置し、sudo sysctl --system で反映させよう。
# --- 送受信バッファの最大値を拡大（高BDP環境対策） ---
# 最大ソケット受信バッファ
net.core.rmem_max = 67108864
# 最大ソケット送信バッファ
net.core.wmem_max = 67108864
# デフォルトの送受信バッファサイズ（最小、初期、最大値のバイト指定）
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
# --- キューイング規 disciplina と輻輳制御アルゴリズム ---
# ネットワークカードのバックログキューを拡大
net.core.netdev_max_backlog = 10000
# Googleが開発したBBR輻輳制御アルゴリズムを有効化（RTTとロス耐性を劇的に改善）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrなぜBBRなのか？
従来のCUBICなどの損失ベースの輻輳制御は、パケットロスを「回線の混雑」と誤認し、ウィンドウサイズを急激に縮小させてしまう。特にVPN特有の暗号化遅延や微小なロスが混じる環境ではこれが致命傷になる。BBRは「帯域幅」と「伝搬遅延」を動的にモデル化し、ボトルネックリンクのパイプを常に最大効率で満たし続ける。これだけでスループットが数倍に跳ね上がるケースは珍しくない。
—
4. プロトコル選定とMTU/MSSクランプの最適化
VPNプロトコル（OpenVPN、WireGuard、IPsec/IKEv2）の選択は、パフォーマンスの天井を決定づける。
WireGuardの圧倒的な優位性と設定の勘所
現代のインフラにおいて、余計なオーバーヘッドを削ぎ落としたWireGuardは事実上の標準だ。ステートレスで高速、UDPベースであるためTCPイン・TCPアウトの二重ラップ（TCP over TCP問題）を防ぐことができる。
しかし、MTUの調整を怠ると、プロバイダのPPPoE環境やルーターの制限に引っかかり、パケットの断片化が発生する。クライアント側の設定ファイル（wg0.conf）では、明示的に MTU を指定すること。
[Interface]
PrivateKey = <クライアントのプライベートキー>
Address = 10.0.0.2/32
# PPPoEやトンネルのオーバーヘッドを考慮し、標準より小さめのMTUを設定
MTU = 1360
[Peer]
PublicKey = <サーバーのパブリックキー>
Endpoint = vpn.example.com:51820
AllowedIPs = 0.0.0.0/0TCP over TCP問題の回避
もしOpenVPNをTCPモード（ポート443フォワードなど）で運用せざるを得ない場合、内側のTCPと外側のTCPがそれぞれ独自に再送制御と輻輳制御を行うため、「TCP Meltdown」と呼ばれる深刻なスループット低下を引き起こす。可能な限りVPNはUDPベース（WireGuardやOpenVPNのUDPモード）を選択すべきだ。
—
5. まとめ：セキュリティと速度のトレードオフをハックする
VPNベンチマークの測定とボトルネック分析の本質は、「どこでパケットがドロップし、どこでCPUやバッファが飽和しているか」を可視化するプロセスに他ならない。
1. iperf3 と sysctl の BBR 有効化 でトランスポート層の限界を突破する。
2. 適切なMTU設定 により、不要なIPフラグメンテーションとPMTUDの破綻を防ぐ。
3. WireGuardなどのモダンなUDPプロトコル を採用し、二重のオーバーヘッドを排除する。
セキュリティを強固にしながら、回線の物理限界ギリギリまでパフォーマンスを引き出す――これこそが、ネットワークの深淵を愛するプロフェッショナルの技術的ロマンである。あなたのVPN環境も、今日のチューニングで劇的な変化を遂げるはずだ。さあ、パケットを解放しよう。
コメント