2つのゲートウェイ間でIPsecトランスポートモードを使用する方法
IPsecトランスポートとトンネルモードの多くの比較を読みましたが、2つのゲートウェイがルーティングされたトラフィックを交換している場合、それらはshouldトンネルモードを使用することが明確に理解されています。つまり、トランスポートモードすべきは、2つのホスト間（またはトラフィックがルーティングされず、相互に通信している場合は2つのゲートウェイ間）でのみ使用されます。私が理解しようとしているのは、トランスポートモードcanがゲートウェイ間設定で使用されているかどうかです。
私の設定は次のとおりです：
LAN1 <-> GW1 <-> GW2 <-> LAN2
私の場合、GW1とGW2の間のリンク（LAN1との間のLANへのIPトラフィックを含む）を保護したいと思います。それは直接接続であり、ルーティングは含まれず、NATも何もありません。トンネルモードが推奨される（およびトランスポートモードは推奨されない）理由はすべて私のケースには当てはまりません。IPヘッダーを暗号化しないままにしてもかまいません。オーバーヘッドバイトを節約したいので、この場合は推奨されていませんが、トランスポートモードを使用したいと思います。
ESPモードで、StrongswanパッケージとIPsecを備えたUbuntu Linuxを使用しています。
私の質問は：それはまったく可能ですか？
それを不可能にする「根本的な」理由はありますか、それとも単に「推奨されていない/通常行われていない/シスコのマニュアルに記載されていない」のですが、実行可能ですか？
誰かが機能する設定ファイルを持っていますか？
問題は、透過的にIPsecを適用することです。
セキュリティアソシエーション（SA）の識別に使用されるSPIはグローバルに一意ではなく、受信ホストによって割り当てられるため、セキュリティアソシエーションデータベース（SAD）のタプルSPIでSAを一意に識別します。プロトコル（ESPまたはAH）と宛先IPアドレスが使用されます。これは、ホストがインバウンドIPsecパケットを処理する方法でもあります。デフォルトでは、受信したパケットからのデータと一致するタプルを持つSADエントリを単に検索します（また、最初に宛先アドレスがローカルであるかどうかを確認してから、SPIとプロトコルのみを使用してSADでルックアップします。これが RFC 4301のセクション5.2 で説明されています）。
ただし、説明されているシナリオでは、宛先はホストに対してローカルな単一の既知のIPアドレスではなく（トンネルモードおよびホスト間転送モードの場合のように）、代わりに、値の範囲全体を取る可能性があります受信ゲートウェイの背後にあるホストのアドレス。したがって、デフォルトのルックアップは使用できません。
必要なのは、宛先アドレスを無視するルックアップ（ゲートウェイの背後にあるホストがIPsec自体を使用し、同じSPIを割り当てた場合に不一致を引き起こす可能性がある）、またはIPアドレスのサブネット/範囲の一致のいずれかです。
Linuxカーネルに関する限り、これらのオプションはどちらも使用できません。インバウンドIPsecパケットのSADエントリを検索するコード（ __xfrm_state_lookup ）は、SADエントリに格納されている宛先アドレスの照合を要求します。したがって、宛先アドレスの処理方法を変更する方法でカーネルのソースコードを変更しない限り、トンネルモードの使用は避けられません。
各ゲートウェイの背後にある単一のIPアドレスについては、Linuxカーネル（およびstrongSwan）がサポートするBEETモードと呼ばれるものが存在します。このモードでは、パケットはトランスポートモードで（ゲートウェイアドレス間で）送信されますが、処理の前/後に、IPヘッダーのアドレスはマッピングアドレスに従って変更されます（ネゴシエートされた単一アドレストラフィックセレクター、-- ドラフトを参照） -nikander-esp-beet-mode （詳細））。
補足：LinuxカーネルにはSAのXFRM_STATE_WILDRECVというフラグがあります。これは、IPv6のワイルドカードアドレス照合を許可しますが、（宛先オプションとタイプでパケットを処理するために）別のルックアップ関数を介してモバイルIPv6でのみ使用されます。 2ルーティング拡張ヘッダーのようです）。