チェーン名はフックではない：iptables と nftables

どちらのファイアウォールも転送される VPN トラフィックを絞り込めますが、パケット経路へのルールの付け方は異なります。iptables ではテーブルの中に組み込みチェーンがあり、FORWARD は名前付きのフック点として存在します。nftables はチェーンの名前を型・フック・優先度から切り離すため、FORWARD という名前の通常チェーンは何も絞り込みません。両モデルを比べると、一方のツールで正しく見える記述が他方で効果を持たない理由が分かります。

チェーンは入れ物です。カーネルがそれを参照するかどうかは実装と、ルールセットがどう結び付けるかで決まります。

二つのモデル、二つの結び付け方

iptables では filter テーブルに三つの組み込みチェーン INPUT、FORWARD、OUTPUT が付いており、-N はユーザー定義チェーンを作ります。これはそれらのいずれかからジャンプされたときだけ効果を持ちます。一方 nftables のマニュアルは、型・フック・優先度を宣言するベースチェーンと、それらを持たない通常チェーンを定義します。ベースチェーンは好きな名前を付けられ、FORWARD という名前の通常チェーンはラベルから何の性質も得ません。違いはこれだけであり、ルールの文面だけを示す入門記事では見えません。

互換バックエンドは、コマンド名から挙動を推測すべきでない二つ目の理由になります。iptables の文書は iptables-nft の下で異なる操作を記しており、ネイティブ nftables、iptables-nft、旧来のルールセットは一つの綴り違いではなく三つの系統として扱うべきです。

エラーを実際の文脈で読む

テーブルの欠落、権限の失敗、利用できないカーネル機能、名前付きチェーンの欠落は四つの異なる所見であり、チェーンに関わるのは一つだけです。ツールの版、要求したアドレスファミリとテーブル、ネットワーク名前空間、最初の正確なエラーを記録します。次に、どの構成要素がルールセットを所有しているかを確認します。ファイアウォールサービスや製品が管理するゲートウェイは自前のチェーンと順序を生成することがあります。それらの隣にネイティブなチェーンを足しても管理ポリシーは変わらず、棚卸しはさらに混乱します。

コンテナの名前空間はホストと異なるルールセットを持てるため、誤った文脈で実行したコマンドでは、転送パケットをどのチェーンが見たのか分かりません。期待したチェーンが見えないからと権限を上げるのは診断ではありません。

カウンタが示すのは到達であり、判定ではない

ルールのカウンタは、そのルールに到達したことを示します。後続のルールが操作を許可したことや、代替経路がすべて拒否されたことは示しません。無害な許可済みフローを一つ流している間に、ルール順序とチェーンの結び付きと併せて読み、判定ではなく一つの観測として扱います。drop ルールのカウンタがゼロでなければ通信がそこに当たったという意味で、当たらなかった通信については何も語りません。

カーネルの IP 転送はまったく別の設定です。チェーンが存在しても転送は有効にならず、見慣れたラベルがないからといって転送が止まったわけではありません。

守りたいフローを書き出す

カプセル化解除後のクライアント要求を一つ書き出します。送信元、宛先、アドレスファミリ、ゲートウェイで終端するのか通過するのかです。ローカルサービスの入力と転送トラフィックは観測点が異なるため、別のルールと別の試験が必要です。ブリッジ型 VPN ではブリッジ経路も確認します。IP 層のチェーンはイーサネットフレームを自動では監視しないからです。

遠隔ゲートウェイを変更する前に、独立した復旧手段を確保します。そのうえで同じルールセットの下で、意図したフローと必要な拒否を確認します。見慣れた名前の新しい空のチェーンは修復ではありません。

比較は一つの問いに帰着します。このパケットに対してカーネルが実際に呼ぶフックはどれか。それに答えれば、チェーンの名前は問題ではなくなります。