NEW だけのファイアウォール規則はすべての WAN 経路を塞がない

WAN 上の新しい外向き接続を拒否する設定は、失敗時に閉じるポリシーのように見えますが、見かけより狭い約束です。すでに存在するフローに属するパケットはこれに一致せず、多くの応答も一致しません。この隙間が見落とされやすいのは、規則がインターフェースを覆うものとして読まれ、その上の一つの接続状態を覆うものとしては読まれないからです。状態一致を判定として読むことが、閉じているという誤った感覚を生みます。

状態は一致条件であり、判定ではない

コネクション追跡は、ファイアウォールがすでに見たものによってパケットを分類し、アプリケーションが信じているものによっては分類しません。双方向で観測されたフローは確立済みであり、その後のパケットは、下の経路がトンネルから通常の上り回線に変わっても確立済みのままです。受信接続への応答も確立済みのトラフィックになり得ます。それらのパケットが再び新規になることはありません。

だからこそ、新規接続だけを対象にした規則では、保護されたすべてのパケットが遮断されていることを示せません。他の状態は、規則セットの残りがそれらをどう扱うかに委ねられ、それはチェーンの前の方に置かれた許可である場合もあります。

規則を周囲とあわせて読む

遮断の前に置かれた、確立済みおよび関連トラフィックへの広い許可は、遮断が評価される前にパケットを通してしまいます。後ろの規則から状態条件を外しても、評価がそこに届かないので変わりません。結果を決めるのは順序であり、どのパケットがその順序に届くかを決めるのは状態一致です。

編集したファイルではなく、実際に効いている規則セットを、他のチェーンへのジャンプやプラットフォームが生成するものも含めて調べてください。iptables で管理されたルーターでは、チェーンを一覧表示すると規則の定義が表示され、それが参照するチェーンもたどる必要があります。ネイティブの nftables システムでは、ファームウェアが同一のチェーンを生成することはほとんどないため、独自の規則セットとフックの優先順位を調べる必要があります。

カウンターはどの規則が実際に一致したかを示し、通常は判定後に取ったパケットキャプチャより情報量が多くなります。カウンターがゼロの規則には、位置が何を示唆していても到達していません。

禁止を状態から独立して表現する

クライアント群がトンネルの外でインターネットに到達してはならないなら、一つの状態で近似するのではなく、そのまま書いてください。規則は接続状態に依存せず、送信元・出口・宛先で選択する必要があり、以前の許可に迂回されない場所に置く必要があります。そうすれば管理アクセスとローカルネットワークの例外はそれぞれ明示的な規則を持ち、意図がポリシー上で見えるようになります。

drop ではなく reject を選ぶと、一致したトラフィックの失敗の仕方が変わり、規則が選択するパケットの集合が広がるわけではありません。拒否された接続と無言のタイムアウトは、同じ選択を指す別の症状です。

WAN 越しに遠隔から開始されたアクセスへの応答を意図的に許可するポリシーは、擁護できます。ただ、トンネル経由だけの完全な分離として提示するのではなく、そのように説明する必要があります。

グループに実際に誰が入っているかを確認する

例が扱うのは、一つのインターフェースから一つのプレフィックスで転送される IPv4 トラフィックです。IPv6、二つ目の上り回線、ルーター自身が生成するトラフィックについては何も述べていません。DNS リゾルバーとして動くルーターは自身の上流クエリを送信し、それらは forward チェーンをまったく通りません。

その外に移った機器はポリシーではなく偶然に直接通信しているので、保護対象のクライアントが今も選択したプレフィックス内のアドレスを持っていることを確認してください。例外の設計を見直さずに遮断を LAN 全体へ広げると、自分の管理経路を失いがちです。

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

次に、古いフローを新しいフローの隣で試してください。新規の接続試行とすでに活動中の双方向転送は、この規則の下で異なる振る舞いをし、両方を試して初めて実際のポリシーが分かります。