XFRMインターフェースでルートベースIPsecが機能する仕組み

ルートベースIPsecは、かつてポリシーセレクターが下していた判断をルーティングテーブルに渡します。Linuxでそれを可能にする部分がXFRMインターフェースです。セレクターではなくインターフェース識別子によって、トラフィックがIPsec状態と照合される仮想デバイスです。作成するにはコマンド一つで済み、トンネルが存在するかどうかは何も証明しません。このデバイスはルーティングとセキュリティポリシーの間のフックであり、何かを保護する前にそのフックの両側を設定する必要があります。

デバイスとは何か、何ではないか

XFRMインターフェースはルーティングの取っ手です。そこへルーティングされたパケットは、同じインターフェース識別子を参照するXFRMポリシーと照合され、ポリシーと状態の両方があればカプセル化されます。それらがなければインターフェースは存在してもカウンターは動かず、トラフィックは役に立たない場所へ向かいます。

これが最初の診断上の分岐点です。 デバイスへのルートはルーティングの事実ですが、インストール済みの状態はセキュリティの事実であり、デバイス上で増えるカウンターはどちらでもありません。インターフェースがUPを示すからトンネルが上がっていると言うとき、人々は自分自身のピアを持たない仮想デバイスのリンクフラグを説明しているだけです。フラグはデバイスが作成され有効化されたことを意味するだけで、それ以上ではありません。

もう一つの境界があります。インターフェース識別子は名前ではありません。似た名前で異なる識別子を持つ二つのデバイスは状態を共有せず、誤った識別子で設定された接続は、どのルートも決して使わない状態をインストールします。

正しい順序で一つ作る

外側のデバイスと、デーモンの設定にも書く番号から始めます。例では外側のインターフェースにeth0、識別子に42を使用しています。これらは自分のアドレスに置き換えてください。

デバイスを立ち上げ、VPN設定に触れる前にカーネルが記録した識別子を確認します：

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

次に、同じ識別子でstrongSwanの接続を設定します。デーモンはそれを参照するポリシーと状態をインストールしなければならないからです。ローカルとリモートのトラフィックセレクターを、ルーティングしたい範囲に設定し、その範囲をデバイスへルーティングします。デーモンの設定とルーティングテーブルは、識別子と宛先の両方で一致している必要があり、どちらか一方が他方を提供するわけではありません。

IKEとESPをトンネルのルートから外す

XFRMデバイスへ向かうデフォルトルートは、カプセル化されたパケットと、それらが運ぶトラフィックの両方を捕まえます。結果はループです。ゲートウェイは、ESPが構築すべきトンネルを通して自分のESPを送ろうとします。

修正は、ピアの外側アドレスへのより具体的なルートを物理インターフェース経由で設定することです。より多くのビットに一致するため、デフォルトルートに勝ちます。複数のトンネルが一つのテーブルを共有する場合、マークベースのルーティングも同じ役割を果たし、strongSwanはルートベース展開向けに両方の手法を文書化しています。

どちらを選んでも、外側のパケットがカプセル化されずに出ていくことを確認してください。手早い確認は、トンネルが上がった後にピアの外側アドレスへpingすることであり、インターフェースが上がっているのに失敗するなら、到達性ではなく捕捉を疑ってください。同じ理屈がIKEポートにも当てはまります。デーモン自身のUDPトラフィックを、確立しようとしているデバイスへルーティングしてはならないからです。

暗号化を疑う前に二か所でカウンターを確認する

インターフェースのカウンターと状態のカウンターは別の段階を測ります。デバイスへルーティングされたパケットは、状態が一致しなくてもデバイスのカウンターを増やします。一方、状態のカウンターは実際にカプセル化されたトラフィックでしか動きません。

両方を読み、次にデーモンが子アソシエーションをどう見ているかを読みます：

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

状態の出力が空なのにデバイスのカウンターが増えているなら、ルーティングは機能していてポリシーが一致していません。通常は識別子かセレクターの誤りです。遠端が何も報告しないのに状態のカウンターが増えているなら、パケットは出ていくものの届かないか認証に失敗しており、経路かピアの設定を示します。一覧に出ている子アソシエーションのトラフィックがゼロなら、片端のセレクター問題であって、壊れた暗号ではありません。

ルートを誰がインストールするかを決める

一つのルーティングテーブルに二人の所有者がいることが、フラッピングの通常の原因です。デーモンがルートを自動でインストールするなら、ネットワークマネージャーも同じデバイス経由のデフォルトルートをインストールしてはいけません。また、起動スクリプトが追加した手動ルートは、次にデーモンが再設定するときに削除されます。

所有者を一人選んで書き留めます。デーモンがルートを所有する場合は、起動スクリプトをテーブルから外し、接続定義にトラフィックセレクターを記述させます。ネットワークマネージャーが所有する場合は、自動インストールを無効にし、再接続時にデーモンが欠けたルートを修復しないことを受け入れます。

転送とファイアウォールのルールはその上に別の判断としてあります。他のホストのトラフィックを通すゲートウェイには両方が必要だからです。ルートベースIPsecは、そのトラフィックを通常のルーティングツールで表現しやすくしますが、ポリシー層を任意にはしません。