トンネル経由で 10.20.0.5 に ping しても何も戻ってこないのに、ルーティングテーブルはそのサブネットに到達できると言い張っています。ルーティングと IPsec は別の問いに答えるもので、到達性に関わるのは片方だけです。転送ルックアップが経路を選び、次にセキュリティポリシーデータベースがその経路を保護すべきか、そのままにするか、拒否するかを決めます。両者が食い違うとパケットは静かに死ぬので、この順序で読んでください。

テーブルではなくルックアップから始める

カーネルが実際に何をするかを尋ねます:ip route get 10.20.0.5 は選ばれたルート、出力インターフェース、使用する送信元アドレスを表示します。プレフィックス、ポリシールール、マーク、優先送信元のいずれもその答えを変えうるので、目でテーブルを読むより実際のルックアップが勝ります。

保護範囲の内側の宛先を試し、ゲートウェイのアドレスは試さないでください。反対側のゲートウェイに届くことは、何らかのルートが存在する証明にすぎず、実際に必要なサブネットについては何も語りません。次に、ルックアップが選んだインターフェースがトンネルに使わせたいものかを確認します。

両側でセレクタを一致させる

ポリシーデータベースには独自のエントリがあり、それぞれが方向、送信元、宛先、プロトコルを指定し、一致するパケットをどう扱うかを述べます。一覧表示には ip xfrm policy を使います;フラグは動作が保護か、バイパスか、ブロックかを示します。セレクタがテストフローより広い、あるいは狭いポリシーはそれに一致せず、パケットは保護されないまま出ていきます。探しているのはその障害であり、欠けたルートではありません。

実際の値を比較します:送信元、宛先、プロトコル、ポートです。ルックアップが一つのアドレス対を解決したのにポリシーエントリが別の対をカバーしているなら、二つの見え方は別のトラフィックを語っています。結論を出す前に同じタプルで両方を再実行してください、さもなければ、経路に存在しなかったポリシーを編集することになります。

ポリシーの一致はインストール済みの状態ではない

一致したポリシーはパケットを保護すべきだと言うだけで、保護を実行するにはカーネルにセキュリティアソシエーションがまだ必要です。ip xfrm state で一覧表示し、strongSwan が交渉する場合は swanctl --list-sas で表示して、各エントリのセレクタとカウンタを読んでください。

ポリシーが一致し、同じセレクタをカバーするアソシエーションがない場合、パケットは平文で送られるのではなく破棄されます。トンネルは上がっているのに一つのサブネットだけ失敗するときに探すべき破棄はこれです。カウンタが残りを語ります:まったく増えないアソシエーションは一度も選ばれておらず、増えているのに破棄で終わるものは遠端を指しています。セレクタの修正と鍵の再生成は別の修理なので、設定に触る前にどちらが必要か決めてください。

ルートベースのトンネルにまだ必要なもの

XFRM インターフェースはトンネルをルーティングできるデバイスのように見せます、これは本当に有用です。ただし、パケットがそこに届いた後に何が起きるかを決めるポリシーとステートをなくすわけではありません。ルートが与えるのはネクストホップだけです。

デバイスが存在し、ルートがその中を指しているのに、内部セレクタに一致するアソシエーションがない場合、パケットは破棄され、どれだけルートを編集しても鍵やセレクタは生まれません。ルーティングしたのと同じ送信元と宛先でインターフェースを確認し、それをステート一覧と比べてください。

何かを編集する前に所有権をはっきりさせる

ホストのファイアウォールは、どちらのデータベースも知らない第三の判断を加えます。正しいルートと一致するポリシーとインストール済みのアソシエーションがそろっていても、破棄されたパケットで終わることがあり、アプリケーションはタイムアウトだけを報告します。IPsec を責める前に、ファイアウォールが保護対象のトラフィックを許可しているか確認してください。トンネルデバイスと物理インターフェースでキャプチャすれば、暗号化のどちら側でパケットが消えたかがわかります。

設定の所有権が、修正が再起動後も残るかどうかを決めます。あるコンポーネントがステートをインストールし、別のコンポーネントがルートを管理していることがあり、後者への手作業の編集は次にトンネルが上がるときに上書きされます。所有する設定を変更し、それから両方の見え方を読み直してください;RFC 4301 は、その分割を他の誰かに説明する必要があるときに二つのデータベースを別々に保ちます。

関連記事