← 冗長構成（HA）Active/Passiveの設定 その1
前回に引き続き、HA構成について記載します。今回は、実際にHAを組んだ際の挙動や手動での切替方法について説明します。なお、今回はPA-445を使用しています。
設定関連
基本的に前回のブログと同じ内容の設定を行っていきますが、PA-445に併せて一部変更していることと、HA以外の設定（ポリシーやルーティング）についても記載します。
PA-445のHAインタフェースの設定
PA-400シリーズには専用のHAポートがありませんので、サービスポートにHAポートを割り当てます。今回は以下のように設定しました。
PAシリーズは、データプレーンとマネジメントプレーンは独立したプロセッサ（またはCPUコア）上で動作しています。仮にデータプレーンが過負荷になっても装置への管理アクセスなどはマネジメントプレーン側で処理しているので継続してアクセスが可能です。（他製品のように過負荷時にそもそも装置にログインできなくなると言った事象を防ぐことができます。）
前回の記事にて記載したようにHA1ポートは対向装置の死活監視を行なっていますので、データプレーンの負荷の影響でフェイルオーバーが発生することがないようにHA1をマネジメントプレーン上で動作するインタフェースに割り当てることが推奨されています。今回のPA-400などの専用のHA1ポートを持たない製品では、マネジメントプレーンに接続されている「MGTポート」をHA1メインポートとして共用します。
For firewalls without dedicated HA ports such as the PA-220 and PA-220R firewalls, as a best practice use the management port for the HA1 port, and use the dataplane port for the HA1 backup.
HA関連設定
PA-445のHA関連の設定を記載します。リンクモニタリングの設定はサービス系のインタフェースの設定を行なった後に設定します。
HAインタフェース設定（【NETWORKタブ】→【インターフェイス】）
サービス系のインタフェースの設定はまだ行なっていません。
【DEVICEタブ】→【冗長化設定】→【全般】
ピアHA IPアドレスは、MGTポートのIP（172.16.1.82と172.16.1.81）を指定します。
バックアップ側 ピアHA IPアドレスは前回同様です。
【DEVICEタブ】→【冗長化設定】→【HA通信】
HA1ポートに「management」が設定されています。MGTインターフェイスには初期セットアップ時にIPを設定していますのでここでの設定は不要になっています。
ここまで設定を行なってNGFW#1、NGFW#2の両方でCommitを行います。HA構成が組めているかダッシュボードで確認してみましょう。正常にHAが組めています。
その他の設定
その他の設定を行っていきます。HA構成を組んでいる場合、HA関連の設定やマネジメント系の一部の設定を除きコンフィグはHAにより同期されますので、設定はNGFW#1を対象に行っていきます。
インターフェイス設定
構成図にあわせてethernet1/2とethernet1/4の設定を行います。
ゾーンの設定
仮想ルーターの設定
スタティックルートで、デフォルトルートを設定しておきます。
セキュリティポリシー
Trust→Untrust向けの通信をすべて許可するポリシーを設定します。
NATポリシー
Trust→Untrust向けのNAPT設定用のポリシーを設定します。
Commitとコンフィグ同期
設定が完了したらNGFW#1でCommitを行います。Commit完了後、NGFW#2のコンフィグを確認するとコンフィグが同期されていることが確認できるかと思います。NGFW#1とNGFW#2の画面右下のタスクをクリックしてタスクマネージャを開いてみましょう。
NGFW#1では、1/15 06:59:18にCommitが完了していて、その直後の1/15 07:00:40に今度はNGFW#2sw「HAピアの同期」というタスクがで完了しています。
リンクモニタリングの設定（コンフィグ同期対象外）
先ほど設定していなかったリンクモニタリングの設定を行います。NGFW#1で以下のようなリンクモニタリングの設定を行いCommitを実施します。しばらく待ってからNGFW#2側のリンクモニタリングの設定も確認してみましょう。コンフィグは同期されていましたか？
NGFW#2側にはリンクモニタリングの設定は同期されていなかったはずです。前回の記事でも説明しましたが、これはリンクモニタリング（HA関連）の設定はコンフィグ同期の対象外となっているからです。このように一部の装置固有の設定についてはHA構成でコンフィグ同期が有効になっていても同期されませんので注意してください。
NGFW#2側でも上記のNGFW#1と同じリンクモニタリングの設定を行いCommitします。ここまでで、設定の準備ができましたので実際に動作確認を行っていきます。
HAの動作確認
切替などの動作確認を行なっていきます。
セッション同期
【DEVICEタブ】→【高可用性】→【HA通信】→【データリンク】→【HA2】→【セッション同期を有効にする】でセッション同期を有効にしていますので、セッションの状態を確認します。クライアントPCから以下の通信を行いながら、「show session all」コマンドで2台のNGFWのセッション状態を確認します。
- 1.1.1.1宛のPing
- www.yahoo.co.jp宛のhttps通信
【NGFW#1】
admin@PA-445-1(active)> show session all filter state active
--------------------------------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
2763 ping ACTIVE FLOW NS 192.168.45.100[14049]/Trust/1 (172.16.1.83[14049])
vsys1 1.1.1.1[1]/Untrust (1.1.1.1[1])
2757 ping ACTIVE FLOW NS 192.168.45.100[14047]/Trust/1 (172.16.1.83[14047])
vsys1 1.1.1.1[1]/Untrust (1.1.1.1[1])
2755 ping ACTIVE FLOW NS 192.168.45.100[14045]/Trust/1 (172.16.1.83[14045])
vsys1 1.1.1.1[1]/Untrust (1.1.1.1[1])
2760 ping ACTIVE FLOW NS 192.168.45.100[14048]/Trust/1 (172.16.1.83[14048])
vsys1 1.1.1.1[1]/Untrust (1.1.1.1[1])
2756 ping ACTIVE FLOW NS 192.168.45.100[14046]/Trust/1 (172.16.1.83[14046])
vsys1 1.1.1.1[1]/Untrust (1.1.1.1[1])
2754 ping ACTIVE FLOW NS 192.168.45.100[14044]/Trust/1 (172.16.1.83[14044])
vsys1 1.1.1.1[1]/Untrust (1.1.1.1[1])
2758 dns-base ACTIVE FLOW NS 192.168.45.100[55224]/Trust/17 (172.16.1.83[28039])
vsys1 8.8.8.8[53]/Untrust (8.8.8.8[53])
2759 ssl ACTIVE FLOW NS 192.168.45.100[40928]/Trust/6 (172.16.1.83[26892])
vsys1 182.22.25.252[443]/Untrust (182.22.25.252[443])【NGFW#2】
admin@PA-445-2(passive)> show session all filter state active
--------------------------------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port])
Vsys Dst[Dport]/Zone (translated IP[Port])
--------------------------------------------------------------------------------
13511 dns-base ACTIVE FLOW NS 192.168.45.100[55224]/Trust/17 (172.16.1.83[28039])
vsys1 8.8.8.8[53]/Untrust (8.8.8.8[53])
13512 ssl ACTIVE FLOW NS 192.168.45.100[40928]/Trust/6 (172.16.1.83[26892])
vsys1 182.22.25.252[443]/Untrust (182.22.25.252[443])
コマンドの結果を確認すると、通信を処理していないPassiveのNGFW#2（PA-445-2）に「dns-base」と「ssl」のセッションが同期されていることがわかります。このようにして、セッション同期設定を行っておくことで、フェイルオーバー時にActiveになったNGFWでも既存のセッションを引き継いでパケットを処理することが可能です（そのセッションが継続できるかどうかは、クライアントPCとサーバー側の通信に依存します）。なお、pingはセッション同期されません。
手動でのフェイルオーバー
GUIでの操作
手動でフェイルオーバーを発生させる場合はActive機をSuspendにします。NGFW#1の【DEVICEタブ】→【高可用性】→【操作コマンド】で、「Suspend local デバイス for high availabillity」をクリックします。
確認のポップアップが表示されるのでOKをクリックします。
NGFW#1のステータスが「🔴 Suspended」になり、NGFW#2が「🟢 Active」になりました。
通信も復旧しました。
このままActive機がSuspendの状態のままだと、切り戻せませんので状態を元に戻します。NGFW#1の【DEVICEタブ】→【高可用性】→【操作コマンド】画面を見ると表示が「Make local デバイス functional for high availability」になっているのでクリックします。表示が「Suspend local デバイス…」に戻ります。
NGFWのステータスを確認すると、NGFW#1が「🟠 Passive」、NGFW#2が「🟢 Active」になっています。（Preemptiveを有効にしていないため自動的に切り戻ることはありません。）
CLIでの操作
今度はCLIを利用して状態を戻してみましょう。やることは先ほどと同じで、NGFW#2側をSuspendしてFunctionalにするだけです。利用するコマンドは、「request high-availability state suspend」と、「request high-availability state functional」の2つです。
admin@PA-445-2(active)> request high-availability state suspend
Successfully changed HA state to suspended
admin@PA-445-2(suspended)>
admin@PA-445-2(suspended)> request high-availability state functional
Successfully changed HA state to functional
admin@PA-445-2(initial)>
admin@PA-445-2(passive)>NGFW#1(PA-445-1)がActiveに昇格します。
admin@PA-445-1(passive)>
admin@PA-445-1(active)>リンク障害によるフェイルオーバー
続いてリンク障害によるフェイルオーバーを確認します。
NGFW#1のeth1/2のケーブルを抜去すると、リンクモニタリングにより障害が検出されNGFW#1は「🔴 Non-functional」になり、その通知を受けたNGFW#2が「🟢 Active」になります。
eth1/2のケーブルを再接続します。NGFW#1が「🟠 Passive」になります。
このようにHAを構成することが可能です。最後に
パス モニタリングの設定と動作の確認
パスモニタリングの設定と動作の確認も行ってみます。パスモニタリングはリンクダウンを伴わない障害を検出するためにPing監視を行う機能です。パスモニタリングはActive機によって実施されます。今回、構成上適切な宛先がなかったので以下の設定で確認します。
- NGFW#1 → 1.1.1.1
- NGFW#2 → 8.8.8.8
パスモニタリングの設定
NGFW#1で【DEVICEタブ】→【高可用性】→【リンクおよびパスのモニタリング】→【パスグループ】で、「仮想ルーターパスの追加」をクリックします。
追加ボタンをクリックして、以下の設定を行います。
- 名前：default
- 宛先IPグループ：1.1.1.1
- 宛先IP：1.1.1.1
NGFW#2側も同様に設定します。
動作確認
NGFW#1（Active側）にCLIでログインして「show high-availability path-monitoring」コマンドを入力します。デフォルト設定では、Pingの送信間隔は200msで10回失敗するとNon-functionalとなります。
【NGFW#1】
admin@PA-445-1(active)> show high-availability path-monitoring
--------------------------------------------------------------------------------
total paths monitored : 1
hold time to send probe packets : 1000 ms
(after device becomes active)
--------------------------------------------------------------------------------
grp/name/type destination suc/total rtt min/max/avg (ms) probe cnt/interval(ms)
--------------------------------------------------------------------------------
1.1.1.1/default/virtual-router 1.1.1.1 10/10 7.55/69.83/14.45 10/200
--------------------------------------------------------------------------------NGFW#2（Passive側）はパスモニタリングを行いませんのでN/Aになっています。
【NGFW#2】
admin@PA-445-2(passive)> show high-availability path-monitoring
--------------------------------------------------------------------------------
path monitoring statistics unavailable due to inactive device state
total paths monitored : 1
hold time to send probe packets : 1000 ms
(after device becomes active)
--------------------------------------------------------------------------------
grp/name/type destination suc/total rtt min/max/avg (ms) probe cnt/interval(ms)
--------------------------------------------------------------------------------
google/default/virtual-router 8.8.8.8 N/A N/A N/A
--------------------------------------------------------------------------------上位に設置したFWでログを確認してみます。NGFW#1が1.1.1.1に対してPingを行っていることがわかります。また、送信元IPはHAで設定した仮想IP（172.16.1.83）になります。
上位のFWで、1.1.1.1宛のPingをブロックして動作を確認してみます。NGFW#1が「🔴 Non-functional (Path down)」になり、フェールオーバーが発生します。
CLIでも確認してみます。NGFW#1がnon-functionalになっています。
【NGFW#1】
admin@PA-445-1(non-functional)> show high-availability path-monitoring
--------------------------------------------------------------------------------
path monitoring statistics unavailable due to inactive device state
total paths monitored : 1
hold time to send probe packets : 1000 ms
(after device becomes active)
--------------------------------------------------------------------------------
grp/name/type destination suc/total rtt min/max/avg (ms) probe cnt/interval(ms)
--------------------------------------------------------------------------------
1.1.1.1/default/virtual-router 1.1.1.1 N/A N/A N/A
--------------------------------------------------------------------------------【NGFW#2】
admin@PA-445-2(active)> show high-availability path-monitoring
--------------------------------------------------------------------------------
total paths monitored : 1
hold time to send probe packets : 1000 ms
(after device becomes active)
--------------------------------------------------------------------------------
grp/name/type destination suc/total rtt min/max/avg (ms) probe cnt/interval(ms)
--------------------------------------------------------------------------------
google/default/virtual-router 8.8.8.8 10/10 4.84/14.96/6.79 10/200
--------------------------------------------------------------------------------その後の動作
この状態でしばらく（1分）待つとどうなるでしょうか？
・・・NGFW#1は「🔴 Non-functional」から「🟠 Passive」になっています。これは、NGFW#1がNon-functionalになったことで1.1.1.1へのパスモニタリングが実行されなくなったためです。
それでは、この状態で8.8.8.8宛のPingもブロックしたらどうなるでしょうか？
- ActiveのNGFW#1は機器は1.1.1.1へのパスモニタリングを行いますが失敗して「🔴 Non-functional」になりフェイルオーバーします。
- 今度は、passiveのNGFW#2が「🟢 Active」になり、8.8.8.8へのパスモニタリングを開始しますが失敗します。本来であれば、ここで「🔴 Non-functional」に移行するのですが、Monitor Fail Hold Down Time (1分間)の間、NGFW#1のステータスが「🔴 Non-functional」のままになりますので、NGFW#1も「🟢 Active」まま待機します。
- NGFW#1はActiveではありませんので、リンクモニタリング機能が動作していません（＝つまりリンクモニタリングに失敗していない状態です）。そのため、復旧に向けて状態を遷移します。ちょうどNGFW#2も「🔴 Non-Functional」なるところですので、Passiveではなく「🟢 Active」になろうとしますが、上述の通りタイマーが動作しますので1分間待機します。
- 1分後、NGFW#1は初期化状態（initial）を経由して「🟢 Active」になり、NGFW#2はパスモニタリングに失敗しているので、「🔴 Non-functional」に移行します。
- この動作（いわゆるフラップ）を3回繰り返します。そして4回目にNGFW#1がパスモニタリングに失敗すると、Flap Maxカウント（3回）を超えるため、NGFW#1のステータスは「🔴 Suspended (Non-functional loop detected)」状態になり、ここでフラップが止まります。
【NGFW#1】
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🔴 non-functional)>
---- 1分待機 ----
admin@PA-445-1(initial)>
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🔴 non-functional)>
---- 1分待機 ----
admin@PA-445-1(initial)>
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🔴 non-functional)>
---- 1分待機 ----
admin@PA-445-1(initial)>
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🟢 active)> (モニタ失敗）
admin@PA-445-1(🔴 Suspended)> 【NGFW#2】
admin@PA-445-2(🟠 passive)>
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🔴 non-functional)>
---- 1分待機 ----
admin@PA-445-2(initial)>
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🔴 non-functional)>
---- 1分待機 ----
admin@PA-445-2(initial)>
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🟢 active)> (モニタ失敗）
admin@PA-445-2(🔴 non-functional)>
---- 1分待機 ----
admin@PA-445-2(initial)>
admin@PA-445-2(🟢 active)> (モニタ失敗）このようにリンクモニタリングやパスモニタリングを利用した場合、障害の状況によってはフラップが発生することがありますので注意してください。
コメント欄 質問や感想、追加してほしい記事のリクエストをお待ちしてます！