ネットワークスペシャリスト 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. 【問題文】の表1には、FW を通過する 3 区間の転送データ量が示されています。
   • 「インターネット ⇔ 社内NW」：89
   • 「インターネット ⇔ DMZ」：10
   • 「社内NW ⇔ DMZ」：1
2. LB3 の位置は図3で「ルータ―LB3―FW 群―LB4/LB5」となっており、インターネット側に唯一配置されています。
   → よって LB3 を通過するのは “インターネット” が絡む 2 区間の通信のみ。
   • 89（インターネット ⇔ 社内NW）
   • 10（インターネット ⇔ DMZ）
     合計は 99 となるため、表2 の あ＝99 です。
3. LB4 は社内NW側に配置され、役割が 2 つあります。
   ① FW 負荷分散（FW 群と社内NW 間）：
   • インターネット ⇔ 社内NW の 89
   • 社内NW ⇔ DMZ の 1
     計 90
     ② Proxy 負荷分散（PC と Proxy 間）：
     図3より PC の通信は必ず Proxy を経由し、Proxy 負荷分散のために 同じパケットが再度 LB4 を通過 します。
     したがって ①で数えた 90 が “往路” と “復路” の 2 回 LB4 を通過し、
     90 × 2 ＝ 180
     よって表2 の い＝180 です。

誤りやすいポイント

• LB4 が「FW 負荷分散＋Proxy 負荷分散」を兼ねていることを見落とし、90 のまま答えてしまう。
• 「社内NW ⇔ DMZ：1」を忘れて 89×2＝178 と計算し、正答を逃す。
• LB3 が DMZ 向け通信（10）も受け持つことに気付かず、89 のみで算出してしまう。

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