ネットワークスペシャリスト 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
   本文には「ゲームβの配信性能向上が必要になる場合には、表1中の所属セグメントイにサーバを増設する。」とあります。ゲームβの所属セグメントは表1で「172.22.1.0/24」であるため、イは「172.22.1.0/24」となります。

誤りやすいポイント

• 「同時接続数を均等にする」というキーワードから「ラウンドロビン方式」を選択してしまうケースがありますが、ラウンドロビンは“接続回数”を均等化するだけで“同時接続数”は考慮しません。
• 表1の読み違えにより、ゲームβのセグメントである172.22.1.0/24とゲームγの172.23.1.0/24を取り違えるミスが頻出します。
• 本文が指すのは「ゲームβ」です。ゲームα・γのセグメントと取り違えないように、表1でゲーム名と所属セグメントを対応させて確認します。

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