IPsec ポリシーがローカルトラフィックを飲み込む：見分け方

机の上のプリンターはトンネルが上がった瞬間に応答を止めますが、トンネルの設定にはプリンターの記載がありません。よくあるのは、保護範囲がプリンターを含むほど広く書かれていたことで、マシンはローカルセグメントに残るべきトラフィックまで暗号化しようとしています。インストール済みのポリシーを読めばこの取り込みが説明でき、正しい場所で狭めればリモートのトラフィックは保護されたままです。失敗した要求から一致するポリシーまでの道のりは数分です。

セレクターを変える前に流れをたどる

失敗した要求から始めて、マシンが使う送信元アドレス、正確な宛先、カーネルが選ぶルート、その組に一致するポリシーの四つの値を書き出します。

この四つの事実が、取り込みが意図的か偶発的かを決めます。リモートセレクターの内側に入る宛先は設計どおり保護されており、設計が誤っていても同じです。その外側なのに取り込まれる宛先は、別の何かが一致しているということで、セレクターを変えても解決しません。どちらもよくあることで、一つのコマンドで区別できます。

何かを編集する前にこれを行うのは、興味深いのが、接続が保護するプライベート範囲と重なるローカルサブネットの場合だからです。192.168.0.0/16 のような身近なプレフィックスは多くのネットワークに現れ、そのどれか向けに書かれたセレクターがあなたのものを静かに覆うことがあります。

振る舞いの異なる三種類のローカル

このホストに割り当てられた宛先、同じリンク上の宛先、別のインターフェースの向こうにある宛先は、三つの異なるケースです。カーネルはトラフィックに保護が必要かどうかを決めるとき、それぞれを別に扱います。

ゲートウェイ自身が生成するトラフィックも、クライアントから転送されるトラフィックとは同じではありません。転送トラフィックには正しく見えるポリシーが、ゲートウェイ自身の管理セッションを捕まえることがあり、管理者はトンネルを直している最中にアクセスを失います。

役に立つ習慣は、このパケットは自分から出るのか、自分のリンクへ向かうのか、自分を通り抜けるのか、とケースを声に出して名付けることです。答えごとに絞り込む場所が変わります。ケースを書き留めておけば、次の人が同じ作業をやり直さずに済みます。

保護範囲がプライベート空間全体だと、三つのケースが同時にその中に入り、症状はトンネルの端点以外どこにも届かないマシンになります。

ファイルではなくインストール済みポリシーを読む

設定ファイルは意図を書き、カーネルは実際に一致するポリシーを保持しています。両方を表示し、不一致を最初の発見として扱います。

次のコマンドは宛先に選ばれたルートと、各方向にインストールされたポリシーを表示します：

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

ルートはパケットが使うインターフェースを教えてくれます。ポリシー一覧はそのパケットにテンプレートが適用されるかを教えてくれます。接続一覧はデーモンがどのセレクターを入れたと思っているかを示し、宛先がリモートセレクターにあれば、推測せずに取り込みを特定できます。

セレクターを狭めるか、宛先を迂回する

対応する修理は二つあり、それぞれ別の問いに答えます。セレクターを狭めるのは、この接続がより小さな範囲だけを保護するという意味で、広い範囲が誤りだった場合に正しい選択です。迂回を追加するのは、この特定の宛先を決して保護しないという意味で、保護範囲が本当に広く、一つの宛先だけが例外である場合に正しい選択です。

できるなら前者を選びます。小さいセレクターのほうが考えやすく接続定義にも現れるので、広い範囲が意図的で、例外が名前を挙げられる単一のホストやサブネットなら後者を選びます。

どちらも接続を所有する設定に属します。手で追加した実行時ルールは次の再接続で消え、誰もその回避策を覚えていないタイミングで障害が戻ります。

再インストールに耐える例外

変更後に同じ無害な要求を繰り返し、同じカウンターを見ます。ローカルの宛先は応答し、意図したリモートの宛先は暗号化されたトラフィックを示したままであるべきです。

この二つの確認で、例外が生き残り、保護が失われていないことが分かります：

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

その後、意図的にトンネルを切断して再接続し、両方をもう一度行います。再接続の前には効き、後で失敗する例外は間違った層に適用されており、これがこの問題の最も一般的な再発経路です。