ファイアウォールのパッケージは入ったのに、再起動でルールが消えた

パッケージはきれいにインストールされ、ルールもテストされたのに、次の再起動のあとゲートウェイは大きく開いていました。処理のどこも失敗しておらず、失敗は何が残るかという前提にありました。ファイアウォールのツールを入れること、残すべきルールを決めること、正しい時点で復元することは、三つの別の作業です。

症状が実際に語っていること

再起動で消えるルールセットの原因は、何も保存しなかった、別の何かが置き換えた、依存するものより先に復元した、の三つのどれかです。前の二つは設定を見れば分かりますが、三つ目は順序にしか現れません。だから再起動はデータ損失に見えても、実際には順序の問題なのです。

まず再起動の前に、どのサービスがルールを保持していたのか、起動時にどのファイルやデータベースを読んでいたのか、その保存元に書き込みが行われたことがあるのかを書き出します。誰も保存していない稼働中のルールセットは、妥当な説明であり最もよくあるものです。

パッケージの再インストールから始めてはいけません。

使う前に永続化ツールを読む

Debian のツールは永続化をプラグインの問題として扱い、各プラグインが自分のルールの書き方を知っていて、一つのラッパーがそれらを呼びます。保存の操作はその時点で読み込まれているものをすべて記録し、起動の操作はそのスナップショットを読み戻します。どちらの操作も、何を保存しているかを確認しません。

それはスナップショットであって、レビューではありません。デバッグ中に残った許可、途中で終わった実験、別の補助ツールが入れた緩いルールは、残したかったポリシーと一緒にすべて恒久的になります。状態を保存することと状態を承認することは別の行為で、判断が要るのは片方だけです。まず読み込まれている集合を読み、そのうえで残す価値のある行を決めてください。

何が読み込まれているかを読んだうえで、意図して保存します。

何を残すべきかを決める

インターフェースのライフサイクルに属するルールは、それと一緒に消えるべきです。トンネルより長く残る必要があるものもあり、最も明確な例は、トンネルが落ちたときに クライアントの通信が物理インターフェースへ戻ることを禁じる 制限です。この二つの分類には別の復元トリガーが必要で、共通のスナップショット一つでは足りません。

三つの時点、つまり起動、VPN の有効化、トンネルの喪失について意図した結果を書きます。次に、選んだツールがそれぞれを表現できるかを確かめます。静的なスナップショットを読み直すだけの永続化パッケージは最初の一つを扱えても、スナップショットはトンネルの状態がいつ変わったかを知らないため、残りは扱えないかもしれません。表現できないなら、その隙間は別のコンポーネントに属します。

答えを決めるのはパッケージではなくポリシーです。

復元の順序を確認する

ファイルを復元することは、結果を所有することと同じではありません。別の管理機構がルールを置き換えることも、以前の許可がそれらを覆い隠すことも、制限が効く前にクライアントが送信を始めることもあります。保存ファイルの有無だけでなく、起動時と再接続時の振る舞いを確認してください。

systemctl status netfilter-persistent
iptables -S

永続化サービスの停止が無害だとは考えないでください、パッケージは停止時に条件付きのフラッシュを行うと明記しているからです。遠隔で管理しているゲートウェイで停止や再起動を実験として使う前に、そのサービスの実際の設定を確定させてください。コンソールセッションと記録されたロールバックが、その試験の最低条件です。

順序は動いているシステムの性質であり、ディスク上のファイルの性質ではありません。

三つの結果を別々に受け止める

パッケージのインストール、読み込まれたルールセット、適用されたポリシーを別々の事実として記録します。サポートのやり取りに出てくるパッケージ名が答えるのは最初の一つだけで、それはめったに重要になりません。

nft list ruleset

そのうえで、許可される操作と要求される拒否を試します。

拒否が再起動のあとも、トンネルが落ちたあとも保たれるなら、ポリシーは生き残っています。どちらか一方の状態でしか保たれないなら、直したのではなく順序の問題を見つけたことになります。