Firewall、次に NAT、次に Outbound を開き、何かを追加する前にモードを読んでください。Automatic モードでは、pfSense が WAN インターフェース用のルールを生成し、その中にリモートアクセス VPN ネットワーク用のルールも含まれるため、追加しようとしているプールは多くの場合すでにカバーされています。手書きの行がないことは、変換がない証拠にはなりません。以下の順序なら、一つのプールを解決するためにファイアウォール全体を Manual に切り替えずに済みます。

モードは、装置上の他のすべてのネットワークについて誰が変換を維持するかを決めるもので、VPN の例外一つより大きな判断です。

Automatic モードはすでに VPN プールをカバーしている

各モードには別の管理者がいます。Automatic は WAN インターフェース用のルールを生成し、リモートアクセス VPN ネットワークをそのソースに含めます。Hybrid は生成されたルールを保持し、その横に手動のルールを追加できます。Manual は何も生成しなくなるため、ファイアウォール上のすべての変換が、自分が書いていないものも含めて自分の責任になります。四番目の設定では外向き NAT が完全に無効になります。手書きに見える行は、どのモードが有効かを知るまで何も証明しません。

Automatic と Hybrid では、ページに生成されたルールも表示されます。VPN プールに変換がないと結論する前にそれらを読み、ソース列でプールのネットワークを、インターフェース列で WAN インターフェースを探してください。

Hybrid はレビュー済みの例外にだけ選ぶ

外向きポリシーが本当に異なる場合、文書化された例外はなお可能です。10.90.0.0/24 を配布するサーバーを想像してください。ファイアウォールは IPv4 のインターネット出口を提供し、ルーティングはすでに WAN を選んでいます。期待される変換は、送信元 10.90.0.23 を WAN アドレスに書き換えることです。生成されたルールがその出口で既にそうしているか確認し、そうでなければ Hybrid は自動カバレッジを保ったままレビュー済みのルールを追加します。

送信元には実際の VPN プール、またはそれに対するサポートされたエイリアスを使い、OpenVPN インスタンス名が選択肢にないからといって無関係なアドレスを選ばないでください。any の送信元は避けてください。ファイアウォール自身が生成する通信も変換してしまいます。

一つのプールのためにファイアウォール全体を Manual に移さないでください。その判断は、すべての内部ネットワークと将来のすべての WAN 変更の保守を再割り当てします。

NAT は出口を選ばない

出口インターフェースを選ぶのはルーティングです。外向き NAT ルールは、パケットが出た後に送信元がどう書き換えられるかだけを記述します。WAN 向けのマッピングは、ルーティングが別の場所へ送ったパケットを WAN に強制するものではないため、NAT を追加しても誤ったルートは直せません。適用される 1:1 NAT のエントリと例外も確認してください。順序が重要で、新しい行が必ず勝つとは限りません。また、外向きのページはフィルターのページではありません。

変換された送信元は、あらゆる宛先に到達する許可ではありません。クライアントにはトンネルを通るルートと、その通信を許可するファイアウォールルールが依然として必要で、選ばれた出口には機能する戻り経路が必要です。LAN のみのアクセスはインターネット出口の許可と分けてください。

新しい接続で変換を証明する

承認された変更の後は、既存の接続を再利用せず、新しく許可された接続でテストしてください。確立された状態は以前の変換を保持するためです。実際に WAN を出る送信元アドレスと、応答が同じ状態を通って戻ることを確認します。最初の一手として状態テーブル全体をフラッシュしないでください。どのルールが結果を変えたかが見えなくなります。変更チケットにモード、ルール、プール、出口を記録してください。

この例は IPv4 の出口だけを扱います。IPv6 の変換やフィルタリングポリシーには何も触れておらず、それが必要な設計は別途明示する必要があります。完成した記録には、許可されたクライアント通信、それを運ぶインターフェース、そして送信元をそもそも書き換える必要がある理由を列挙します。

関連記事