「社内ファイアウォールの冗長化構成の導入」

FortiGateを冗長化する目的は、システム稼働中に問題が発生した場合でも停止時間を最小限に抑えながらシステムを継続稼働させることです。 FortiGateではHAの設定が冗長化構成に対応します。冗長化構成において、稼働している装置を「プライマリ」と呼び、待機している装置を「セカンダリ」と呼びます。 今回の記事ではプライマリとして運用するFortiGateをプライマリ機、セカンダリとして運用するFortiGateをセカンダリ機と表記します。
正常時はプライマリ機が稼働し、通信の制御を行います。一方、セカンダリ機は待機状態となり、通信に影響を与えません。 プライマリ機に問題が起こった場合には、フェイルオーバーが発生してセカンダリ機が動作するという仕組みです。 プライマリ機が正常に戻った場合はフェイルバックを行い、プライマリ機が動作するようにします。
さらに、冗長化の副次的なメリットとして、ファームウェアのアップデートが容易になることが挙げられます。 従来の1台構成では、アップデート時に再起動が必要となるため、その間は社内とインターネットの接続ができず、数十分の停止時間が発生していました。 冗長化構成では、アップデートを実行すると、まずセカンダリ機のアップデートが行われます。 完了後にフェイルオーバーを実施し、その後プライマリ機のアップデートが行われます。すべてのアップデートが完了後にフェイルバックを行います。

図1は冗長化構成を行ったネットワーク構成図を簡略化したものです。社内とインターネットの通信は赤字のルートを通り、FortiGateは通信の門番のような役割を担っています。

図1. FortiGate冗長化　ネットワーク構成図説明

分かりにくい部分について補足します。
FortiLink:AとBでは、2台のFortiGate同士をLANケーブルで接続し、冗長化構成に必要な通信を行っています。
WAN2は、異なるIPアドレスを設定し通信するためのポートです。 通常プライマリ機とセカンダリ機は同じ設定が適用されるため、正常時にIPアドレスで管理画面に接続するとプライマリ機の管理画面のみが表示され、セカンダリ機には接続できません。 そこで管理インターフェースの設定を行い、異なるIPアドレスを割り当てることで、社内ネットワークからプライマリ機・セカンダリ機の両方に接続ができます。

基本的な設定は「システム」→「HA」で設定します。

図2. HA設定画面

モード：アクティブ・パッシブとは、1台のFortiGateが稼働して、もう1台は待機する構成です。 別の設定としてアクティブ・アクティブ設定があります。この場合、セカンダリ機も常に稼働させることで冗長化に加えて負荷分散を行う事ができます。
ただし、FortiGateでは全ての通信が一度プライマリ機を通じてから処理される仕組みとなっているため、実際には負荷分散のメリットはそれほど大きくありません。 今回の目的はあくまで冗長化であるため、本構成ではアクティブ・パッシブとしています。
優先度の効果を上げる：ONにすると、デバイスのプライオリティの値が高いFortiGateがプライマリとして選択されます。 これにより、障害復旧後に元のプライマリ機へ戻すフェイルバックができるようになります。 この設定をOFFにすると、HA設定での稼働時間の長さを優先され、必ずしも元のプライマリ機に戻るとは限りません。

構成で説明した通り、WAN2には別のIPアドレスを設定しています。画面のように管理インターフェースの予約で設定可能です。

図3. 管理インターフェースの設定

これは大きく二つのメリットがあります。
一つは、接続先を明確にできる点です。
IPアドレスが共通の場合、管理画面に接続して「プライマリ機に接続している」と思っていても、実はプライマリ機は故障していて、セカンダリ機に接続しているという可能性があります。 その状態でメンテナンスのために電源を落としてしまうと、通信断などの問題に繋がる可能性があります。 もちろん管理画面の表示や実機のLEDランプを確認すれば判別できますが、人的ミスを防ぐためにも、接続先をIPアドレスで明確に区別できる構成を採用しました。
もう一つは、それぞれのFortiGateに対して個別にシャットダウンを実行できる点です。
社内サーバーなどは、停電時にUPSやその他のPCからシャットダウンを行う運用をしていますが、その時に2台のFortiGateそれぞれにシャットダウンコマンドを送る事ができます。

まずは実機を動かす前に情報収集から作業を始めました。 しかし、公式のドキュメントでは専門用語の説明が専門用語で書かれていたり、設定の説明はあるものの、明確な設定手順や実際の設定画面例がなかったりと、調査の段階から苦戦しました。 実機を動かして想定通りになった時に、「この設定はこの解釈であっていたのか」と安心することができました。 また、同じようにFortiGateで冗長化構成を構築した方が書いたブログ記事はとても参考になりました。本記事の最後にブログ記事のリンクを記載しました。

実際に社内環境に導入する作業は、社員がいない時間に実施する必要があります。稼働中のFortiGateをプライマリ機として運用したまま作業を行えば、通信障害を起こさずに作業ができますが、万が一のためです。幸いに水曜日はノー残業デーで18時には全員が退社するため、土日出勤はしないで済みます。
と思いきや、Web会議が長引いている社員がいたためその日は断念することになりました。事前検証を何回も行い、「自分のデスク上と同じ事をやればよい」という安心感もあったため、翌日のお昼休みに作業を実施しました。時間通りに進められるか少しヒヤヒヤしましたが、作業は問題なく進める事ができました。ただ、実際にサーバーラックで作業をしてみると、配線の多さに少し混乱しました。この時点で、「八戸事業所での作業は大変になるぞ」と思いました。

八戸事業所での導入では、サーバーラックでの機器配置と配線作業を現地の社員に依頼して、設定作業を本社事業所からリモートで行う方針としました。
とは言っても、八戸事業所のサーバーラックを管理している情報セキュリティ・インフラ整備推進室員は、FortiGateの仕組みについて詳しいわけではありません。そのため、専門知識がなくても安全に実施できるように準備を行いました。
具体的には、作業手順書を作成して、Web会議にて作業内容の説明を行いました。また、事前にサーバーラックの状態を確認してもらい、当日の作業内容について認識合わせを行いました。私自身、八戸事業所のサーバーラックを見たことがなかったので、ケーブルの接続位置や問題になりそうな点を現地で確認してもらいました。
機材とケーブルは本社事業所から発送しましたが、事前に必要な本数を用意してすべてにラベルを貼り付けることで、接続を間違えようがないように配慮しました。当日は電話をしながら実機の設置と配線をしてもらい、設定は本社事業所からリモートで行いました。
設定完了後には通信接続の確認を行い、最後にその場でフェイルオーバーが実際に発生することを確認して、作業完了としました。八戸事業所の社員にとっては、設定が正しく行われているか判断しづらいため、目に見える形で動作確認を行えた点は安心材料になったと思います。