社内あてのパケットを、別のパケットの中に入れて運ぶ

図 7 では、支店からデータセンターへ社内の住所のまま送ると、プロバイダのルータで止まりました。

図 8 の書き換えは、外のサーバへ行くための道具で、拠点同士をつなぐ話には使えません。 この記事は、図 7 で挙げた 3 つの問題のうち「途中のルータの経路表を自分では書けません」と「社内専用の住所はインターネットでは運ばれません」の 2 つを、拠点同士について解きます。 3 つ目の「通信の中身は誰にでも読めます」は、この図では残ったままです。

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

登場するもの

トンネルインターフェース（Tunnel0）

論理のものです。 ケーブルも物理ポートも 1 本たりとも増えていません。 ルーティングテーブルの出口の欄に、物理ポートと同じように書ける口です。 実体は「包んで別の口から出す」処理です。

カプセル化

1 つのパケットの中に、別のパケットがまるごと入っている状態です。

GRE ヘッダ

論理のもので、通信 1 つずつに付きます。 最小 4 バイトで、この後ろに元のパケットがまるごと入ります。

外側 IP ヘッダ

宛先が相手ルータの外側グローバル IP、送信元が自分の外側グローバル IP です。 IPv4 では 20 バイトです。 プロトコルの欄は 47 で、途中の機器はこの番号で「中に別のパケットが入っている」と分かります。 分かるだけで、中身は読めます。

結びつき

• Tunnel0 ⇄ source と destination の外側グローバル IP は手動です。両端のルータに、互いの外側の番地を人が書きます。
• Tunnel0 ⇄ 社内あての行（192.168.3.0/24 → Tunnel0）は手動です。この行を書かないと、社内あては相変わらずデフォルトルートへ流れて捨てられます。
• トンネルの中の番地（10.0.0.0/30）の行だけ自動です。自分の口の IP から行が載る、という図 1 と同じ理屈が論理の口にも働きます。

通信フロー

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

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

② ルータ 1 はテーブルを探します。192.168.3.0/24 に一致する行の出口が Tunnel0 なので、そこへ渡します。

③ Tunnel0 は元のパケットの前に GRE ヘッダと外側 IP ヘッダを付けます。外側の宛先は 198.51.100.20、送信元は 203.0.113.10 です。できた新しいパケットを、ルータ 1 はもう一度テーブルで探し直し、デフォルトルートに従って Gi1 から送り出します。

④ プロバイダのルータは外側の宛先だけを見て運びます。中に入っている 192.168.3.10 は見ません。

⑤ ルータ 2 の Tunnel0 が外側 IP ヘッダと GRE ヘッダを外します。出てくるのは ① とまったく同じパケットです。それを自分のテーブルで探し、Gi1 から C へ送ります。

図 10

図の上半分が構成図と包むと何が増えるか、下半分が各テーブルと設定・通信の中身の推移です。

図 5 の ② は「一致する行の出口へ送る」でした。 図 10 では、その出口が論理の口になり、包んだ後にもう一度テーブルを探し直す段が増えます。 図 5 には無かった段はここだけで、MAC の付け替えはそのまま生きています。

図 7 の ③ でプロバイダのルータが運べなかったのは、宛先が社内専用の住所だったからです。 図 10 の ④ で運べるのは、外側の宛先がグローバル IP だからです。 プロバイダに載っているのはグローバル IP の経路だけでよく、192.168.3.0/24 の行は 1 つも要りません。

残った問題 3 は、図の帯で内側の宛先・送信元・データが読める状態で並んでいるところに出ています。 次の図 11 で、この中身に封をします。

未検証・注意

• 外側 IP ヘッダ 20 バイトと GRE ヘッダ 4 バイトで、一度に運べる大きさが 24 バイト減ります。Cisco の既定では、トンネルインターフェースの IP MTU は物理インターフェースより 24 バイト小さくなり、1500 に対して 1476 です。1500 は一般的なイーサネットの値、1476 は Cisco の既定値で、どちらも規格が定めた値ではありません。回線によって違います。
• 入りきらないパケットは分割されます。ただし「分割するな」の印（DF）が立っていると分割できず、捨てられます。これは IPv4 一般の決まりです。なお RFC 2784 §9 は「既存の GRE 実装は経路 MTU 探索を行わず、配送ヘッダに分割禁止の印を立てない」と書いているので、外側そのものは途中で分割されることがあります。
• GRE ヘッダは「最小 4 バイト」です。チェックサムを付ける設定では長くなります。
• 再帰ルーティングという事故があります。包んだ後の宛先（トンネルの destination）への経路をトンネル自身から学んでしまうと、包む・出口を探す・またトンネル、と回り続けます。Cisco はこれを %TUN-5-RECURDOWN というログの意味として公開しており、検知するとトンネルを数分間 down にする、と説明しています。直し方は、トンネルの宛先への経路だけを、より範囲の狭い行で別に持たせることです。このログの文字列は Cisco 機器の表示で、他社の機器で同じ言い方をするかは確認していません。
• RFC 2784 にも捨てるという記述はありますが、それは包んだ中身の宛先が自分自身だった場合の話で、再帰ルーティングとは別です。
• 勉強会のラボは 3 拠点・トンネル 3 本という構成でしたが、この図は 2 拠点・トンネル 1 本に単純化しています。

出典

• 勉強会での本人の観察（2026-09-13 実機ハンズオン。資料は非公開）
• RFC 2784: Generic Routing Encapsulation (GRE) — §2 の「Delivery Header / GRE Header / Payload packet」、§2.1 の最小 4 オクテット、§4「The IPv4 protocol 47 is used when GRE packets are encapsulated in IPv4」、§9「既存の実装は経路 MTU 探索を行わず、配送ヘッダに DF を立てない」
• RFC 791: Internet Protocol — §2.3「If internet datagram marked don't fragment cannot be delivered to its destination without fragmenting it, it is to be discarded instead」
• Cisco: GRE と IPsec の断片化・MTU・PMTUD — トンネルインターフェースの IPv4 MTU は既定で物理より 24 バイト小さく、1476 になる
• Cisco: GRE Tunnel Interface Flaps — 宛先への経路がトンネル自身を指すと回り続ける。検知すると数分間トンネルを down にする。トンネルの宛先には範囲の狭いスタティックルートを持たせる

関連

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

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

• 前の記事（図 9）: ネットワーク_09_ACL（/notes/nw-basics-09-acl）

• 次の記事（図 11）: ネットワーク_11_IPsec（/notes/nw-basics-11-ipsec）

• 3 つの問題を出した記事: ネットワーク_07_インターネットを挟む（/notes/nw-basics-07-internet）