レガシーの皮を被った多重構造：L2TP/IPsecのパケットがたどる過酷な旅路
こんにちは。ネットワークの配管工からカーネルの隅っこまで愛してやまない技術系ライターの私だが、今回はあえて「レガシー」のタグが貼られつつも、今なお企業の拠点間接続や個人向けVPNの片隅でしぶとく生き残り続ける「L2TP/IPsec」の深淵にメスを入れたい。
現代のゼロトラスト全盛期において、TLS 1.3やWireGuardのような洗練されたモダンプロトコルが持て囃されるのは当然だ。しかし、インフラエンジニアとして現場の最前線に立つ我々は、カフェのフリーWi-Fiから飛んできた泥臭いパケットが、どのようにルーターやファイアウォールを突破し、カーネルのネットワークスタックを悶えさせながらデカプセル化されていくのか、その「痛覚」を正確に理解しておく必要がある。
今回は、L2TP/IPsecが抱えるUDPポート 500 番と 1701 番、そしてペイロードを包み隠す ESP（Encapsulating Security Payload） の実態を、パケットレベルの挙動とともにつまびらかにしていこう。
—
1. 二重の衣を纏うパケット：L2TPとIPsecの役割分担
L2TP（Layer 2 Tunneling Protocol）それ自体は、暗号化機能を一切持たない。ただの「レイヤー2のフレームをUDPパケットに詰め込んで運ぶための箱」に過ぎない。つまり、L2TP単体をオープンなインターネットに放り投げた瞬間、通信は丸裸のまま世界中に晒されることになる。
そこで登場するのがIPsecだ。IPsecはL2TPのパケット全体をまるごと暗号化し、セキュリティの担保（機密性・完全性・認証）を一身に背負う。この「L2TPがトンネルを掘り、IPsecがその中身を厳重に封印する」という二重構造こそが、L2TP/IPsecの正体である。
この通信が開始されるとき、ネットワークの境界では次のようなドラマが展開される。
1. ISAKMP（IKE Phase 1）: お互いの身元を確認し、安全な暗号通信路（SA: Security Association）を確立する。ここで使われるのが UDPポート 500 番 だ。
2. IPsec（IKE Phase 2 / ESP）: 実際のデータ暗号化のパラメータをネゴシエーションし、データ本体の転送が始まる。ここで ESP（IPプロトコル番号 50） や、NAT環境をバイパスするための UDPポート 4500 番（NAT-T） が絡んでくる。
3. L2TP制御・データ転送: トンネルが無事に開通したあと、L2TP自体のセッション確立やデータグラムの転送に UDPポート 1701 番 が使われる。
—
2. ポート 500 と 1701、そして ESP のパケット解剖学
実際にパケットキャプチャ（tcpdump や Wireshark）を覗いたとき、このプロトコルスタックがどれほど複雑なカプセル化を行っているかを知ることは、トラブルシューティングの速度を劇的に向上させる。
① UDPポート 500番：IKE（Internet Key Exchange）の死闘
クライアントがVPN接続を開始すると、まず宛先ポート 500 番に向けてISAKMPパケットが飛ぶ。ここは Diffie-Hellman 鍵共有やPre-Shared Key（PSK）による認証が行われる、いわば「要塞の門番」だ。
ステートフルなファイアウォールはこのポートへのトラフィックを監視し、セッション状態を厳密に管理する。
② ESP（IPプロトコル番号 50）：暗号化された実データの奔流
IKEのハンドシェイクが完了すると、L2TPパケットはIPsecによって暗号化され、IPヘッダーの直下に ESPヘッダー を伴ってカプセル化される。
ここで注意すべきは、ESPは TCPでもUDPでもなく、レイヤー3（IP層）の直接のプロトコル（Protocol 50） であるという点だ。これが何を意味するか？
そう、NAPT（Network Address Port Translation）を行う一般的な家庭用ルーターや安価なブロードバンドルーターは、ポート番号を持たないESPパケットを見た瞬間、「これ、どこにルーティングすればいいんだ？」とパニックを起こし、容赦なくパケットをドロップ（あるいはステートフルインスペクションで破棄）するのだ。
③ UDPポート 1701番：L2TPの皮肉な運命
そして、L2TPの識別子である UDPポート 1701 番 だ。教科書的には「L2TPはポート 1701 を使用する」と書かれているが、実際のIPsecトンネル内（ESPで暗号化された内側）を覗いてみると、実はハンドシェイクの初期段階を除いて、ポート 1701 が単体で剥き出しのまま流れることは稀である。
IPsecのトランスポートモード、あるいはトンネルモードの内部でカプセル化されるため、外側のパケットヘッダーからは直接見えないことが多い。また、L2TPはUDPベースでありながら、セッションの信頼性を自前で担保しようとするため、パケットロスが多い回線ではTCPの再送制御と競合し、著しいスループットの低下を引き起こす。
—
3. 現代のネットワークにおける「NATの呪い」とNAT-T
前述した通り、ESPプロトコルはポート番号を持たないため、NAPT環境との相性が最悪だ。個人向けVPNとしてL2TP/IPsecを利用する場合、ユーザーの多くは自宅のWi-Fiルーターやスマホのテザリング（つまりNATの背後）から接続を試みる。
この問題を解決するために発明されたのが NAT-Traversal（NAT-T） である。
NAT-Tが有効な場合、IKEのハンドシェイクの段階で「俺たちの間にNATルーターがあるぞ」と検知されると、通信は強制的に UDPポート 4500 番 にカプセル化（UDP-Encapsulated ESP）される。
これにより、パケットは通常のUDPパケットに化け、ルーターのNAPTテーブルにポートマッピングを維持したまま、無事にNATの壁をすり抜けることができるようになる。
—
4. 実務で役立つ設定とトラブルシューティング
Linux（StrongSwanやxl2tpd）環境でL2TP/IPsecを構築、あるいはトラブルシュートする際の実践的な知見を共有しよう。
ファイアウォール（nftables / iptables）の要件
クラウド上のVPSなどでL2TP/IPsecサーバーを立てる場合、以下のポートとプロトコルを完全に空けておく必要がある。さもなければ、接続要求はサイレントドロップの海に沈む。
# nftablesでL2TP/IPsecに必要なポートとプロトコルを許可する設定例
table inet filter {
chain input {
type filter hook input priority filter; policy drop;
# 確立済み・関連づけられたパケットの許可（ステートフルファイアウォールの基本）
ct state established, related accept
# 1. IKE（ISAKMP）用：UDPポート 500
udp dport 500 accept comment "Allow IKE for IPsec"
# 2. NAT-T用：UDPポート 4500
udp dport 4500 accept comment "Allow NAT-Traversal for IPsec"
# 3. L2TP用（必要に応じて）：UDPポート 1701
udp dport 1701 accept comment "Allow L2TP control/data"
# 4. ESPプロトコル（Protocol 50）の直接許可（NATがない環境やサーバー間接続用）
ip protocol esp accept comment "Allow raw ESP packets"
}
}カーネルパラメーター（sysctl）のチューニング
L2TP/IPsecはカプセル化のオーバーヘッドが大きく、MTU（Maximum Transmission Unit）問題によるフラグメンテーション（断片化）がパフォーマンス低下の主原因になりやすい。
パケットがルーターで断片化され、それがドロップされる（PMTUDブラックホール問題）を防ぐため、以下のカーネルパラメータを調整しておくと吉だ。
# /etc/sysctl.d/99-vpn-perf.conf
# パケットのフォワードとマスカレードを有効化
net.ipv4.ip_forward = 1
# パスのMTUディスカバリーを強制し、断片化によるドロップを防ぐ
net.ipv4.tcp_mtu_probing = 1
# UDPバッファのサイズを拡大し、高スループット時のパケットドロップを防ぐ
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216さらに、pppインターフェースが生成された際には、MTU/MRUを適切に調整（通常は 1400 や 1360 程度に）し、IPsecの暗号化ヘッダー分（約 50〜70 バイト）を考慮したオーバーヘッドを吸収させることが、安定稼働の秘訣となる。
—
5. 結びにかえて：レガシープロトコルに向き合う姿勢
L2TP/IPsecは、UDP 500 番での鍵交換、ESPによる重厚長大かつNAPT泣かせな暗号化、そしてUDP 1701 番を内包する複雑なカプセル化構造を持っている。モダンなWireGuardやOpenVPN（TLS）のシンプルさと比べると、どうしても「古き良き時代の遺物」に見えるかもしれない。
しかし、主要なOS（Windows, macOS, iOS, Android）が標準でネイティブサポートしているという圧倒的な利便性ゆえに、インフラエンジニアがこのプロトコルと対峙する機会は今後もゼロにはならないだろう。
パケットがどのポートを叩き、どのプロトコルレイヤーでカプセル化され、どこでNATの洗礼を受けているのか――その足跡を頭の中で完璧にトレースできる能力こそが、真のネットワーク・セキュリティスペシャリストの武器である。泥臭いパケットの旅路に思いを馳せながら、今日も安全で頑健なネットワークを構築していこう。
コメント