単一のインターネット回線からの脱却
6ヶ月前、私たちのオフィスは限界に達していました。ピーク時のZoom会議中にメインの光回線が瞬断するたびに、チーム全員の業務が止まってしまったのです。ビジネスにおいて、1本のケーブルの不調が全業務の停止につながるというリスクは、避けるべきものです。大手ベンダーのエンタープライズ向けSD-WANソリューションは99.99%のアップタイムを謳っていますが、年間2,000ドルのライセンス料は小規模なチームにとっては痛い出費です。
そこで私は、pfSenseとポリシーベースルーティング（PBR）を使用して、独自のSD-WAN代替環境を構築することにしました。本番環境で2四半期運用してきましたが、安定性は抜群です。500Mbpsのメイン回線と200Mbpsのサブ回線という、2つの手頃なビジネス用光回線を組み合わせることで、総スループットの向上と、さらに重要なシームレスなフェイルオーバーを実現しました。このセットアップは、高額なサブスクリプションの罠に陥ることなく、SD-WANの主要な機能を再現しています。
ハードウェアと初期環境
ハードウェアには、少なくとも3つの物理ネットワークインターフェースが必要です。LAN用に1つ、それぞれのWANプロバイダー用に2つです。私は、Intel i226-V 2.5GbE NICを4ポート搭載したファンレスのミニPCを使用しました。このチップは、安価なRealtek製カードに見られるドライバーの不安定さがなく、高速ルーティングを処理できるため、pfSense構築では定番の選択肢です。
プロのヒント：ISPに連絡して、モデムをブリッジモードにするよう依頼してください。これにより、VPNやVoIPを阻害する「二重NAT」という悪夢を回避できます。もし拒否された場合は、pfSenseのWANインターフェースに静的なプライベートIPを割り当て、そのIPをモデムのDMZに設定してください。理想的ではありませんが、機能はします。
ゲートウェイとモニタリングの設定
システムは、接続がいつ切断されたかを正確に把握する必要があります。System > Routing > Gatewaysに移動してください。2つのWANが表示されますが、デフォルトのモニタリング設定は不十分です。ISPのローカルゲートウェイにのみpingを送信するため、実際のインターネット接続が死んでいても、そのゲートウェイ自体が生きていることがあるからです。
私は、パブリックDNSサーバーを「炭鉱のカナリア」として使用することを好みます。WAN1には8.8.8.8（Google）、WAN2には1.1.1.1（Cloudflare）を使用します。pfSenseがこれらの特定のIPに到達できない場合、その経路が本当に断絶していると判断できます。
# 推奨されるモニタリング設定
WAN1 (光回線 A): モニター 8.8.8.8
WAN2 (光回線 B): モニター 1.1.1.1デフォルトの感度のままにしないでください。Advancedの設定で、レイテンシのしきい値を250msに、パケットロスを10%に設定しました。光回線で10パケットに1パケットのロスが発生し始めたら、ユーザーがラグに苦しむ前に、システムが即座にその接続を切り捨てるようにしたいからです。
ゲートウェイグループの作成：SD-WANの心臓部
ここからが本番です。System > Routing > Gateway Groupsに移動します。ニーズに応じて2つのシナリオを作成します。
1. ロードバランスグループ
WAN1 and WAN2の両方をTier 1に設定します。両方が同じ階層（Tier）にある場合、pfSenseは負荷を分散します。500Mbpsの回線が2本あれば、オフィスは実質的に1Gbpsのパイプを手に入れることになります。万が一、一方の回線が工事などで切断されても、もう一方のTier 1回線が即座にトラフィックの100%を引き継ぎます。
2. フェイルオーバーグループ
2本目の回線が低速で従量制の4G/5Gバックアップである場合に使用します。高速な光回線をTier 1に、セルラーモデムをTier 2に設定します。pfSenseは、光回線が完全にダウンしたときにのみ、その高価なセルラーデータ通信を使用します。
ポリシーベースルーティング：トラフィックの誘導
グループを定義しただけでは不十分です。pfSenseにそれらを実際に使用させる必要があります。Firewall > Rules > LANに移動し、主要な「Allow」ルールを編集します。Advanced Optionsの下にあるGatewayまでスクロールし、「Default」を新しく作成したLoadBalanceGroupに変更します。
銀行などのセキュリティが厳しいサイトは、セッション中にIPが切り替わることを嫌います。「セキュリティ上の理由」で即座にログアウトされてしまいます。これを解決するには、System > Advanced > Miscellaneousに移動し、Sticky Connectionsを有効にします。これにより、現在のセッションが終了するまで1つのデバイスが同じWANに固定され、煩わしいログインループを防ぐことができます。
マルチWAN環境でのDNS処理
DNSは、多くのマルチWANセットアップにおける「サイレントキラー」です。メインのWANがダウンし、DNSがその回線に紐付いている場合、バックアップ回線が生きていてもインターネットが「壊れている」ように感じられます。System > General Setupに移動し、DNSサーバーを特定のゲートウェイに明示的にマッピングします：
- 8.8.8.8 -> WAN1_Gateway
- 1.1.1.1 -> WAN2_Gateway
この簡単なステップにより、どちらか一方のプロバイダーが生きている限り、チームはドメイン名を解決し続けることができます。
6ヶ月後の結果
今やStatus > Gatewaysページは、私が最も頻繁にチェックするダッシュボードです。リアルタイムのRTT（レイテンシ）とジッターが表示されます。スタッフから「接続が遅い」という苦情があった場合、通常、ISP-Bのレイテンシが150msに跳ね上がっていることが確認できるため、手動でその回線を切り離し、全員をよりクリーンな回線に強制的に移動させることができます。
フェイルオーバーのテストでは、4K動画のストリーミング中にメインのWANケーブルを物理的に引き抜いてみました。動画は正確に3秒間バッファリングされた後、再生を再開しました。ほとんどのVoIP通話は一瞬途切れましたが、切断されることはありませんでした。これこそが、金曜午後の締め切りを救うパフォーマンスです。
より詳細な分析には、ntopngパッケージをインストールしてください。各WANでどのワークステーションが帯域幅を占有しているかを正確に把握できます。これを構築したことで、数千ドルのライセンス料を節約できただけでなく、ネットワークの完全な可視化を実現できました。建物に2つのインターネット回線が来ているなら、両方を活用しない手はありません。
