VPN の NAT を UFW の before.rules のどこに置くか、そしてテスト方法

シェルに入力すれば動く NAT ルールも、before.rules に貼り付けると失敗します。このファイルはスクリプトではなく、テーブルセクション、チェーン宣言、各テーブルの COMMIT マーカーを持つリストア形式の文書だからです。誤った位置の行は、リストア全体を中断させるか、存在すると思っていたルールを黙って落とします。以下の手順は、フレームワークが期待する場所に断片を置き、次の再読み込みの前に結果を証明します。

シェルコマンドはリストアファイルではない

iptables -t nat で始まる行は iptables バイナリへの指示であり、UFW が読むファイルは完全なルールセットの記述です。違いは見た目ではありません。リストア形式は、どのテーブルにいるのか、どのチェーンが存在するのか、テーブルがどこで終わるのかを知らなければなりません。その文書に貼り付けたコマンドは、構文エラーか、さらに悪ければ誤ったテーブルに付いたルールになります。フレームワークがこれらのファイルをリストアツール経由で読み込むのは、まさに逐次型ではなく宣言型だからです。

文書は全体として読み込まれるため、ひとつの不正なセクションが残りの適用を止めることがあります。したがって NAT 断片の小さな誤りがフィルタルールも巻き込み、ファイアウォールの変更が障害になるのです。

既存のテーブルセクションの内側に断片を置く

NAT 断片には形があり、形は中のルール文よりも重要です。テーブルヘッダーがセクションを開き、チェーン宣言がカウンタを設定し、ルールが続き、COMMIT がセクションを閉じます。

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

上のプールとインターフェースは自分の値のためのプレースホルダーです。コピーする価値があるのは構造です。ファイルにすでに *nat セクションがあるなら、二つ目を開くのではなくそのセクションの中にルールを追加してください。形式はテーブルごとに一つの COMMIT を想定しており、同じテーブルに二つのセクションがあれば、いずれ起きる修正待ちになるからです。ディストリビューションのチェーン定義はそのまま保ち、ベンダーが独自の統合のために追加したものも含めてください。UFW フレームワークのマニュアルは before、user、after の各ファイルと、対応する COMMIT の要件を記述しています。

ファイルが空だったとしても、チュートリアルで埋めてはいけません。どのパッケージが所有しているのか、実際のライブポリシーは何なのかを確認してください。空の永続ファイルはカーネルにルールがないことを証明せず、読み込まれたルールセットは次の再読み込みに完全なファイルがあることを証明しないからです。まずサポートされたベースラインを復元し、その上にサイトの変更を再適用します。

適用せずに候補をテストする

リストアツールは適用せずにルールセットを解析して構築できます。これが最も安価なテストです。ライブファイルではなく保護されたコピーに対して実行し、終了ステータスだけでなくエラーテキストを読んでください。解析の失敗は行と通常はテーブルを示すので、失敗した再読み込みが教えてくれるより多くのことが分かります。

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

その検査に通ることは、文書が解析できることを証明するだけで、それ以外は何も証明しません。候補が UFW の依存するすべてのチェーンをまだ含むこと、意図した送信元だけを許可すること、遠隔管理が到達可能なままであることは証明しません。それらは別々のレビューであり、最後のものは開始前に開く二回目のセッションに値します。

インストールされたバックエンドとアドレスファミリーに合うツールを選んでください。互換レイヤー経由で nft バックエンドを動かすホストには対応するコマンドが必要で、IPv6 のルールはまったく別のファイルにあります。

転送、NAT、アクセスポリシーを分けておく

送信元変換はアドレッシングの問題を解決するだけで、何も許可しません。転送は sysctl とフィルタテーブルで制御される別の許可であり、トンネルが経路を選んでもトラフィックが通らないときに人々が忘れるものです。アクセスポリシーは、どの送信元がどのサービスに到達できるかという三つ目の決定であり、どの NAT ルールもそれを表現しません。この三つを分けておくことが、一つの漠然とした症状ではなく診断可能な障害にします。

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

これら三つの出力は一つずつではなく一緒に読んでください。転送が無効な masquerade ルールは、接続はするが何にも到達しないクライアントを生み、クライアント側からは経路障害にしか見えないため、人々を誤ったファイルへ導きます。フィルタテーブルは、広すぎる accept が隠れる場所でもあるので、そこにいる間に既定のポリシーも確認してください。

再読み込み、拒否、VPN 喪失を検証する

三つの観察が完全な受け入れテストになります。再読み込みが成功し、許可されたクライアント操作が機能し、拒否されるべき要求が実際に拒否されることです。三つ目こそが飛ばされるものであり、ポリシーが何かをしている唯一の証拠です。

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

次に、設計した失敗を試します。トンネルを落としてホストがどうするかを見てください。VPN が上がっている間だけ機能するポリシーは、宣言されていない依存を持つポリシーだからです。その後にもう一度再読み込みして、残った実行状態ではなくファイルが機能する結果を生むことを証明します。

IPv4 の NAT は IPv6 について何も語らないので、両方のファミリーの想定範囲をルールと同じメモに記してください。目標は一貫した管理されたポリシーであり、たまたま解析できた断片はその証拠ではありません。