ゼロトラスト時代でも生き抜くIPsec「トンネルモード」の正体：パケットの全カプセル化と拠点間接続の鉄則
こんにちは。ネットワークの現場を渡り歩いてきたシニアエンジニアの私です。
現代のセキュリティ界隈では「ゼロトラスト」が合言葉のように叫ばれています。「もう社内ネットワークの内側だから安全、という時代は終わった。すべての通信を検証せよ」――その思想自体は100%正しい。しかし、どれほどクラウドシフトが進み、マイクロセグメンテーションが導入されようとも、企業の本社、支店、そしてクラウド上のVPC（仮想プライベートクラウド）同士をセキュアに結びつける「大動脈」として、IPsec VPNが消えてなくなることはありません。
ゼロトラストアーキテクチャにおいても、信頼できないインターネットをまたいでセキュアな境界（トランスポート層・ネットワーク層での暗号化トンネル）を築くための基盤として、IPsecは今なお現役バリバリの主役です。
そして、そのIPsecの挙動を語る上で避けて通れないのが「トンネルモード」です。
今回は、パケットが暗号化され、荒波のようなインターネットの海をどうやって安全に渡っていくのか。その内部構造から、実務で絶対にハマるパラメータの調整、そして設定ファイルの具体例まで、現場の泥臭い知見を交えて徹底的に解説します。
—
1. トランスポートモードと何が違う？ トンネルモードの基本構造
IPsecには、大きく分けて「トランスポートモード」と「トンネルモード」の2つの動作モードが存在します。
- トランスポートモード： ペイロード（データ本体）だけを暗号化・認証し、元のIPヘッダーはそのまま利用する。主に「ホスト間（エンドツーエンド）」の通信で使われます。
- トンネルモード： IPパケットの「全体（元々のIPヘッダー＋ペイロード）」を丸ごと新しいIPパケットで包み込み（カプセル化）、さらに新しいIPヘッダーを付与する。主に「ゲートウェイ間（拠点間）」の通信で使われます。
なぜ拠点間接続では「トンネルモード」が必須なのか？
Web APIやアプリケーションの開発者であれば、「通信の暗号化＝TLS」を思い浮かべるでしょう。確かにアプリケーション層の保護にはTLSが最強です。しかし、企業の拠点間接続やクラウドとの接続において、TLSだけでは対応できない致命的な壁があります。それは「ルーティング」です。
想像してみてください。あなたの会社の東京本社（プライベートIP: 192.168.10.0/24）から、大阪支店（プライベートIP: 192.168.20.0/24）のファイルサーバーへアクセスしたいとします。これらのプライベートIPアドレスは、グローバルインターネット上ではルーティングできません。
ここでトランスポートモードを使うと、元々の 192.168.10.x から 192.168.20.x 宛てのIPヘッダーがそのまま露出し、インターネット上のルーターはどこへ送ればいいか迷子になってパケットを破棄します。
一方、トンネルモードであればこうなります。
1. 元のパケット（送信元: 192.168.10.50 / 宛先: 192.168.20.50）を丸ごと暗号化する。
2. その外側に、両拠点の「VPNゲートウェイのグローバルIPアドレス」を送信元・宛先とした新しいIPヘッダーを張り付ける。
3. インターネット上のルーターは、この新しい外側ヘッダー（グローバルIP）だけを見て、パケットを対向のVPNゲートウェイまで確実にお届けする。
4. 対向のVPNゲートウェイがパケットを受け取り、外側ヘッダーを剥がし、内側のパケットを復号して大阪支店の内部ネットワークへ送り出す。
この「パケットの包み直し（カプセル化）」こそが、トンネルモードが拠点間接続において不可欠とされる所以です。
—
2. IPsecトンネルの通信フロー（IKEからデータ転送まで）
IPsecトンネルが確立されるまでには、厳密なダンス（ハンドシェイク）が行われます。現場でトラブルシューティングを行う際、このシーケンスのどこで止まっているかを把握しているかどうかが、復旧スピードを大きく左右します。
一般的に現代のIPsecは、IKEv2（RFC 7296）を用いて確立されます。
[東京本社VPNGW] [大阪支店VPNGW]
| |
| ----- 1. IKE_SA_INIT (暗号アルゴリズム交渉) ----> |
| <---- 2. IKE_SA_INIT (応答・DH公開鍵交換) ------ |
| |
| ----- 3. IKE_AUTH (認証・ID提示・CHILD_SA要求)-> |
| <---- 4. IKE_AUTH (認証完了・IPsecトンネル確立)- |
| |
| ================================================ |
| 5. ESPによる暗号化パケットの往来 |
| ================================================ |ステップの解説
1. IKE_SA_INIT： 双方が安全に暗号化通信を行うための「親セッション（IKE SA）」を確立します。ここでDiffie-Hellman鍵交換を行い、共通鍵の元となる情報を安全に共有します。
2. IKE_AUTH： お互いの身元（事前共有鍵（PSK）やデジタル証明書）を証明し合い、いよいよ実際のデータ通信路である「子セッション（CHILD_SA / IPsec SA）」のパラメータを交渉します。このタイミングで「どのネットワーク同士をトンネルで結ぶか（Traffic Selector）」が合意されます。
3. ESP（Encapsulating Security Payload）通信： ネゴシエーションが無事に完了すると、ESPプロトコル（IPプロトコル番号 50）を用いて、実際にトンネルモードでカプセル化されたデータが流れ始めます。
—
3. 実務で直面するパラメーターの罠と設定例
ここからは、実務のインフラ構築でそのまま役立つ設定例を見ていきましょう。
代表的なオープンソースのIPsec実装であるStrongSwan（Linux）を例に取ります。設定ファイルである /etc/ipsec.conf の記述を見てください。
StrongSwanの設定例 (/etc/ipsec.conf)
config setup
uniqueids = yes
conn tokyo-to-osaka
# IKEのバージョン指定（現代はIKEv2一択です）
keyexchange = vike2
# 接続タイプ（ここでトンネルモードを指定）
type = tunnel
# 動作モード（初期接続のアクション：両側から張る場合は 'start' または 'route'）
auto = start
# 自拠点（東京）の情報
left = 203.0.113.10 # 東京GWのグローバルIP
leftid = @tokyo.gw.example.com
leftsubnet = 192.168.10.0/24 # 東京本社の内部ネットワーク
# 相手拠点（大阪）の情報
right = 198.51.100.20 # 大阪GWのグローバルIP
rightid = @osaka.gw.example.com
rightsubnet = 192.168.20.0/24 # 大阪支店の内部ネットワーク
# 暗号化・認証アルゴリズムの指定（フェーズ1 / IKE_SA）
ike = aes256gcm16-prfsha384-ecp384!
# 暗号化・認証アルゴリズムの指定（フェーズ2 / CHILD_SA）
esp = aes256gcm16-ecp384!
# ライフタイム（定期的な鍵の再生成時間）
lifetime = 3600
ikelifetime = 28800現場で絶対に知っておくべき「パラメーターの落とし穴」
1. Traffic Selector（サブネット設定）の不一致
leftsubnetとrightsubnetの設定が、対向の機器（Ciscoルーターやパロアルトなど）と1ビットたりともズレていてはなりません。片方が192.168.10.0/24で、もう片方が192.168.10.0/25などと設定ミスしていると、IKE_AUTHの段階で「Proposal mismatch（提案のミスマッチ）」を起こして沈黙します。ログを泣きながら見直すポイントNo.1です。
2. MTU（Maximum Transmission Unit）とフラグメンテーションの悲劇
- これがインフラエンジニアを最も悩ませる問題です。トンネルモードは、通常のIPパケットに「ESPヘッダー」や「新しいIPヘッダー」を上乗せするため、パケットサイズが大きくなります（通常、数十バイトのオーバーヘッドが発生します）。
- 標準のインターネット回線のMTUが
1500の場合、VPNトンネルを通るパケットの最大サイズ（MSS）を調整しないと、パケットが巨大になりすぎて途中でルーターに断片化（フラグメンテーション）され、最悪の場合はパケットロスやWeb APIのタイムアウトを引き起こします。
—
4. トラブルシューティング：パケットロス・MSS調整の実践知見
もしあなたが構築したIPsec VPNトンネルを通して、大阪のサーバーから東京のAPIサーバーへ大容量のPOSTリクエスト（JSONデータなど）を送った際、「なぜか小さいリクエストは通るのに、大きなデータになると途中でフリーズする（タイムアウトする）」という現象に遭遇したなら、それは99% MTU/MSS問題です。
対策：TCP MSS Clamping の設定
ルーターやLinuxのIPsecゲートウェイ側で、通過するTCPパケットのMSS（Maximum Segment Size）を強制的に書き換える「MSS Clamping」を設定します。
Linux（nftables または iptables）を使用している場合、ファイアウォールルールで以下のように設定してパケットサイズを調整します。
# iptablesを使用している場合、SYNパケットのMSSを1360バイトに制限する
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
# nftablesを使用している場合（モダンなLinuxディストリビューション）
sudo nft add rule inet filter forward tcp flags syn / syn,rst tcp option maxseg size set 1360※一般的に、標準的なMTU 1500 からIPsecのオーバーヘッド（ESP等で約50〜60バイト）を引いた安全値として、MSSを 1360 もしくは 1380 にクランプすることが実務の定石となっています。
—
まとめ
今回は、IPsecの「トンネルモード」の仕組みから、実際の拠点間接続における重要性、そして現場で必ず直面する設定やトラブルシューティングの勘所まで解説しました。
- トンネルモードとは、 IPパケット全体を丸ごとカプセル化し、新しいグローバルIPヘッダーを付与することで、プライベートIP同士の通信をインターネット上でルーティング可能にする技術である。
- 拠点間接続やクラウド連携では必須であり、アプリケーション層のTLSとは異なり、ネットワーク層全体をセキュアに接続する大動脈となる。
- サブネットの整合性とMTU/MSSの管理こそが、実運用で障害を防ぐためのプロの技である。
ゼロトラストの時代であっても、「信頼できるセキュアなパイプライン」をインフラストラクチャレベルで担保する技術としてのIPsecの価値は揺るぎません。本記事が、皆さんの日々のインフラ設計やトラブルシューティングの一助となれば幸いです。
それでは、また次回の技術現場でお会いしましょう。
コメント