読者です 読者をやめる 読者になる 読者になる

befs_anneの日記

インフラエンジニアとして多少マシになっていく記録(予定)

【資格】ネットワークスペシャリスト 平成26年 午後Ⅰ 問2のファイアウォールの仕様だとかを整理してみる

資格 IPA ネットワークスペシャリスト

概要

ネットワークスペシャリスト 平成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のほうがベターだとは思う)。
  • 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にならないのは何故か?
      • 他のActive動作中のFWを認識すると、「主系又は副系であるかにかかわらずStandby動作に入る」はずなので、代替機もStandbyにならなきゃおかしい。
      • 疑問1における「起動時」が「起動プロセス中」を指していて、この時点では代替機の起動プロセスが完了しているから?→だとしたらFW2も完了しているので、両方Activeのままなはず……。
      • 実はフェールオーバリンク上でアップタイムをやり取りしていて、Dual-Activeの場合は両機のアップタイムを比較して一定以上差がある場合短いほうはActiveのまま、みたいな裏設定が存在する?→問題文に書いとけよIPAナニコラタココラ。
  • 障害発生。苦情相次ぐ。
  • 代替機と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の挙動と酷似しているという情報もいただいたが、ごめんなさいもう眠くて何も考えられません。

フェールオーバーの設定 - Cisco Systems