【資格】ネットワークスペシャリスト 平成26年 午後Ⅰ 問2のファイアウォールの仕様だとかを整理してみる
概要
ネットワークスペシャリスト 平成26年 午後Ⅰ 問2のファイアウォールの問題が何だかよくない気(俗に言う違和感)を発しているので、整理しながらこの気の発生源を突き止めてみる。
問題文から読み取れるFWの仕様
問題文から、FWの仕様に関する記述のみ抜粋する。私が想像したことはそれと分かるように記載している(つもり)。
- Z社では、FW1を主系に設定し、FW2を副系に設定したActive-Standby冗長構成を採用し、運用を行っている。
- 通常時、FWは、必ず主系がActive動作になり、副系がStandby動作になる仕様である。
- FW間にはフェールオーバリンクと呼ばれる専用接続があり、設定情報の同期、管理情報の複製、及び対向FWのの動作状態の識別に使用されている。
- FWの冗長化機能は、仮想アドレスを使用する方式ではなく、主系のIPアドレス及びMACアドレスを副系が引き継ぐ方式である。
- 新たにActive動作となったFWは、切り替わったことを通知するフレームをFWはの各ポートから送信する。FWに接続しているスイッチは、このフレームを受信することで、レイヤ2機能で用いるテーブルを適切に更新することができる。
- 疑問1: こんなフェールオーバ通知機構があってよいのだろうか？
- 周囲の機器の実装に期待している？例えば、FWがフラッディングしたフレームを、ARPテーブルを持つノードが受信する→MACアドレステーブル上で、フレームを受信したポートに紐付いているMACアドレスを上書きする→MACアドレステーブル上で書き換えられたMACアドレスを、ARPテーブル上でも新しいMACアドレスに書き換える、的な……。そんなわけないか。問題中でもGrauitous ARPを引き合いに出しているということは、純粋にMACアドレステーブルしか更新しないんだと思う。
- (追記)「FWの冗長化機能は、仮想アドレスを使用する方式ではなく、主系のIPアドレス及びMACアドレスを副系が引き継ぐ方式」だから、フェールオーバしてもゲートウェイとして提供するIPアドレスとMACアドレスは変わらない。つまりフェールオーバした時にFWが通知する必要があるのは「自身のインタフェースの方向」だけだから、Gratuitous ARPはいらない、ということだと一晩寝たら気づいた。今回の障害は主系設定のFWを交換したからFWのMACアドレスが変わってしまったことによる、周囲のARPエントリとの不一致。「Gratuitous ARPだったらこんなこと起きなかった」だけであって、通常のフェールオーバにおいてもGratuitous ARPが必要だったかというと、そんなことはない(Gratuitous ARPのほうがベターだとは思う)。
- 疑問1: こんなフェールオーバ通知機構があってよいのだろうか？
- Active動作のFWを副系から主系に切り戻すためには、手動設定が必要である(=プリエンプションしない)。
- 起動時にフェールオーバリンクによって、他のActive動作中のFWを認識すると、主系又は副系であるかにかかわらずStandby動作に入る。このとき、FWは自己の設定情報を無視して、Active動作中のFWから設定情報を同期する。
- 疑問2: 「起動時」とは「起動プロセス中」のことか？起動プロセスが終わった後のことか？それとも双方を含むのか？
障害発生の流れ
FW1が故障してから、U君がやらかして障害発生、解決するまでの一連の流れを、事後の調査で判明した原因も含めてまとめる。なお、問題文中では交換が済んだあたりから代替機をFW1と呼んでいるが、この記事では一貫して故障したFW1を「FW1」、代替機を「代替機」と呼ぶことにする。ただし、問題文を引用する際はその内容に準ずる。
- FW1が故障したので、FW2にフェールオーバする。この時点でFW2は副系設定かつActive。
- FW1の結線を外してからアンマウントする。
- 代替機(工場設定のまま=主系設定)をマウントし、結線する(しかし、SW2との接続ができておらず)。
- 代替機に電源投入。フェールオーバリンクが確立されていないので、現在ActiveのFW2の存在を認識できず、代替機もActiveでブートする。
- 少し経ってからSW2のFW1接続ポートのLEDが消灯していることに気づき、挿し込む。リンクアップを確認(=FW間のフェールオーバリンクが確立)する。
- 疑問3:「少し経ってから」とは、代替機の起動プロセス中か？それとも起動プロセスが終わった後か？
- FW2は代替機の存在を認識し、Standbyへ移行する。同時に代替機の設定情報を自身に同期する(=Z社のフィルタリングルールを含む設定情報が失われていた理由)。
- 疑問4: 代替機もFW2の存在を認識したのに、Standbyにならないのは何故か？
- 障害発生。苦情相次ぐ。
- 代替機とFW2の設定を確認、Z社のフィルタリングルールを含む設定情報が失われていることを確認する。
- FW1の設定情報を復元(とってあったFW1の設定情報のバックアップを代替機に投入？)し、FW2に設定情報を同期(手動？)するも、障害復旧せず。
- 事故の原因を特定して通信を回復(=周辺機器のARPテーブルをクリア)した。障害復旧。
根本原因
障害復旧後に作成された「表1 FW故障時の交換作業手順」を見るに、FW1が故障した場合の手順の最初に「代替機の主系設定が解除されていることを確認する」とある。障害復旧後の事実確認においては「FW1が主系設定であったので…」の文言があるため、そもそもの原因は「代替機が工場出荷状態のままであり、工場出荷状態では主系設定になっている」ことが原因であると言えそう。
L2SW(SW2)の存在意義
障害発生の契機はU君が半挿しのケーブルをカチッとしてしまったことだが、これはあくまで契機であって原因ではない。「あってよかったSW2！」ということにもなっていない。フェールオーバリンクが確立しているかどうかだけであればFW間を直接接続していても分かるわけで、やはりSW2の存在意義はフェールオーバリンクが落ちている時に、SW2のポート状態からどちらのFWのポートが落ちているか(=故障しているか)を判断できる、ということのみであると言えそう。そんなことのために障害ポイント増やすかね？
主系と副系、ActiveとStandby
主系「設定」という言葉が問題文中にあることから、主系と副系には何らかの設定差異があることが分かる。単なる呼び名(奇数系と偶数系的な)や、それに基づく「もともと」Activeであるノードかどうか、だけではなさそう。起動時に主系設定だったら他のActive機を探して、いなければ自身がActive機になる。いればStandby機になる。ただし、疑問2と疑問4で提起している通り「起動時」の定義はあいまい。一方、起動時に副系設定だった場合は、Active機が存在するかどうかに関わらずStandby機になり、Active機がいたらその設定情報を自身に同期する。たぶん。
所感
「起動時」の定義とか「Dual-Activeの時の挙動」の定義がグダグダなんだと思う。CiscoのASAの挙動と酷似しているという情報もいただいたが、ごめんなさいもう眠くて何も考えられません。
