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

解答の論理構成

• 【問題文】では「①LBは配信サーバにHTTPアクセスによって死活確認を行い、動作が停止している配信サーバに対してはゲーム端末からのアクセスを振り分けない」と記載されています。
• HTTP での死活確認は、配信サーバ上の HTTP サーバプロセス が稼働し、ゲームファイルを返せる状態かどうかを直接確かめる手段です。
• ICMP Echo は OS のネットワークスタックが応答するだけで、アプリケーション層の状態を確認できません。
• そのため OS は稼働しており ICMP Echo には応答するが、肝心の HTTP サーバプロセスが停止 または 異常 というケースを識別できず、LB が引き続き該当サーバへトラフィックを振り分けてしまいます。
• 結果としてゲーム端末はレスポンスを受け取れず、配信品質が劣化するため「ICMP Echo に応答するが HTTP サーバのプロセスが停止している状態を検知できない」という解答になります。

誤りやすいポイント

• ICMP Echo に切り替えると “通信不可” を確実に検知できると誤解し、アプリケーション層の死活監視が不要と考えてしまう。
• 「ICMP は軽量＝優れている」と短絡的に判断し、検査粒度の差（L3 と L7）を見落とす。
• ファイアウォールで ICMP が遮断されるリスクばかりに目が行き、本設問が問う “サービスプロセスの異常検知漏れ” を書き忘れる。

FAQ

解答の論理構成

1. 選択肢の確認
   本文には「LBのサーバ振分けアルゴリズムには、ラウンドロビン方式及び最少接続数方式がある。」とあります。
2. 採用理由の読み取り
   続けて「各配信サーバへの同時接続数をなるべく均等にするために、LBの振分けアルゴリズムとしてア方式を採用している。」とあります。同時接続数を均等化したい場合、接続数が最も少ないサーバを優先する「最少接続数方式」が最適であるため、アには「最少接続数」が入ります。
3. 所属セグメントの決定
   表1よりゲームごとの所属セグメントは
   ・ゲームα：172.21.1.0/24
   ・ゲームβ：172.22.1.0/24
   ・ゲームγ：172.23.1.0/24
   本文には「ゲームDの配信性能向上が必要になる場合には、表1中の所属セグメントイにサーバを増設する。」とあり、ゲームD＝ゲームβを指します（ゲームα・γはA社題意より除外）。ゲームβの所属セグメントは表1で「172.22.1.0/24」であるため、イは「172.22.1.0/24」となります。

誤りやすいポイント

• 「同時接続数を均等にする」というキーワードから「ラウンドロビン方式」を選択してしまうケースがありますが、ラウンドロビンは“接続回数”を均等化するだけで“同時接続数”は考慮しません。
• 表1の読み違えにより、ゲームβのセグメントである 172.22.1.0/24 とゲームγの 172.23.1.0/24 を取り違えるミスが頻出します。
• 「ゲームD」という表記揺れを誤読し、実際に存在しないゲームを探してしまうと設問意図を見失います。

FAQ

解答の論理構成

1. 【問題文】には「ゲーム端末は、インターネット経由でゲームごとにそれぞれ異なるURLにHTTPSでアクセスする」とあります。ここで HTTPS は TLS による暗号化通信であり、サーバ側には公開鍵証明書（サーバ証明書）が必須です。
2. 続いて【問題文】に「LBは、プライベートIPアドレスが設定されたHTTPの配信サーバにアクセスを振り分ける」と記載されています。ゲーム端末から LB までは HTTPS、LB から配信サーバまでは HTTP であるため、暗号化の終端（TLS 終端）は LB が担っていると読み取れます。
3. 表1 でも LB のポートは「443」、配信サーバのポートは「80」と示されており、LB が HTTPS を受付けた後、平文 HTTP に変換してバックエンドへ中継している構成だと確認できます。
4. 従って、サーバ証明書を必ずインストールしておくべき装置は「LB」です。

誤りやすいポイント

• 「HTTPS だから配信サーバにも証明書が必要」と早合点し、バックエンド側を答えてしまう。実際には LB が TLS を終端しています。
• 表1 の「ポート 443」が LB 側、「ポート 80」が配信サーバ側であることを見落として HTTPS⇔HTTP 変換に気付けない。
• 図だけを眺めて装置名を探し、【問題文】の記述との突き合わせを怠る。文章と表の両方を確認するのが確実です。

FAQ

解答の論理構成

• 【問題文】には「BGP の経路選択では、LP 〔LOCAL_PREF〕 属性については値が ウ 経路を優先し、MED 〔MULTI_EXIT_DISC〕 属性については値が エ 経路を優先する。」とあります。
• BGP の標準的な経路選択アルゴリズムでは、LOCAL_PREF は値が大きい方が優先されます。理由は、同一 AS 内で望ましい出口（次ホップ）を管理者が明示的に制御するためで、より高い値を付けた経路を社内で選ばせる設計だからです。
• 一方、MULTI_EXIT_DISC は値が小さい方が優先されます。これは隣接 AS 間で複数の出口がある場合に、より「好ましい（コストの低い）」出口を小さい値で示そうという設計方針によります。
• したがって ウ には「大きい」、エ には「小さい」が入ります。

誤りやすいポイント

• LOCAL_PREF と MED を逆に覚えてしまい、両方とも「小さいほうが優先」と思い込むケース。
• OSPF のメトリック（小さい値が優先）やルーティング全般の「コストは小さいほうが良い」というイメージをそのまま BGP LOCAL_PREF に当てはめる誤答。
• AS Path 長など他の属性と混同し、LOCAL_PREF は「長さ」だと誤解してしまう。

FAQ

解答の論理構成

1. 問題が前提としている状況
   • ゲーム端末（AS−G）が送った HTTPS リクエストは「AS−E 東京 POP」に到着している。
   • 本文中の下線②は「②E 社のある POP からゲーム端末へのトラフィックの経路は、その POP の BGP ルータが受け取る AS Path 長によって選択される」と述べている。
   • さらに「LP 属性と MED 属性が経路選択に影響を及ぼさないように設定している」とあるため、経路選択で効くのは AS Path 長のみである。
2. 図2に示された2つの経路
   • 経路①　AS−E 東京 POP → IX → AS−G
     （AS Path 長＝1）
   • 経路②　AS−E 東京 POP → AS−F → AS−G
     （AS Path 長＝2）
3. AS Path 長による優先順位
   • BGP の経路選択では「AS Path 長が短い経路が優先」される。
   • 経路① の AS Path 長は1、経路② は2なので、経路① が選択される。
4. 「途中通過する場所」を問う設問
   • 経路① で AS−E から AS−G へ向かう途中で必ず通過する場所は図2に明示されている「IX」である。
5. したがって答えは
   ➡ IX

誤りやすいポイント

• 「ゲーム端末から東京 POP への到達経路」を尋ねていると勘違いし、AS−F を選んでしまう。設問は「E 社トラフィックがどこを通って配信されるか」、すなわち東京 POP から外向きの経路を問うている。
• LP（LOCAL_PREF）や MED が絡むと思い込み、値を比較し始める。本文で「LP 属性と MED 属性が経路選択に影響を及ぼさないように設定している」と明記されているため、AS Path 以外は無視する。
• 「IX」は装置名ではなく接続点（Internet Exchange）である点を見落とし、「AS−F − AS−G 間リンク」など具体的な回線名を書いてしまう。

FAQ

解答の論理構成

1. 問題文は、BGP の隣接ルータ間で「③ 隣接 AS の BGP ルータと MD5 認証のための共通のパスワードを設定」していると述べています。
2. MD5 認証は、BGP セッション確立時にパケットへハッシュを付与し、相手が同じパスワードを持つ場合のみ接続を許可する仕組みです。
3. この仕組みにより、パスワードを知らない第三者がセッションを張ること、すなわち “なりすまし” によるセッション確立を阻止できます。
4. よって防げるのは「BGP セッションを不正に確立されること」であり、解答は「不正な BGP 接続」となります。

誤りやすいポイント

• 「MD5 認証＝経路情報の改ざん防止」と短絡しやすい
  → 経路改ざんを“直接”防ぐのは ④ の「経路フィルタリング」。③ はセッションそのものの不正確立防止です。
• 「TCP-AO」や「BGPsec」など最新プロトコルと混同する
  → 本問で採用しているのは MD5 認証であり、範囲を越えた回答は不可。
• 解答に「セッション」や「ピアリング」を入れ忘れ、“BGP” を含めない
  → 指示は「“BGP” という字句を用いて」なので必ず盛り込む必要があります。

FAQ

解答の論理構成

1. 【問題文】には、E 社 BGP ルータが「④アドレスブロックや AS 番号を偽った不正な経路情報を受け取らないための経路フィルタリングを行っている」とあります。
2. フィルタリングを外すと “不正な経路” が BGP で採用される可能性があります。
3. BGP では、受け取った経路のうち最適と判断したものに従ってトラフィックを転送します。したがって “不正な経路” が最適と判定されると、正規の POP ではなく第三者（攻撃者）が示す経路へパケットが流れます。
4. 攻撃者が通称 BGP ハイジャックを行うと、対象プレフィックスへの通信が遮断・盗聴・改ざんされ、正規コンテンツが利用者に届きません。
5. 以上より「不正な経路に含まれるアドレスブロックへのコンテンツ配信ができなくなる」という結論になります。

誤りやすいポイント

• 「経路が偽装される＝通信が乗っ取られる」と直感できず、単に遅延や負荷増大だけを解答してしまう。
• “不正な経路” を必ず解答文に入れる指示を見落とす。
• 影響範囲を POP 内に限定してしまい、インターネット全体での経路誤誘導を考慮しない。

FAQ

解答の論理構成

1. 【問題文】には、RTBH 方式の動作として
   「RTBH方式の対象であることを示すBGPコミュニティ属性が付いたホスト経路を受け取った各BGPルータは、そのホスト経路のネクストホップを廃棄用インタフェース宛てに設定することで、DDoS攻撃の宛先IPアドレス宛ての通信を廃棄する。」
   とある。
2. つまり、インターネット側から届く攻撃パケットは、【図3】中の「BGPルータ1」など “複数の BGP ルータ” で破棄される。
3. 一方 FW1 フィルタリング方式では、攻撃パケットは「BGPルータ1 → ルータ → FW1」まで到達した後に捨てられる。
4. したがって RTBH 方式は、FW1 方式よりもネットワークの外縁、すなわち「攻撃元に近いところ」で遮断できる点が長所である。

誤りやすいポイント

• 「各BGPルータで破棄」という記述を見落とし、FW1 と同じ内部遮断と思い込む。
• RTBH を “ブラックホール＝全通信遮断” と誤解し、正当なトラフィックも巻き添えにすると判断してしまう。
• FW1 の設置場所を「BGPルータ1 の前」と勘違いし、優位性を逆に説明してしまう。

FAQ

解答の論理構成

1. RTBH方式の動作確認
   • 問題文には「RTBH方式の対象であることを示すBGPコミュニティ属性が付いたホスト経路を受け取った各BGPルータは、そのホスト経路のネクストホップを廃棄用インタフェース宛てに設定することで、DDoS攻撃の宛先IPアドレス宛ての通信を廃棄する。」とあります。
   • すなわち RTBH は “宛先IPアドレス” 単位でトラフィックを丸ごと捨てる仕組みです。
2. BGP Flowspec方式の機能確認
   • 「BGP Flowspec方式では、DDoS検知サーバからのiBGPピアリングで、DDoS攻撃の宛先IPアドレスだけではなく、DDoS攻撃の送信元IPアドレス、宛先ポート番号などを組み合わせてBGPルータに広告して該当の通信をフィルタリングすることができる。」と記載されています。
   • Flowspec は複数条件（宛先IP、送信元IP、ポート番号等）を組み合わせてマッチングでき、粒度が細かいことがわかります。
3. 両方式を比較した長所の整理
   • RTBH：宛先IP“だけ”でブラックホール化。
   • Flowspec：宛先IPに加え「送信元IPアドレス、宛先ポート番号など」を条件にできる。
   • よって Flowspec は不要な通信だけを狙い撃ちでき、正常トラフィックへの影響を最小化できます。
4. 以上より、下線⑤「BGP Flowspec方式の方が有用である」理由は
   「より細かい条件で選別して破棄することができる。」
   となります。

誤りやすいポイント

• RTBHでも送信元IPやポートを指定できると誤解する
  → 問題文は“宛先IPアドレス宛ての通信を廃棄”と明言、追加条件は不可。
• Flowspec＝ACL置換と短絡的に覚える
  → FlowspecはBGP属性として拡散される制御情報であり、単なるルータ内ACLとは実装層が異なる。
• 「より細かい条件」を“パケット内容を検査できる”と誤記する
  → DPI機能ではなく、L3/L4ヘッダ条件（IP・ポート・プロトコル等）でのフィルタリングである点に注意。

FAQ