ネットワークスペシャリスト 2015年 午後1 問02

解答の論理構成

1. [ア] の導出
   • 問題文には「“LBの仕様には、1秒当たりの転送データ量である ア が記載されている。”」とあります。
   • 「1秒当たりの転送データ量」を表す一般的な性能指標は “スループット” です。
   • よって [ア] は「スループット」になります。
2. [イ] の導出
   • 続けて「“しかし、LBには1秒当たりの転送 イ 数に上限があるので、実際の最大 ア は転送パケット長によって変化する。”」とあります。
   • データ量（スループット）がパケット長で変わる理由は、装置が処理できる単位が “パケット数／秒” で決まっているからです。
   • 従って [イ] は「パケット」となります。
3. [ウ] の導出
   • 新NWではFWを “③3台構成” のActive-Activeにし、セッション情報を同期しない方式が採用されています。
   • そのため「“現行NWのActive-Standby構成と異なり、新NWでは、FWの故障発生時にセッションウができない。”」とある通り、途中で経路が変わるとセッションを保持できません。
   • ここには “維持” が入ると文脈が成立します。
   • よって [ウ] は「維持」になります。

誤りやすいポイント

• 「1秒当たりの転送データ量」を “帯域” と誤記しやすいですが、帯域は理論的なリンク速度、スループットは実際に処理できる量という違いがあります。
• [イ] を “フレーム” や “セッション” としてしまうと、パケット長によるスループット変動の説明がつきません。
• Active-Activeであっても同期機能付きFW製品も存在するため、[ウ] を “切替” と誤解しがちです。本問では同期しない前提なので “維持” が正解です。

FAQ

解答の論理構成

1. 端末間通信の基本はTCPコネクションです。問題文には「(A)、(B)は、機器aと機器bとの間のTCPコネクション上のパケット」とあり、両パケットともアプリケーションの宛先は「機器b」です。したがって宛先IPアドレスは両方とも機器bになります。
2. IP層より下位（L2）の転送は、ロードバランサ（LB）がFW負荷分散用にMACアドレスを書き換えます。根拠は【問題文】の引用「①FWはセッションの終端ノードではないので…LBは、FW宛てのイーサネットフレームに対し、宛先MACアドレスを振り分け先FWのものに書き換えて転送する。」です。
3. さらに、「②LBaとLBbによるパケットの振り分けは、FWでの動的フィルタリングが正しく行われるように実行される」「LBは、セッション単位で振り分け先FWを決定する。」とあるため、同じTCPコネクション内では常に同一FWを通過しなければなりません。
4. 本設問では「このTCPコネクション上のパケットはFW2を経由する。」と明示されています。ところが図2の (A) はFW1 → LBa方向、(B) はFW2 → LBa方向を示しており、(A) は “誤ったFW1へ送られたパケット” を表現しています。LBaはFW2へ送るべきところをFW1へ誤配送したため、FW1宛てのMACアドレスに書き換えられた状態で流れている、というシナリオです。
5. 以上より
   ・宛先IPアドレスはいずれも「機器b」。
   ・宛先MACアドレスは (A) がFW1、(B) がFW2。
   となります。

誤りやすいポイント

• IPとMACの層を混同し、「FWへ転送する＝宛先IPもFW」と誤解する。LBが書き換えるのは「宛先MACアドレス」だけであり、IPヘッダは変更しません。
• 「FW2を経由する」ので (A)(B) ともMAC＝FW2と早合点する。図2の (A) 矢印は“誤配送例”である点を見落としやすいです。
• TCPセッション維持の要件「セッション単位で振り分け先FWを決定」を読み飛ばし、送信方向ごとに異なるFWを選べると思い込む。

FAQ

解答の論理構成

1. 問題文の事実確認
   • 本文には「①FWはセッションの終端ノードではないので、FWの負荷分散では、パケットに対して行える操作に制約があり」とあります。
2. “セッションの終端ノードではない” とは
   • FWは透過装置としてレイヤ4までの動的フィルタリングを行い、通信の送受信元ホストとは別の中継装置です。
3. 制約の内容を具体化
   • サーバ負荷分散で一般的な「仮想IPアドレスを用いる方式」は、LBが受信パケットの宛先IPを“仮想IP”に書き換え、サーバ側で元のIPに戻す方式ですが、FWではこの書き換え後に正しくステートフル検査ができなくなります。
4. 結論
   • よって、FW向けパケットについてLBが行えるのはMACアドレスの書き換えのみで、宛先IPアドレスは変更できない、という点が制約になります。
   • 模範解答「宛先IPアドレスを書き換えられない。」はこの理由から導かれます。

誤りやすいポイント

• 「セッション終端ではない＝L4以降を見られない」と誤解し、ポート番号の書き換え不可と答えてしまう。実際にはFW自身がL4まで検査するためポート番号を参照するが、LBがIPを書き換えるとセッション管理が崩れる点が本質です。
• MACアドレス書き換えは“透過モード”の機能であり禁止事項ではない。MACではなくIPを対象にする設定と混同しがちです。
• DNSラウンドロビンやホストルーティングなど他方式の可否を答えてしまい、設問が求める“パケット操作の制約”から外れるケース。

FAQ

解答の論理構成

• 【問題文】では、FWが「レイヤ4までの動的フィルタリング」を行うと記載されています。動的フィルタリングは通信の状態をFW内部に保持するため、同じセッションの往復パケットが同一FWを通過しないとステートが一致せずパケットが破棄されます。
• そこで下線②に関して【問題文】は「②LBaとLBbによるパケットの振り分けは、FWでの動的フィルタリングが正しく行われるように実行される必要がある」と述べています。
• さらにLBの個別仕様として「・LBは、セッション単位で振り分け先FWを決定する」「・セッションと振り分け先FWとの対応は、セッションの生成・消滅に合わせて動的に管理される」とあり、LBがセッション粒度でFWを固定することが明示されています。
• LBa（入口側）とLBb（出口側）が別々の判定で異なるFWを選んでしまうと、外向きパケットと内向きパケットが異なるFWを通過し、前述のステート不整合が発生します。
• よって「2台のLBがセッション単位で 同一FWを必ず選択する」ことが、動的フィルタリングを破綻させないための必須条件となります。
• 以上より模範解答「セッション単位に、2台のLBが同じFWを選択する。」となります。

誤りやすいポイント

• LBaとLBbが「ハッシュ値」や「IPアドレス」で独立に振り分けても大丈夫と考えてしまう。実際にはFWがステートフルであるため入口・出口が合致しなければ通信が成立しません。
• 「どちらか一方のLBだけがセッション固定を行えばよい」と誤解する。2台が協調して同一FWを選ばなければ往復経路が分断されます。
• サーバ向けの負荷分散と同じく「仮想IPアドレス方式を使えばFWの振り分けも簡単」と想定する。本文の「①FWはセッションの終端ノードではないので…仮想IPアドレスを用いる方式は使えない」が示す通り、FWでは適用できません。

FAQ

解答の論理構成

1. 性能要件の把握
   本文には「インターネットとの通信量の増加によって、FWとProxyは、現状の 1.4倍以上 の処理能力が必要である」とあります。したがって単体のFW（現行性能1.0）では将来トラフィックをさばけません。
2. Active-Active化による性能向上
   W氏は「現行NWでのActive-Standby構成からActive-Active構成に変更する案を検討」としています。FWを2台同時稼働させれば実効処理能力は 2.0 相当となり、通常時の1.4を満たします。
3. 故障時のボトルネック
   しかし2台構成で1台が故障すると、残る1台の性能は 1.0 に落ち込み、必要な 1.4 に届きません。
4. 3台構成の採用
   そこで「現行NWにFWを1台追加し、③3台構成とする」と設計しました。3台Active-Active-Active運用なら
   • 通常：1.0×3＝3.0（十分）
   • 1台故障：1.0×2＝2.0（必要1.4を上回る）
   よって「故障発生時でも性能不足にならない」ことが目的となります。
5. 以上より模範解答「故障発生時の性能を不足させないため」が導かれます。

誤りやすいポイント

• 「3台＝冗長度向上」とだけ捉え、性能要件（1.4倍）を無視してしまう。
• Active-Standby時代の考え方を引きずり、「待機系が動けば1.0＋1.0で足りる」と誤算する。実際は故障時に1台運転となる点を見落としがちです。
• Proxy増設と混同し、「Proxyが増えるからFWも3台」と短絡的に覚えてしまう。

FAQ

解答の導き方

1. LB3の計算
   図3を見ると、LB3はインターネット側にあり、ルータ／インターネットとFW群の間に位置しています。したがってLB3が転送するのは、インターネットとFW間の全トラフィックです。表1で該当するのは "Internet ⇔ 社内NW"（89）と "Internet ⇔ DMZ"（10）です。よって
   $89+10=99$
   従って表2中の あ は99になります。
2. LB5の確認（表2に既出）
   LB5はDMZ側（Webサーバ側）にあり、FWとDMZ間のトラフィックを扱います。表1の "Internet ⇔ DMZ"（10）と "社内NW ⇔ DMZ"（1）の合計で $10+1=11$ となり、表2のLB5 = 11と一致します。
3. LB4の計算（最も注意が必要）
   設問文にある "PCからインターネット及びDMZ上のWebサーバへの通信は、現行どおり全てProxyを経由する" を使います。これにより、表1の次の項目はProxyとFW間のやり取りに対応します：

• Internet ⇔ 社内NW = 89 → Proxy ⇔ FWの一部（インターネット向け）
• 社内NW ⇔ DMZ = 1 → Proxy ⇔ FWの一部（DMZ向け）
  したがってProxy ⇔ FWの合計は $89+1=90$ です。

• Proxy ⇔ FW（上で求めた $90$）
• PC ⇔ Proxy（PCがProxyにリクエストを送り、Proxyが応答を返す内部通信）

• あ = 99
• い = 180

誤りやすいポイント

• 表1の値を「片方向」や「片道分のみ」と誤解する。表1は "FW全体の転送データ量を100としたときの値"（往復合計）である点を確認する。
• LB4を計算する際にProxy ⇔ FWのみを数えて終わりにする（PC ⇔ Proxyを見落とす）。LB4は両方を転送するため合計が2倍になる。
• LB4を「4回分」として過剰に掛け算する誤り。正しくは表1の往復分（既に往復を含む）に対して内部のPC⇔Proxy分を追加して2倍にする、という考え方である。
• LB3の計算で "Internet ⇔ DMZ = 10" を忘れて89のままにする誤り。LB3はInternet側全体を見る。
• 問題文が「Proxyのキャッシュ効果を無視」としている点を無視して実運用の推定値を持ち込む誤り。設問条件に従う。

FAQ

解答の論理構成

• 本文には、FWの故障検出機能として
  「④ 対向するLBとの間で、経由するFWを変化させながら、相互にヘルスチェック用パケットを送受信する」
  と記載されています。
• 一方、設問が比較対象とする方式は「LBが故障検出対象であるFWに対してヘルスチェック用パケットを送信する方法」です。これはFWの応答可否だけを監視する手法です。
• 直接FW宛てに送ればFW自身の生死は分かりますが、LBとFW間のリンク断やFWのインタフェース障害など、FWを挟んだ“経路”の不具合は検出できません。
• ④の方式では、ヘルスチェック用パケットが「対向するLB」まで到達して初めて正常と判断できるため、FWはもちろん、FWを通る“経路”そのものが疎通できるかどうかを一括で確認できます。
• したがって、直接FW監視よりも障害検知範囲が広がる点が利点となります。
• 以上より解答は「FWを経由するLB間の経路の障害を検出できる。」となります。

誤りやすいポイント

• 「FWの稼働確認」＝「FW以外の経路も含めた確認」と誤解しやすい。直接FWへPingするだけではリンク障害を見逃す点に注意。
• ④の記述を“LB同士だけの監視”と短絡的に読み取り、FWの経由を意識しない答案を書くと減点対象。
• セッション維持やRST送出など他の故障時処理と混同して利点を書き違えるケース。

FAQ

解答の論理構成

• 本文は、FW故障時の影響軽減策として「⑤FWをはさんでいる両LBが、RSTフラグをオンにしたパケットをTCPコネクションの両端に送信する」と明記しています。
• 一方、Active-Active構成では、FWが落ちると「新NWでは、FWの故障発生時にセッションウができない」ため、途中にあったTCPコネクションは行先を失います。
• RSTはTCPの「接続を直ちに破棄せよ」という制御フラグです。RSTを受信した端点は即座に該当コネクションを閉じ、アプリケーションにエラーを通知します。
• もし⑤の動作を行わなければ、端点はACKが返らないことから再送を繰返し、最終的にTCPの再送タイマやアプリケーションのタイムアウトで切断を検知します。これは数秒〜数分遅延する場合があります。
• 故障直後にRSTを送れば、この待ち時間無しで「接続断」という事実を認識でき、新たな接続を即座に張り直せます。
• したがって利点は「リトライタイムアウトを待たずに速やかに切断を検知できる」ことになります。

誤りやすいポイント

• 「RST＝再接続を自動で張り直す信号」と誤解しがち。RSTはあくまで“即時切断”通知です。
• 「アプリケーション層に影響がない」と考えてしまう。RSTによりソケットはエラー終了するため、アプリケーションは再接続処理を実装しておく必要があります。
• RSTを片方向だけに送れば十分と誤読するケース。⑤は「TCPコネクションの両端」に送るので、双方が同時に切断を認識できます。

FAQ