外から読めるのは、外側の宛先と取り決めの番号だけ

図 10 で、社内あてのパケットを別のパケットの中に入れて運べるようになりました。

ただし、入れただけでは途中の機器が開けば中身が読めます。 勉強会では、ping の中身が読める状態と、ESP に変わって読めない状態を並べて見ました。 この記事は、図 7 で挙げた 3 つの問題のうち、最後に残った「通信の中身は誰にでも読めます」を解きます。

この連載は、ネットワークの言葉を 3 つの層に置いて読みます。 もの（物理か論理か）、結びつき（人が設定で付ける手動か、機器が学習する自動か、製造時に決まる固定か）、通信フロー（1 本の通信がそれらを順に通る道筋）の 3 つです。

登場するもの

ESP ヘッダ

論理のもので、通信 1 つずつに付きます。 中には SPI（取り決めの番号）と連番が入ります。 ESP を運ぶパケットは、外側 IP ヘッダのプロトコルの欄が 50 です。 図 10 では 47 でした。

AH

改ざん検知だけで、暗号化しない封です。 外側のプロトコル番号は 51 です。 この図では使いません。

SA（安全の取り決め）

論理のもので、相手・暗号の方式・鍵・SPI・寿命の組です。 片道に 1 つで、送る側用と受け取る側用は別物です。 だからデータ用は 1 つの相手につき 2 本になります。 勉強会で見た Active SAs: 2 はこの 2 本です。 打合せ用の取り決めは、これとは別にもう 1 つできます。

crypto map

論理のもので、人が書きます。 相手・守る通信の並び（図 9 の ACL）・暗号の組合せを 1 つに束ね、外向きの口に貼ります。

2 つのモード

トンネルモードは元の IP ヘッダごと包むので、社内の宛先も送信元も外から見えません。 トランスポートモードは元の IP ヘッダを残し、中身だけを守ります。 この図の拠点間はトンネルモードです。

結びつき

• crypto map ⇄ 外向きの口は手動です。貼った口を出入りする通信だけが判定にかかります。守りたい通信がその口から出る経路に乗っていることが前提で、この図では 0.0.0.0/0 → 203.0.113.1（Gi1）の行がその役をしています。経路が別の口を向いていれば、貼った組は一度も効きません。
• crypto map ⇄ 守る通信の並び・相手・暗号の組合せも手動です。両側で同じものにしないと合いません。片側だけ直すと通らなくなります。
• SA は自動でできます。ただし勝手に湧くのではなく、打合せ（図 12）の結果としてできます。

通信フロー

支店の A（192.168.10.10）から、データセンターの C（192.168.3.10）へ送ります。

① A はデフォルトゲートウェイ（ルータ 1）へ送ります。図 10 の ① と同じで、PC 側は何も変わりません。

② ルータ 1 は、外向きの口に貼った組の中の「守る通信の並び」に、このパケットが一致するかを上から順に見ます。一致したので、送信用の SA に書かれた方式と鍵で元のパケットをまるごと暗号化し、ESP ヘッダと外側 IP ヘッダを付けます。一致しない通信はそのまま素通しで出ていきます。

③ プロバイダのルータは外側の宛先 198.51.100.20 だけを見て運びます。途中で開いても、暗号化された固まりと ESP の札しか見えません。

④ ルータ 2 は ESP ヘッダの SPI でどの受信用 SA かを選び、改ざん検知をしてから復号します。出てくるのは ① と同じパケットです。

⑤ ルータ 2 は出てきたパケットを自分のテーブルで探し、Gi1 から C へ送ります。

図 11

図の上半分が構成図と封の種類・モード・SA、下半分が各テーブルと設定・通信の中身の推移です。

図 10 の ③ と図 11 の ③ を並べると、箱の並びが同じ形のまま、GRE だった 1 枚が ESP に変わり、内側の宛先と送信元が読めない部分に飲み込まれているのが見えます。 図 10 では内側の宛先まで外から見えていました。

図 9 の行の並びは、ここでは「通す・通さない」ではなく「守る・守らない」の選別に使われます。 同じ道具の別の使い方です。

図 5 の MAC の付け替えも、図 1 のルーティングテーブルもそのまま生きています。 封をする仕組みは口に貼るもので、テーブルの行の書き方を変えません。

SPI と連番が暗号化されないのは、受け取った側がどの取り決めかを選ぶために要るからです。 その取り決めをどうやって作るかが、次の図 12 です。

未検証・注意

• 勉強会で使った 3DES は、RFC 8221 §5 で SHOULD NOT（使うべきでない）に置かれています。今の必須は AES-GCM と AES-CBC です。
• SHA-1 を使う改ざん検知（AUTH_HMAC_SHA1_96）は、同 §6 で MUST-（今はまだ必須だが、いずれ格下げという印）です。「使うな」とまでは書かれていません。必須は HMAC-SHA2-256-128 のほうで、MUST NOT が付いているのは HMAC-MD5-96 です。
• 同 §4 が NOT RECOMMENDED としているのは「ESP と AH を重ねて使うこと」です。AH 単体を非推奨とは書いていません。
• 勉強会で見た「Wireshark では ESP としか見えない」は本人の観察です。SPI や連番がどこまで表示されるかは、この図では確かめていません。
• この図は GRE を使わず IPsec だけで包む形です。GRE と IPsec を重ねて使う構成もありますが、この図では扱っていません。
• 拠点間 VPN の相手は機器の種類を選びません。別の勉強会で扱ったファイアウォールの資料でも、ルータとファイアウォールの間、ファイアウォール同士で、この図と同じ組み立て（互いの認証・守る通信の選別・暗号の組合せ・外向きの口に貼る）を使っていました。これも本人の観察です。
• SPI や鍵の実際の値、事前共有鍵の文字列は書いていません。

出典

• 勉強会での本人の観察（2026-09-13 実機ハンズオン。資料は非公開）
• RFC 4303: IP Encapsulating Security Payload (ESP) — プロトコル番号 50。暗号化されるのはペイロードと ESP トレーラで、SPI・連番・ペイロード・トレーラが改ざん検知の対象。§3.1.1 のトランスポートモードと §3.1.2 のトンネルモードの違い
• RFC 4301: Security Architecture for the Internet Protocol — §4.1「An SA is a simplex 'connection' that affords security services to the traffic carried by it」。双方向には 1 対の SA が要る
• RFC 4302: IP Authentication Header — §2。AH の直前のヘッダはプロトコルの欄に 51 を入れる
• RFC 8221: Cryptographic Algorithm Implementation Requirements for ESP and AH — §5 で ENCR_3DES が SHOULD NOT、ENCR_AES_GCM_16 と ENCR_AES_CBC が MUST。§6 で AUTH_HMAC_SHA2_256_128 が MUST、AUTH_HMAC_SHA1_96 が MUST-、AUTH_HMAC_MD5_96 が MUST NOT。§4 で「ESP+AH. This method is NOT RECOMMENDED」

関連

• ネットワーク_INDEX — 連載の目次

• 連載の入口: ネットワーク_00_3層で言葉を置く（/notes/nw-basics-00-three-layers）

• 前の記事（図 10）: ネットワーク_10_GREトンネル（/notes/nw-basics-10-gre）

• 次の記事（図 12）: ネットワーク_12_IKE（/notes/nw-basics-12-ike）

• 守る通信を選ぶ行の並び: ネットワーク_09_ACL（/notes/nw-basics-09-acl）