L2TP、GRE、IPsec：セッションを運ぶのはどの層か

L2TP、GRE、IPsec が同じ設計メモに並ぶと、二つの問いが絡み合います——どのセッションを運んでいるのか、どの層がそれを保護するのか。前者を間違えると、下流はすべて内部的に整合したまま、間違った問題を解くことになります——ユーザーがダイヤルインすべき場所にルーティングされたオーバーレイを築いたり、拠点間ゲートウェイの代わりにダイヤルイン集中装置を置いたりするのです。下のワークシートは、誰かが機器にログインする前にその区別を強制します。順番に埋めていけば、各行は単独で検証できるものになります。

プロトコル一覧ではなくセッションから始める

PPP セッションを持つリモートユーザーと、二つのゲートウェイ間のルーティングされたオーバーレイは、どちらも最終的に IPsec で包まれるとしても、別のネットワーク関係です。前者はユーザーごとのリンクを終端し、アドレス割り当て、人または機器の認証、そのユーザーが到達できる内部ネットワークを指定するポリシーを必要とします。後者は誰もダイヤルインしない拠点間でパケットを転送します。

どちらを構築しているのかを一文で書き、それを運用する人のつもりで読み返してください。その文に「と」が必要なら両方を構築しており、ワークシートには、それぞれに中途半端に奉仕する妥協の一列ではなく二列が必要です。ユーザーを挙げてもアドレスプールがなく、プレフィックスを挙げても転送ポリシーがないなら、その文はまだ不完全です。官僚的に聞こえますが、ヘルプデスクのチケットで発覚するはずの設計を捕まえる最も安い場所です。

各層にちょうど一つの役割を与える

L2TPv2 は二つの端点の間で PPP セッションを運びます。PPP がリンク折衝を、折衝される場合はユーザー認証を行い、L2TP は暗号を一切追加しないため、素の L2TP デーモンは IPsec のセキュリティ関係をまったく実装せず、すでに信頼しているリンクの内側にしか属しません。

GRE は二つのアドレス間のカプセル化です。論理オーバーレイを越えてネットワーク層のパケットを運び、それ自体では機密性も認証されたピア識別も提供しません。これは欠陥ではなく、ヘッダーは転送ハードウェアで安く処理できるよう意図的に単純に設計されています。結果として GRE は「このパケットを二つのアドレス間でどう運ぶか」にだけ答え、それ以外には何も答えず、まさに尋ねるべき問いに応じます。

こうして IPsec が、トラフィックを選択し、ピアを認証し、保護を指示されたものを暗号化する層として残ります。何を保護するかは設定上の判断であり、端点が実際に生成するカプセル化と一致しなければなりません（GRE の外側アドレス向けに書かれたポリシーと、内側プレフィックス向けに書かれたポリシーでは挙動が異なるためです）。GRE の仕様はペイロード、GRE ヘッダー、外側の配送プロトコルを明確に分けており、ポリシーにも同じ分離が必要です。

設定より先にパケット経路を書く

パケットを一つ取り、追加される各ヘッダーを追加順に列挙し、それを追加する機器を名指ししてください。ダイヤルインユーザーなら通常 PPP が L2TP の中、それが IPsec の中；拠点オーバーレイなら内側の IP パケットが GRE の中、GRE が IPsec の中です。二つの機器が同じヘッダーを追加しているなら、ループか二重トンネルがあり、ポリシーをいくら編集しても直りません。

同じ一覧が MTU を決めます：使える内側のサイズは、測定したパス MTU から今列挙したヘッダーを引いたもので、それ以外ではありません。フォーラムの投稿から数値をコピーしないでください：外側の IP、UDP、ESP のオーバーヘッドを足し、次に GRE か L2TP、該当する場合は PPP を足し、実際に測定したパス MTU から引きます。大きな転送でだけ現れる症状や、確立後に最初の大きな応答で死ぬセッションは、たいていこの加算を推測で行ったことに由来します。

各層を外側から内側へ個別に確認する

チェックを順番に実行し、最初に失敗したところで止めてください。各行は別の問いに答えるので、失敗はトンネルが壊れていると告げるのではなく、ワークシートのどの列かを指します。

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Cisco 機器では対応する操作が役割依存で、正確な構文はプラットフォームとリリースによって異なります：IPsec ピアには show crypto session、GRE またはトンネルインターフェースにはインターフェースカウンター、ダイヤルイン役割には VPDN または PPP の検証を使います。PPP を終端するコマンド一式は GRE 対応を何も証明せず、動作する GRE インターフェースは PPP サービスを何も証明しないので、図の役割ではなく実際に設定した役割を検証してください。

各出力は、それが属するワークシートの行の隣に記録してください。障害が発生している間に取ったメモは、後から記憶で描き直したトポロジーより価値があります。

解体の順序を決め、その後で再検証する

解体を逆順で行うのには理由があります：保護対象のトラフィックを IPsec ポリシーから外してから、そのポリシーが前提としたカプセル化を削除してください、そうしないとポリシーは存在しないインターフェースを指したままになり、次の設定読み込みが無関係に見える場所で失敗します。Linux ではトンネルインターフェースより先に state と policy の項目を削除し、ルーターではトンネルより先に crypto map またはプロファイルの項目を削除します。

再構築後、四つの受け入れ観察を一つずつ繰り返します：外側の到達性、確立した IPsec アソシエーション、設計に含まれる場合は確立した PPP セッション、そして実際の宛先アドレスへの内側転送です。緑のランプ一つは残り三つの証拠にはならず、その隙間こそ本番で最も長く生き残る障害です——トンネルは上がり、暗号化され、内側ルートが一度も追加されていないために何も転送しないのです。

記入済みのワークシートは機器の設定の隣に置いてください。埋められない列は役割の割り当てられていない層であり、役割のない層は通常スタックに入れるべきではない層です。