空のVPNテーブルはそれ自体では何も遮断しない

ポリシールールはマークされたパケットを専用のテーブルへ送りますが、VPNルートを失えば遮断されると考えるのが普通です。しかし仕組みは別のことをします。テーブルに一致するルートがない場合、検索は次のルールへ続きます停止するのではなく、mainテーブルには通常のuplink向けデフォルトルートが残っています。その結果は、fail-closedに見えてfail-openに振る舞う設定です。

壊れているわけではなく、ポリシールーティングはそう規定されています。

テーブルに何もないとき検索は続く

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

このルールセットでは、マークされた検索はテーブル42へ進み、後のルールが同じマークをdefaultという名前のテーブルへ送ります。テーブル42に使えるデフォルトルートがある間は、最初の検索が経路を提供します。そのルートが消え、テーブル42のほかに何も一致しないと、検索は破棄にはならず、処理は次のルールへ進み、それも何も見つけなければmainテーブルに到達します。その流れのどこにも、どのルールが最終的な答えを出したのかは報告されず、動いている接続は動いているポリシーのように見えます。

慣例的にdefaultと呼ばれるテーブル253は通常のルーティングテーブルで、ふつうは空です。その名前はパケットを破棄する指示ではなく、テーブル内のデフォルト宛先ルートとも同じものではありません。

終端アクションは検索を終わらせる

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

空のテーブルへの検索の代わりに、VPN検索の後へ終端ルールを置けます。同じマークで、テーブル42のルールの後に置いたprohibitアクションは、そのテーブルが何も返さないときに検索を終わらせ、mainテーブルに別の機会を与える代わりに管理上の拒否を返します。unreachableとblackholeも終端で、送信者に対するエラーの挙動が異なります。

throw型のルートは異なり、そのテーブルの中では何も一致しなかったかのように振る舞うため、後のルールには順番が回ってきます。だからthrowは意図的なフォールバックには役立ち、最終的な遮断としては誤りです。

実際のマークとインターフェースで検証する

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

図ではなく実際のルールとテーブルを調べ、そのフローが本当に持つ送信元・マーク・入力の文脈で問い合わせます。宛先に向けた読み取り専用の検索に送信元アドレス、インターフェース、マークを与えると、パケットを出すことなくカーネルが選ぶルートを報告します。問い合わせにマークを与えても、ファイアウォールが実際の通信にマークを付けている証明にはならず、それはマーク付けのルールの別の確認です。問い合わせから結論を出す前に、カウンターやログで値を確かめてください。

ローカルで生成される要求には、そのマーク付けの経路が転送される通信の経路としばしば異なるため、独自の文脈が必要です。アプリが実際に使う出力インターフェースで確認してください。

二つの障害状態、一つではない

一つの障害状態は、VPNルートが消えて通信がuplinkへ落ちることです。ルートが残ったままの死んだトンネルは別の状態で、パケットは落ちずに使えない経路へ向かい続け、症状は目に見える直接接続ではなく静かな損失です。両方をテストし、起動、再接続、サービス停止の挙動もテストしてください。

そのようなルールは、存在し、パケットがそれを選ぶマークをまだ持つ間だけ役立ちます。ルールを削除するシャットダウンスクリプトや、マークをはがす経路は、開いた挙動を復活させます。そうした遷移は練習する価値があります。

ポリシーはIPv6に別途適用し、承認済みのエンドポイント例外は暗黙ではなく明示的に保ってください。