こんにちは、現場のネットワークエンジニアの皆さん。夜中に突然「オンプレの基幹システムとクラウドのKubernetesクラスター間のIPsecトンネルが死んだ！Web APIの疎通が全滅だ！」なんていう悪夢のようなアラートを受け取った経験はありませんか？
画面の向こうで冷や汗を流しながら ping を叩き、tcpdump でパケットの墓場を覗き込む……。インフラやWeb APIの設計・運用に携わる私たちにとって、VPN、特にIPsec VPNは、避けて通れない「見えないインフラ」です。
ゼロトラスト全盛の現代においても、拠点間接続（Site-to-Site）や、クラウドとデータセンターをセキュアに直結するパイプラインとして、IPsec VPNは依然としてエンタープライズの脊髄を支え続けています。今回は、このIPsecの基本概念から、パケットレベルの挙動、そして実務で必ず直面する暗号化プロトコルの違いまで、現場の泥臭い知見を交えて徹底的に解説します。
—
1. なぜ今、あえて「IPsec」なのか？ ゼロトラスト時代における位置づけ
「すべてを疑え、常に検証せよ」というゼロトラストの思想において、かつての「社内ネットワークだから安全」という境界防御の神話は崩壊しました。では、IPsec VPNはオワコンかというと、答えは「NO」です。
ゼロトラストアーキテクチャ（ZTA）においても、エンドポイントからリロケートされたマイクロサービス群や、異なるクラウドVPC間を安全に結ぶ「信頼された暗号化オーバーレイネットワーク」の基盤として、IPsecは現役バリバリで使われています。SSL-VPN（TLS）がアプリケーション層やトランスポート層（TCP）を保護するのに対し、IPsecはOSI参照モデルの第3層（ネットワーク層）で動作します。
つまり、TCPだろうがUDPだろうが、ICMPだろうが、IPの上のパケットはすべて丸ごと暗号化の対象にできる。これが、インフラエンジニアとしてIPsecを信頼する最大の理由です。
—
2. IPsecの二大巨頭：AHとESPの決定的な違い
IPsecは単一のプロトコルではありません。実際には、セキュリティアソシエーション（SA）を確立する「IKE（Internet Key Exchange）」と、実際にパケットを保護する「AH」「ESP」というプロトコルたちのチームプレイで成り立っています。
実務で設計する際、ほとんどのケースでESP（Encapsulating Security Payload）を採用することになります。それぞれの役割と「なぜESPなのか」を整理しておきましょう。
AH (Authentication Header)
- 役割: データの「完全性（改ざん検知）」と「送信元認証」を提供します。
- 最大の弱点: 暗号化（機密性）を一切提供しません。
- 実務での立ち位置: 現代のインターネットにおいて、平文でデータを流すことはセキュリティポリシー上あり得ないため、AH単体で使われることは絶滅危惧種レベルで稀です。NAT（ネットワークアドレス変換）越えの相性も最悪です。
ESP (Encapsulating Security Payload)
- 役割: データの「完全性」「送信元認証」に加え、「機密性（暗号化）」を完璧に提供します。
- 実務での立ち位置: IPsecといえば実質的にESPのことを指します。パケットのペイロード全体をカプセル化し、暗号の要塞に閉じ込めてしまいます。
—
3. パケットは中でどう変わる？ トランスポートモードとトンネルモード
IPsecのパケットカプセル化には、2つのモードが存在します。ここを混同すると、ルーティング設計で大惨事を引き起こします。
1. トランスポートモード
- 元のIPヘッダーはそのままで、その直後にIPsecヘッダー（ESPなど）を挿入し、ペイロードを暗号化します。
- *用途:* ホスト間（端～端）の通信。実務ではあまり直接使われず、後述のL2TP over IPsecなどで見かける程度です。
2. トンネルモード
- 元のIPパケット全体を丸ごと新しいESPパケットで包み込み、全く新しいIPヘッダーを外側に付与します。
- *用途:* 拠点間（Site-to-Site）接続。AWSのVPNゲートウェイやAzureのVPN Gatewayなど、クラウドとオンプレを繋ぐときは100%これです。
トンネルモードのパケット構造のイメージ
[ 新しいIPヘッダー (GW間) ] + [ ESPヘッダー ] + [ 元のIPヘッダー (内部NW) ] + [ TCP/UDP + ペイロード ] + [ ESPトレーラー/認証子 ]この「外側のIPヘッダー」のおかげで、ルーター同士がグローバルIPでルーティングしつつ、内側のプライベートIPパケットを安全に宛先まで運べるわけです。
—
4. 実務で役立つ設定とパラメータの勘所（StrongSwanの例）
Linux（UbuntuやCentOS）のオープンソースIPsec実装である StrongSwan を使った設定ファイル（ipsec.conf）のサンプルを見てみましょう。実務でよく遭遇するAES-GCMやIKEv2を用いたモダンな構成です。
# /etc/ipsec.conf の設定例
conn aws-to-onprem
# IKEのバージョンは必ずv2を指定する（v1はレガシーかつ脆弱性が多いため排除）
ikev2 = yes
# 接続モード（トンネルモード）
type = tunnel
# 自局（オンプレ側）のグローバルIPと識別子
left = 203.0.113.10
leftid = onprem-gw.example.com
leftsubnet = 10.100.0.0/16 # オンプレ側のプライベートネットワーク
# 相手局（クラウド側）のグローバルIPと識別子
right = 198.51.100.20
rightid = aws-vpn.example.com
rightsubnet = 172.16.0.0/16 # クラウド側のVPC CIDR
# 暗号化アルゴリズムと完全性アルゴリズムの指定（IKEv2 / Phase 1 & Phase 2）
# AES-GCMを使うことで、暗号化と認証を同時に高速処理させるのがモダンなトレンド
ike = aes256gcm16-prfsha384-ecp384!
esp = aes256gcm16-ecp384!
# ライフタイム（鍵の有効期限。短すぎると再鍵交換で瞬断し、長すぎるとセキュリティリスク増）
keyingtries = %forever
ikelifetime = 8h
lifetime = 1h
# 自動起動設定
auto = start現場のエンジニアがハマる「パラメータ不一致」の罠
- IKEv1 vs IKEv2: 相手がCiscoでこっちがYamahaやLinuxの場合、IKEのバージョンやフェーズ1/フェーズ2のアルゴリズム（Proposal）が1つでも異なると、容赦なく「NO_PROPOSAL_CHOSEN」というログを吐いてトンネルは立ち上がりません。
- MTUとMSSの調整（PMTUDの悲劇）: IPsecでパケットをカプセル化すると、ヘッダーの分だけパケットサイズが肥大化します。フレキシブルに調整しないと、Web API経由の大きなJSONペイロードやPOSTリクエストだけが途中でドロップ（ブラックホールルーター問題）します。インターフェースのMSS（Maximum Segment Size）クランプ設定は必ず行いましょう。
—
5. トラブルシューティングの現場から：パケットをどう追うか？
もしWeb APIの疎通確認テスト（例えばPythonの requests や curl）を実行してタイムアウトした場合、どこを疑うべきでしょうか？
import requests
from requests.exceptions import RequestException
# クラウド上のAPIエンドポイントへ疎通テスト
url = "https://172.16.10.50/api/v1/healthcheck"
try:
# IPsecトンネル経由で内部APIを叩く想定
response = requests.get(url, timeout=5)
print(f"ステータスコード: {response.status_code}")
print(f"レスポンスボディ: {response.json()}")
except RequestException as e:
print(f"通信エラーが発生しました: {e}")
# このエラーが出たら、アプリケーション層ではなくインフラ（IPsec SA）を疑うこのPythonスクリプトがタイムアウトを吐いたとき、シニアエンジニアが最初に叩くべきコマンドはこれです。
# StrongSwanの状態確認（SAが確立されているか）
sudo swanctl --list-sas
# 生のパケットをキャプチャしてESPパケット（Protocol 50）が流れているか確認
sudo tcpdump -i eth0 -nn 'esp or port 500 or port 4500'port 500とport 4500はIKE（鍵交換）に使われるUDPポートです。ここがハンドシェイクすらしていないなら、ファイアウォール（セキュリティグループ）の穴あけ漏れか、プレシェアードキー（PSK）のミスです。- ハンドシェイクは成功しているのにデータが流れない場合は、前述の
leftsubnet/rightsubnetのルーティング定義ミスや、ルーターのNAT-T（NAT Traversal / UDP 4500）の不具合を疑います。
—
まとめ：見えないネットワークを「見える化」する力
IPsec VPNは、設定が正しければ驚くほど強固に、そして無言でデータを守り続けます。しかし、ひとたび設定が噛み合わなくなると、そのエラーメッセージの不親切さ相まって、インフラエンジニアの精神をゴリゴリと削ってくる曲者でもあります。
大切なのは、「今、どの層で、何のプロトコルが何をやっているのか（IKEで鍵を握手しているのか、ESPでデータを暗号化して流しているのか）」を頭の中でパケットの動きとしてイメージできることです。
トラブルに直面したときは、焦らず swanctl のログを開き、tcpdump でパケットの息遣いを感じ取ってください。ネットワークの挙動に魔法はありません。すべてはパケットの往来という物理的（論理的）な事実の積み重ねなのですから。
コメント