OpenVPNの深層：UDP 1194とTCP 443のパケット挙動が語る、パフォーマンスと検閲回避のリアル
ネットワークエンジニアなら誰もが一度は向き合うことになるOpenVPNのポート選定。デフォルトであるUDP 1194と、制限回避の切り札であるTCP 443。この2つの選択肢は、単なる「プロトコルの違い」ではない。OSI参照モデルのトランスポート層における根本的なアプローチの違いであり、さらにはパケットがルーターやファイアウォールを通過する際の「物理的・論理的挙動」そのものを変えてしまう重要な分岐点だ。
教科書的な解説で「UDPは速いが信頼性が低い、TCPは遅いが確実である」と片付けるのは、プロトコルスタックの深部でうごめくカーネルの挙動や、暗号化ハンドシェイクのオーバーヘッドを無視した暴論に等しい。
本稿では、インフラアーキテクトやテックリードの視点に立ち、UDPとTCPのトランスポート層における振る舞い、TLSハンドシェイクの最適化、パケットロス時の挙動、さらには実践的なサーバー設定（server.conf）のチューニングに至るまで、徹底的に解剖していく。
—
1. パケットレベルで見るUDP 1194とTCP 443の根本的な挙動差異
まずは、両者がネットワーク上をどのように流れるのか、その「生態系」を解き明かそう。
UDP 1194：オーバーヘッドを極限まで削ぎ落とした「生」の速度
OpenVPNのデフォルトである UDP 1194 は、コネクションレス型のトランスポート層プロトコルを利用する。
ハンドシェイクのプロセスはシンプルだ。クライアントが UDP ペイロードに包まれたOpenVPNの制御パケット（P_CONTROL_V1など）を送信し、サーバーが応答する。TCPのような3wayハンドシェイクの待ち時間が存在しないため、物理的な回線速度の限界に近いスループットを叩き出す。
しかし、UDPには「信頼性」がない。パケットが途中のルーターのバッファ溢れや輻輳によってドロップした場合、それを検知して再送を要求するのは上位のOpenVPNレイヤー、あるいはさらにその上のアプリケーション層の仕事になる。ここに「高速性」と「パケットロス時のジッター増加」というトレードオフの本質がある。
TCP 443：信頼性の代償としての「TCP Meltdown」問題
一方の TCP 443 は、Webトラフィック（HTTPS）に擬装して厳格なファイアウォールやディープ・パケット・インスペクション（DPI）をすり抜けるために使われる。しかし、ここでインフラエンジニアが最も恐れなければならないのが 「TCP Meltdown（TCPのメルトダウン）」 だ。
VPNトンネルの内部でTCP（例えばSSHやHTTPSのトラフィック）が流れているとき、その下層（トランスポート層）にもTCP（OpenVPNのTCPコネクション）が存在する。これを「TCP over TCP」と呼ぶ。
もし、物理回線の瞬間的なパケットロスによって、外側のOpenVPNのTCPパケットが1つ失われたとする。
1. 外側のTCPはパケットロスを検知し、輻輳制御アルゴリズムに基づいてウィンドウサイズを絞り、再送処理（Retransmission）を開始する。
2. この間、内側のTCPコネクションはパケットが届かないため、「ネットワークが混雑している」と勘違いし、同様にウィンドウサイズを絞り、独自の再送タイマーを起動する。
3. 結果として、両方のレイヤーで再送と輻輳制御が不気味に同期し、スループットが急激に低下、最悪の場合はコネクションが切断される。これがTCP Meltdownのメカニズムだ。
そのため、TCP 443 はあくまで「どうしてもUDPがブロックされる環境（ホテルの厳格なゲストWi-Fiや企業城壁のようなファイアウォール）を突破するための最終手段」として位置づけられるべきである。
—
2. トランスポート層とTLSハンドシェイクの最適化
OpenVPNは、トランスポート層の上に独自のセキュアチャネルを構築するため、内部でTLS（Transport Layer Security）を用いたハンドシェイクを行っている。この初期ネゴシエーションにおける最適化は、接続確立までのレイテンシー（接続遅延）に直結する。
MTU（Maximum Transmission Unit）とフラグメンテーションの罠
VPNトンネルを流れるパケットは、通常のIPパケットにOpenVPNのヘッダーやTLSのオーバーヘッドが付加される。
UDP 1194 の場合、標準的なイーサネットのMTUである 1500 バイトを超過すると、IPフラグメンテーションが発生する。フラグメント化されたパケットの1つがドロップしただけで、元のパケット全体が再送対象となり、実効スループットが著しく低下する。
これを防ぐためには、mssfix や fragment ディレクティブを用い、トンネル内のTCPセグメントサイズを強制的に制限する必要がある。
—
3. 実践：極限のパフォーマンスを引き出すサーバー設定
理論を理解したところで、実務の現場で即座に展開できる堅牢かつ高速なOpenVPNサーバー設定（server.conf）のサンプルを見てみよう。ここでは、パフォーマンスを最大化するUDP設定と、万が一のためのTCP設定の両方を視野に入れたベストプラクティスを提示する。
# ==========================================
# OpenVPN サーバー設定ファイル (server.conf)
# 対象: Linux (Ubuntu/Debian系カーネルチューニング前提)
# ==========================================
# 1. 基本ネットワーク設定
# デフォルトの高速性を狙うならUDP、制限回避ならTCPを指定
proto udp
port 1194
# デバイス設定 (L3ルーティングを行う場合はtun)
dev tun
# 2. 暗号化と認証の強靭化
# モダンな暗号スイートを指定し、CPUのAES-NI命令を活用する
cipher AES-256-GCM
auth SHA256
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
# 3. ネットワーク最適化とMTUチューニング
# パケットフラグメンテーションを防止し、TCP over UDPの効率を最大化
mssfix 1350
fragment 0
# キープアライブの設定 (死活監視とNATセッション維持)
# 10秒ごとにpingを送り、120秒応答がなければ再接続
keepalive 10 120
# 4. バッファサイズの拡張 (Linuxカーネルのソケットバッファと協調)
# デフォルトのバッファサイズを拡大し、高スループット時のパケットロスを防ぐ
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"
# 5. システム・権限設定
user nobody
group nogroup
persist-key
persist-tun
# 6. ログと冗長性
status openvpn-status.log
verb 3この設定におけるキモは、sndbuf と rcvbuf の明示的な拡張、そして mssfix 1350 によるオーバーヘッドの吸収だ。OS標準のソケットバッファサイズでは、広帯域・高遅延（高BDP: Bandwidth-Delay Product）な回線において、パイプが満たされる前に送信がストップしてしまう現象が発生する。バッファを明示的にチューニングすることで、回線のポテンシャルを限界まで引き出すことが可能になる。
—
4. 重大なネットワーク脆弱性の回避とセキュリティ境界の死守
VPNは「安全なトンネル」を作る技術であると同時に、正しく設定されなければ 「社内ネットワークへの侵入経路（バックドア）」 にもなり得る。ゼロトラストアーキテクチャの観点から、絶対に押さえておかなければならないセキュリティ要件がある。
1. 圧縮攻撃（VDE: Voracious Dulling of Encryption / Compression Oracle）への対策
かつて帯域幅を節約するために重宝された comp-lzo などのデータ圧縮機能は、暗号化されたトラフィックのサイズから機密情報を推測されるサイドチャネル攻撃（CRIMEやBREACHに類似した脆弱性）の温床となる。
モダンなOpenVPN環境においては、データ圧縮は一切有効にすべきではない。設定ファイルから comp-lzo などの記述は完全に排除し、帯域はケチらずに回線帯域で殴るのが鉄則だ。
2. ルートリーク（デフォルトゲートウェイの乗算）の防止
クライアント側がVPN接続時に redirect-gateway def1 を有効にすると、すべてのトラフィックがVPN経由になる。しかし、これが原因でローカルネットワーク（自宅のプリンターやLAN内機器）へのアクセスが遮断されたり、DNSリークが発生してプライバシーが露呈する事故が後を絶たない。
クライアント設定側では、明示的にDNSサーバーを指定し、パケットが予期せぬインターフェースから漏れ出していないかを tcpdump や Wireshark で常時監視する体制が不可欠である。
# パケットキャプチャによるDNSリークおよびルーティング確認の例
sudo tcpdump -i tun0 -nn 'port 53'このコマンドを叩き、VPN接続中に名前解決のクエリが正しく tun0 インターフェースを通過しているかを目視確認する。インフラエンジニアたるもの、設定ファイルを信じるな、パケットを信じろ。
—
5. RTT削減とTCPバッファチューニングの極意
最後に、エンドユーザーの体感速度（特にWebブラウジング時のレスポンス）を左右するRTT（Round Trip Time）の削減と、Linuxカーネルレベルのチューニングについて言及しておこう。
OpenVPNのパフォーマンスを限界突破させるためには、OpenVPNの設定だけをいじっても不十分だ。ホストOS（Linuxカーネル）のネットワークスタックが最適化されている必要がある。
/etc/sysctl.conf に以下のパラメータを追記し、カーネルのネットワークバッファを強制的に拡張せよ。
# ==========================================
# Linuxカーネルネットワークチューニング (/etc/sysctl.conf)
# ==========================================
# TCPソケットの最大メモリ割当 (最小, デフォルト, 最大 [bytes])
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# UDP受信/送信バッファの最大値
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# 輻輳制御アルゴリズムの変更 (BBRの有効化によるパケットロス耐性の向上)
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr特に net.ipv4.tcp_congestion_control = bbr（Googleが開発したBBR輻輳制御アルゴリズム）の適用は、パケットロスが常態化する劣悪な公共Wi-Fi環境やモバイル回線において、UDP上のOpenVPNトンネルを通るトラフィックののスループットを劇的に改善する。従来のCUBICアルゴリズムが「パケットロス＝輻輳（混雑）」と誤認して速度を落としていたのに対し、BBRは「実際の帯域幅と伝搬遅延」を直接測定して送信レートを決定するためだ。
—
結びにかえて
OpenVPNの UDP 1194 と TCP 443 の選択、そしてその背後にあるトランスポート層のチューニングは、ネットワークの物理的制約とセキュリティ要件の妥協点を探るスリリングなエンジニアリングの縮図である。
「なぜこのポートを選ぶのか」「なぜこのバッファサイズなのか」「パケットは今、どのカーネル空間でどう処理されているのか」。そのすべてを解像度高く語れることこそが、真のインフラ・セキュリティスペシャリストの条件なのだ。
さあ、エディターを開き、あなたのインフラの server.conf と sysctl.conf を見直す時が来た。
コメント