The Social DorkがOPNsenseのホームファイアウォールを構築する方法

Eva Wong は テクニカルライター であり、 生粋の技術好き としてZimaSpaceで活動しています。ホームラボやオープンソースソフトウェア をこよなく愛する生粋のギークで、複雑な技術概念をわかりやすく、実践的なガイド にまとめることを得意としています。Evaは、セルフホスティングは難しいものではなく、楽しむものだと考えています。チュートリアルを通じて、初めてのNAS構築からDockerコンテナの使いこなしまで、コミュニティがハードウェアのセットアップをわかりやすく理解できるよう 支援しています。、初めてのNAS構築からDockerコンテナの習得まで。

ZimaBoard 2を使ったOPNsenseホームファイアウォールの構築を紹介してくださったThe Social Dork | サイバーセキュリティに感謝します。仮想マシンがルーティングとファイアウォールポリシーを担い、アクセスポイントがWi-Fiを提供し、Pi-holeが接続クライアント向けのDNSフィルタリングを行います。詳しいデモはYouTubeの元動画による解説をご覧ください。

読む前に視聴:ネットワークゲートウェイとワイヤレスアクセスポイントを分離したい方に役立つ、約10分の動画です。制作者がネットワーク構成を説明し、Zima Virtual MachineでOPNsenseを起動して、インターフェースとDHCPを設定した後、Wi-Fi接続したノートパソコンとDNSフィルタリングを確認します。

このデモで達成するのは、ノートパソコンを新しいファイアウォール経由でネットワークに接続し、選択したDNSフィルターを使うところまでです。動画では、最初の1台を接続する手順を紹介しています。脆弱なIoT機器に関する冒頭の問題提起に対処するには、ネットワークのさらなる分離とアクセス制御が必要です。機器を新しいSSIDに接続するだけでは、機器同士が隔離されるわけではありません。

既存のゲートウェイに残す役割を決める

ネットワーク構成の解説では、一体型ルーターでは見えにくい3つの役割を分けています。プロバイダーとの接続、ルーティングを担うファイアウォールの境界、そしてワイヤレスアクセスです。イーサネット接続は新しいファイアウォールにつなげられますが、DSLやケーブル回線では、適切なモデムまたはプロバイダー機器が引き続き必要です。ルーティング機能を置き換えても、物理的な接続が不要になるわけではありません。

制作者の実際の環境では、既存のホームルーターをファイアウォールのWAN側に接続し、そのLAN側にアクセスポイントを配置しています。上流のゲートウェイもネットワークアドレス変換を行う場合、二重NATになります。初期テストでは問題ないこともありますが、外部からの接続サービスやトラブルシューティングが複雑になる可能性があります。ブリッジモードやパススルーモードが使えるかどうかは、プロバイダーの機器やサービスによって異なります。本番環境の接続を変更する前に確認してください。

役割 図示された構成のコンポーネント クライアントを移行する前に確認すること
プロバイダーとの接続 イーサネット接続、または必要なモデム/ゲートウェイ。 接続を維持するために残しておく必要がある機器はどれですか?
ルーティングとポリシー OPNsense仮想マシン。 クライアントのトラフィックは実際にこのゲートウェイを経由していますか?
ワイヤレスアクセス 別途用意したアクセスポイント、または対応するAP構成。 クライアントを想定したLANにブリッジ接続していますか?
IPアドレスの割り当て クライアントネットワークで動作するDHCPサービスを1つにする。 ゲートウェイとDNSの設定を提供するのはどのサーバーですか?
DNSフィルタリング Pi-holeサービス。 そのクライアントは、選択したリゾルバーにアクセスできますか?

切り替え前に、現在のプロバイダー側の設定を書き留めてください。イーサネットで接続する動画を見ても、ISPの認証、VLAN、モデムの要件までは分かりません。新しい経路をクライアント1台でテストする間は、以前のゲートウェイ設定も使える状態にしておきましょう。これにより、上流サービスの問題と、新しいLANの設定ミスを切り分けられます。

ダブルNATとは、ルーティングとアドレス変換の境界が2つある状態を指します。下流にアクセスポイントがあるだけの場合とは異なります。無線機器が引き続きルーティングしていると、境界とDHCPサービスがさらに1つ追加される可能性があります。ケースの製品ラベルで役割を判断せず、実際の動作モードとケーブルの接続位置を確認してください。

仮想インターフェースを実際のWANとLANの境界に割り当てる

The Social DorkはOPNsenseのインストールイメージをダウンロードし、ZimaBoard 2上のZima Virtual Machineで起動します。これは仮想化ファイアウォールのデモです。ホストでは引き続きZimaOSが動作しているため、そのネットワーク構成も設計の一部であり、ゲスト内のOPNsense設定だけではありません。

同様の構成では、各仮想インターフェースを目的の物理ポートまたは分離されたホストネットワークに明示的に割り当ててください。ネットワークポートが2つあっても、その対応関係が自動的に決まるわけではありません。WAN側の経路を通常のホストサービスから分離し、LANクライアントの通信が上流接続に到達するには、必ずファイアウォールを通過するようにしてください。クライアントにVMを迂回する別の経路があると、ファイアウォールはその通信にポリシーを適用できません。

ゲートウェイ仮想マシン内でのOPNsenseのWANおよびLANインターフェース設定
作成者は、OPNsense内でWANとLANのインターフェースを割り当てています。ゲストの各インターフェースを目的の物理ネットワーク経路に対応させ、アドレスを確認してください。動画の5:25付近のフレーム。The Social Dork提供。

選択したイメージとプラットフォームに対応する最新のOPNsenseのインストール手順と仮想マシンのガイダンスを使用してください。インターフェースを変更する前に、ホストとVMコンソールへの接続方法を記録しておきましょう。ホストの再起動、ストレージの問題、VMのシャットダウンにより、このゲートウェイが中断する可能性があります。家庭内のネット接続への影響を考慮して、メンテナンスを予定してください。

インターフェースの構成を明確にする

  1. ホストの物理ポートを特定し、どのケーブルが上流接続につながっているか記録します。
  2. ゲストのWAN側インターフェースを、目的の上流ネットワークに割り当てます。
  3. LAN側インターフェースを、独立した下流ネットワークに割り当てます。
  4. 管理用経路や通常のホストサービスが、意図せずWAN側に公開されていないことを確認します。
  5. テスト用クライアントを1台下流に接続し、ほかのデバイスを追加する前に、実際のデフォルトゲートウェイを確認します。

ゲスト内のインターフェース名は、物理ポートの横に印字されたラベルと一致しないことがあります。ハイパーバイザーのネットワークマッピングとゲストコンソールを使って、対応関係を確認してください。仮想アダプターを変更した後も、もう一度確認しましょう。動画では作成者のマシンで動作する構成が紹介されていますが、遭遇しうるすべてのホストブリッジやアダプター設定を網羅しているわけではありません。

ホスト上のZimaOSやその他のサービスに余力を残しつつ、ファイアウォールにリソースを割り当ててください。最新のOPNsense仮想化ガイドでは、RAMの最小要件3 GB、仮想ディスクの推奨最小容量8 GB、ネットワーク互換性に関するガイダンスが示されています。これらは初期条件であり、スループットを保証するものではありません。ログ、VPN、検査機能、その他のワークロードによって、必要な余裕は変わります。

これは、1台のマシンを共有する場合の運用上のトレードオフです。ホストの更新や再起動によって、ゲートウェイVMも停止することがあります。VMを起動後にどう立ち上げるか、起動しない場合にどう復旧するかを決めておきましょう。ネットワーク設定を誤ってWebインターフェースにアクセスできなくなったときには、安定したコンソール接続が特に役立ちます。

各クライアントネットワークのDHCP管理は1つのサービスに任せる

作成者は上流と下流で異なるIPv4ネットワークを使用しています。上流側は192.168.0.xアドレス、クライアントLANは192.168.1.xアドレスを使用しています。これらは動画内の例です。すでに使われている可能性のあるアドレスをそのまま使うのではなく、自分のネットワークに合った、重複しないサブネットを選んでください。

アクセスポイントが無線接続を提供し、OPNsenseが下流クライアントにDHCPリースを割り当てます。この手順では、APモードと、以前使っていた無線ルーターのDHCPサービスを無効にする方法を説明しています。専用のAPモードがない機器では、DHCPを無効にするだけで透過的なアクセスポイントとして動作するとは限りません。メーカー指定のLAN-LAN配線とルーティング/NATの要件を確認してください。DHCPプールと競合せず、管理用アドレスにアクセスできる状態を保ってください。

動画内のOPNsense Dnsmasq DNSおよびDHCP設定
作成者が下流ネットワークのDHCPを設定しています。1つのサービスから、意図したクライアントアドレス、ゲートウェイ、リゾルバーが提供されていることを確認してください。動画の6:25付近の映像。The Social Dork提供。

作成したリースをノートパソコン1台でテストします。意図したLAN内のアドレス、ファイアウォールのLANアドレスをデフォルトゲートウェイ、意図したDNSサーバーとして取得できるはずです。Wi-Fiへの接続に成功しただけでは、無線接続が機能していることしか確認できません。アドレス、ゲートウェイ、リゾルバーを確認すれば、クライアントが実際に新しいネットワーク経路に接続できているかがわかります。

固定アドレスとリースプールを分けて計画する

以下は/24 LANプランの例であり、制作者が実際に使用したアドレスをそのまま記したものではありません。既存のネットワークに合わせて調整してください。固定のインフラ用アドレスは動的割り当てプールの範囲外に確保し、上流ネットワークと下流LANには異なるネットワークを使用してください。

項目 アドレスまたは範囲の例 理由
OPNsense LANインターフェース 192.168.1.1/24 クライアントはこのアドレスをゲートウェイとして使用します。
アクセスポイントの管理 192.168.1.2 例のプール範囲外に設定する、固定の管理用宛先。
到達可能なPi-holeエンドポイント 192.168.1.10 この例でクライアントに通知するDNSエンドポイント。
クライアント用DHCPプール 192.168.1.100–192.168.1.199 固定アドレスとの競合を避けるため、別のプールを使用します。

Pi-holeが実際には別のサブネット上、またはホスト側の仮想ネットワーク上にある場合は、実際に到達可能なエンドポイントと、必要なルーティングおよびポリシーを使用してください。例のアドレスを設定しただけでは、サービスがLAN上で利用可能になるわけではありません。DHCPエントリーはクライアントにリクエストの送信先を知らせるだけで、経路を確立したりサーバーを起動したりするものではありません。

OPNsenseのDHCPプールとDNSサーバーのフィールドを示すPi-hole公式ドキュメントの例
DHCPアドレスプールと、クライアントに配布されるDNSサーバーを示すOPNsenseとの公式連携例。アドレスは説明用です。出典:Pi-holeドキュメント。画像をクリックすると元のサイズで表示されます。

DHCPを変更した後は、サーバーの設定ページだけでなく、ノートPCのリースも確認してください。割り当てられたアドレス、マスク、ゲートウェイ、DNSエントリーを確認します。古いリースが残っているクライアントがあると、新しい設定が正しいのに動作していないように見えることがあります。予期しないアドレスやゲートウェイも、別のDHCPサーバーがまだ稼働していることを示す手がかりになります。

最初の許可ルールは接続テストとして扱う

制作者は、テスト用ノートPC 1台に対して、送信方向を許可する緩やかなルールから始め、WANからLANへの未承諾接続を防ぐ方法について説明しています。OPNsenseはステートフルフィルタリングを使用するため、許可された接続への応答は接続状態に基づいて処理されます。OPNsenseファイアウォールルールのドキュメントでは、インターフェース、方向、ルールの順序がその動作にどう影響するかを説明しています。

最初の接続テスト中のOPNsenseファイアウォールルールエディター
チュートリアルでは、テストクライアントの接続を確立するためにファイアウォールルールを編集します。ポリシーを広げる前に、インターフェース、送信元、宛先、目的を確認してください。The Social Dork提供の動画フレーム(7:40付近)。

この動画では、上流のプライベートネットワークからWebインターフェースを開いています。独自の環境では、管理アクセスを信頼できる管理経路に限定し、コンソールからの復旧手段を確保してください。WANというラベルは、このファイアウォールから見た役割を示します。上流のプライベートなラボ用セグメントとパブリックインターネットでは、外部への露出条件が異なります。

冒頭で挙げたIoTの懸念に対処するには、対応機器を使ってネットワークを分け、その間で許可するトラフィックを定義します。同じローカルセグメント内でトラフィックをやり取りするデバイスは、ルーティングされたファイアウォールを通らずに通信できる場合があります。ゲートウェイやプライバシーに関する判断を別の実例から確認するには、cachito labsのOPNsenseファイアウォール構築をご覧ください。

接続性と分離を切り分ける

ポリシーの目標 事前に満たすべき条件 検証方法
テスト用ノートパソコンでウェブを閲覧できます。 意図したゲートウェイとリゾルバーを使用しています。 許可された宛先に接続し、一致するフローを確認します。
IoTネットワークから信頼済みLANにはアクセスできません。 デバイスは別々のルーティングネットワーク上にあります。 選択したネットワーク間接続を試し、ポリシーを確認します。
クライアントは意図したDNSサービスを使用しています。 リゾルバーに到達でき、正しく通知されています。 クライアントの問い合わせをPi-holeのクエリログと照合します。
管理は信頼できる経路上で行います。 管理アクセスは、意図した送信元に限定されています。 認可された経路を確認しつつ、コンソールから復旧できる状態を保ちます。

ルールを追加する前に、送信元、宛先、プロトコル、目的を明確にします。あるノートパソコンがインターネットに接続できることを確認するルールは、家庭内のすべてのデバイスに適用するポリシーではありません。ネットワークを分離するには、別々のネットワークと、それらの間のファイアウォール経路を使用します。同じセグメント内でやり取りされるトラフィックは、ゲートウェイをまったく通らない場合があります。

ルールを変更しても効果がないように見える場合は、新しい接続でテストし、接続状態を考慮してください。OPNsenseルールガイドでは、ステートフル処理について説明しています。既存の状態が再テストに影響することがありますが、すべての状態をリセットすると、ほかのアクティブな接続が中断されます。広範な診断変更を行う前に、テスト対象のフローを特定してください。

DNSループを作らずにDHCP経由でPi-holeに接続する

終盤で、The Social DorkはDHCPで提供されるDNSサーバーをPi-holeのアドレスに設定します。これにより、先ほどのPi-holeとTailscaleによる広告ブロックプロジェクトを新しいワイヤレスネットワークに導入できます。OPNsenseはルーティングされるトラフィックの経路を制御し、Pi-holeはそのサービスを通じて要求されたDNS名を評価します。2つのコンポーネントの役割は異なります。

Pi-holeのDNS設定中に表示されたOPNsenseのDHCPオプションダイアログ
DHCPオプションの設定手順では、選択したDNSサービスをクライアントに通知します。保存済みのフォームだけに頼らず、クライアントのリースを更新してリゾルバーを確認してください。The Social Dork提供の動画の8:15頃のフレーム。

Pi-holeのOPNsense連携ガイドでは、DHCPによる直接配布と、ファイアウォール経由の転送を別々の構成として紹介しています。一貫した経路を選び、リゾルバー同士が互いにクエリを転送し合うループが発生しないようにしてください。また、Pi-holeが別のネットワークにある場合は、クライアントからPi-holeのアドレスにアクセスできることも確認してください。

OPNsenseの上流DNS設定に関する、Pi-hole公式の連携例
ここで説明する転送構成における、OPNsenseのDNS設定の公式例。出典:Pi-holeのドキュメント。画像をクリックすると、元のサイズで表示できます。

リゾルバーの経路を1つ選び、端から端まで図にする

構成 名前解決の経路 ログで確認できること
クライアントはPi-holeに直接問い合わせます。 クライアント → 到達可能なPi-holeエンドポイント → 選択した上流リゾルバー。 Pi-holeでは、実際に受信した送信元アドレスに基づいてリクエストを識別できます。
クライアントは転送を行うファイアウォールのリゾルバーに問い合わせます。 クライアント → ファイアウォールのリゾルバー → Pi-hole → 独立した上流経路。 Pi-holeからは、転送元のファイアウォールがリクエストの送信元として認識される場合があります。

動画では、DHCPでクライアントにPi-holeのアドレスを配布しています。リンク先の公式ガイドに記載されている転送構成は、別の方法です。こちらを選ぶ場合は、Pi-holeの上流DNSが同じ転送経路にリクエストを送り返さないようにしてください。経路が明確であれば、応答がない場合の原因をずっと特定しやすくなります。

DNSには、通信方式とルーティングへの依存関係もあります。クライアントとリゾルバーが異なるネットワークにある場合は、経路と、TCP/UDPポート53に関するポリシーを確認してください。実際の結果がDHCP設定と異なる場合は、IPv6のDNS通知と、クライアント側で個別に設定されたDNSも確認してください。Pi-holeのウェブインターフェースにアクセスできるだけでは、十分な証拠になりません。

外出先でもフィルタリングするには、関連するPi-holeとTailscaleの手順をご覧ください。リモートDNSアクセス、ローカルゲートウェイのポリシー、VPN経由ですべてのインターネット通信を送ることは、それぞれ別の選択です。実際に使用する接続で、それぞれをテストしてください。

すべてのデバイスを移動する前に、経路全体を確認する

最後のデモでは、ノートパソコンのWi-Fiネットワークを切り替え、フィルタリング設定の有無で同じウェブサイトを比較します。これは選択したクライアントの通信経路を示すものであり、すべてのウェブサイトに広告がないことや、すべてのデバイスが隔離されていることを証明するものではありません。まずインターネット接続とDNSを確認し、次に該当するファイアウォールとPi-holeのログを調べて、それぞれの結果が意図したクライアントに対応することを確認してください。

家庭内ネットワークを移行する前に、クライアントのリース更新、許可された接続、設計にセグメンテーションが含まれる場合は別々のネットワーク間で意図的に拒否される接続をテストしてください。動作するファイアウォール設定をエクスポートし、復旧手順を確認します。目指すのは、ルーティング、DHCP、フィルタリング、管理の仕組みを説明し、維持できるゲートウェイです。元のトポロジーと設定手順については、The Social DorkによるOPNsense家庭用ファイアウォールの完全ガイドをご覧ください。

段階的な受け入れテストを実施する

  1. 使用する無線ネットワークに接続し、新しいクライアントリースを確認します。
  2. デフォルトゲートウェイを確認し、適切な場合はIPアドレスを使った許可済みの接続をテストします。
  3. 選択したリゾルバーを通じて許可されたホスト名を名前解決し、クエリを確認します。
  4. 有効なPi-holeポリシーに含まれるドメインをテストし、期待どおりの応答を確認します。
  5. セグメンテーションを設定した場合は、ルーティングされた境界を越える接続について、許可される接続と拒否される接続をそれぞれテストしてください。
  6. クライアントを再接続するか、リースを更新し、意図した設定が復元されることを確認します。
  7. 計画したメンテナンス時間内に、常時稼働を任せる前にホストとゲートウェイVMの起動手順を確認してください。

ネットワークの順にトラブルシューティングする

症状 調査が必要と考えられるレイヤー 有用な証拠
想定したクライアントアドレスが割り当てられない。 APのブリッジ接続、ケーブル接続、DHCPインターフェース、または競合するDHCPサーバー。 リースと、そのリースを取得したネットワーク。
クライアントにアドレスは割り当てられているが、インターネットに接続できない。 ゲートウェイ、仮想インターフェースのマッピング、上流への接続、ルーティング、またはNAT。 ゲストのインターフェースの状態と、テストする通信。
IP接続は機能するが、名前解決に失敗する。 DNSのエンドポイント、ポリシー、リスナー、または上流リゾルバー。 明示的なDNSテストと、それに対応するリゾルバーログ。
拒否されたはずの接続がまだ使える。 誤ったネットワーク経路、ルールの適用範囲/順序、または既存の状態。 送信元/宛先アドレスと、該当する接続の状態。
ホストのアップデート後にネットワークが使えなくなる。 ゲートウェイVMの起動、またはホストのネットワークマッピング。 コンソールへのアクセスと、最後に正常動作したときのホスト/ゲストの設定。

ログを使って、一度に1つの疑問に答えましょう。OPNsense のファイアウォールのログ記録に関するドキュメントによると、ステートフルな通信では、パケットごとにライブログに新しい行が記録されるとは限りません。ファイアウォールの診断ガイドでは、状態を確認できます。ログに何も記録されていないことだけでは、ファイアウォールを通過した通信がないとは証明できません。

大きな変更を加える前に、動作する設定を保存し、明確なロールバック手順を用意しておきましょう。テスト中は、古い接続を別途利用できる状態に保ち、ファイアウォールを迂回して上流ネットワークと下流ネットワークが誤って接続されないようにしてください。有効なロールバックでは、クライアント側の設定とともに、動作確認済みのゲートウェイに戻します。同じクライアントセグメント内に、互いに競合するルーターを2台設置することは避けましょう。

よくある質問

ZimaBoard 2だけでWi-Fi無線機能を代替できますか?

この動画では、別のアクセスポイントがWi-Fiを提供しています。ボードは仮想化されたゲートウェイと関連サービスをホストします。ルーティングと無線アクセスは別々の役割です。

ISPのモデムを取り外せますか?

サービスの接続に必要なくなった場合に限ります。DSL、ケーブル回線、プロバイダー固有の構成では、元の終端装置が引き続き必要な場合があります。ゲートウェイを交換する前に、機器とサービスの要件を確認してください。

アウトバウンド通信を許可するルールでIoTデバイスを分離できますか?

ネットワークの分離にはなりません。同じローカルセグメント上のデバイス同士は、ルーティングされたファイアウォールを経由せずに通信できる場合があります。分離するにはネットワークを分け、その間のポリシーをテストする必要があります。

Pi-holeはOPNsenseの内部で動かすべきですか?

紹介されているプロジェクトでは、仮想化されたファイアウォールと併せてPi-holeサービスを使用し、そのアドレスをDHCP経由で通知しています。重要なのは、DNSへの経路が到達可能で一貫していることです。OPNsenseをインストールすれば、そのサービスも一緒にインストールされると思い込まないでください。

ファイアウォールVMに2つのネットワーク経路が必要なのはなぜですか?

ルーティング構成には、上流ネットワーク向けの経路と、そこから分離された下流ネットワーク向けの経路が必要です。ゲストとホストの対応付けを正しく行うことで、この境界を確立できます。アダプター名が2つ表示されているだけでは、ネットワークが分離されている証明にはなりません。

ZimaOSホストを再起動するとどうなりますか?

ゲスト用ファイアウォールやその他のホスト型サービスが利用できなくなる可能性があります。VMの起動と復旧を計画し、メンテナンス時間中に検証しましょう。ハードウェアを共有する構成では、ホストのメンテナンスもゲートウェイの可用性に影響します。

結論

The Social Dorkの構成が参考になるのは、一体型ゲートウェイの役割を、プロバイダーへの接続、仮想化されたルーティング、無線アクセス、アドレス割り当て、DNSフィルタリングという、理解しやすい機能に分けているからです。ノートPCで最初の接続テストに成功すれば、出発点としては十分です。継続的に運用するホームゲートウェイには、ネットワーク境界の検証、クライアントグループごとに適切なポリシー、復旧手段も必要です。

家庭内のネットワーク全体を切り替える前に、まず1台のクライアントで一連の確認を完了し、追加のネットワーク分割やVPNの動作は個別に検証してください。OPNsenseの動画解説を手元に置き、自分のインターフェース構成図や最新の公式ドキュメントと照らし合わせましょう。目指すべきは、動作を説明・テストでき、復旧もできるネットワークです。

Zimaキャンペーンハブ

続きを読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.