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

解答の論理構成

• 【問題文】には「本社をハブ、各支社をスポークとするア型のVPNを構成している。」とあります。
• 「ハブ」と「スポーク」という語は、自転車の車輪に例えれば中心軸（ハブ）とそこから放射状に伸びる棒（スポーク）の関係を示し、ネットワークでは中央拠点を経由して各拠点を接続するトポロジを指します。
• このトポロジを表す正式な用語は「ハブアンドスポーク（Hub and Spoke）型」です。
• したがって ア に入る適切な字句は「ハブアンドスポーク」と判断できます。

誤りやすいポイント

• 「スター型」と混同する
  スター型は中央装置に全端末が直接接続する LAN トポロジを指すため、WAN の VPN 構成では「ハブアンドスポーク」を用いるのが正確です。
• 「フルメッシュ型」との取り違え
  スポーク間に直接 VPN を張る場合はフルメッシュですが、本文では「本社をハブ」と明示されているため不適切です。
• 英語表記を直訳して「ハブおよびスポーク」と答えてしまう
  試験では一般的に使われるカタカナ表記「ハブアンドスポーク」が求められます。

FAQ

解答の論理構成

• 【問題文】には、下線①として
  「①本社のUTMと支社のUTMのペアではIPsecで暗号化するために同じ鍵を共有」
  とあります。
• IPsec で装置同士が“同じ鍵”をあらかじめ保持しておき、その鍵を使って IKE Phase 1 などの認証を行う方式は、公開鍵基盤(PKI)を使わずに済む簡易手法として広く採用されています。
• この“あらかじめ共有しておく秘密鍵”を IPsec／IKE の用語では「事前共有鍵」（Pre-Shared Key, PSK）と呼びます。
• よって設問の答えは「事前共有鍵」となります。

誤りやすいポイント

• 共有する鍵＝「セッション鍵」と誤解する
  → セッション鍵は通信開始後に生成・交換される一時鍵であり、あらかじめ設定しておく鍵ではありません。
• 公開鍵暗号の「公開鍵」と混同する
  → 事前共有鍵は“秘密鍵”であり、外部に公開するものではありません。
• SA(Security Association)と回答してしまう
  → SA は通信ごとのパラメータ集合であり、“鍵”そのものの名称ではありません。
• PFS(Perfect Forward Secrecy)を使う場合は事前共有鍵を使わないと誤認
  → PFS を有効にしていても、Phase 1 の認証に事前共有鍵を選択することは可能です。

FAQ

解答の論理構成

1. 問題文では、VPNを構成する各拠点間で暗号化に用いる鍵について
   「②この鍵はペアごとに異なる値が設定されている。」
   と明記されています。
2. IPsecでは、同じ鍵を多数の通信ペアで共有すると、万一その鍵が漏えいした際に“全てのトンネル”が解読されるリスクが生じます。
3. ペアごとに異なる鍵を割り当てれば、漏えいしても影響を受けるのは“当該ペアの通信”だけに局限されます。
4. したがって、設問が求める「鍵の管理に着目した効果」は
   「鍵が漏えいした際の影響範囲を小さくできる」
   という説明になります。

誤りやすいポイント

• 「ペアごとに異なる鍵」を「定期的に更新する鍵」と混同し、更新頻度のメリットを答えてしまう。
• 影響範囲の縮小を“漏えい確率が下がる”と誤解してしまう。確率ではなく“被害範囲”の話です。
• 「可用性向上」「通信速度向上」といった無関係な利点を挙げてしまう。今回問われているのは“鍵管理”視点のみです。

FAQ

解答の論理構成

1. 問題文は下線③として
   “トランスポートモードとした場合は元のIPパケット（元のIPヘッダと元のIPペイロード）とESPトレーラの範囲を暗号化”
   と明示しています。
2. IPsec ESPでは
   ・トランスポートモード … 上記のとおり“元のIPパケット＋ESPトレーラ”を暗号化し、外側の“IPヘッダー”は暗号化しません。
   ・トンネルモード … “新たに付加する外側 IP ヘッダー以外の部分”を丸ごと暗号化します。
3. 図2のレイヤ表記は
   “IPヘッダー / ESPヘッダー / 元のIPパケット / ESPトレーラ / ESP認証データ”
   です。
4. 従ってトンネルモードでは、暗号化対象は
   “IPヘッダー、元のIPパケット、ESPトレーラ”
   となります。ESPヘッダーとESP認証データは暗号化対象外です。

誤りやすいポイント

• 「IPヘッダー」を除外してしまう
  トンネルモードでは外側の“IPヘッダー”以外を暗号化すると誤解しやすいですが、図2で示される“IPヘッダー”は IP-IP でカプセル化した内側ヘッダーを指しています。
• 「ESPヘッダー」まで暗号化対象に含めてしまう
  ESPヘッダーは復号処理の入口になるため暗号化しません。
• 「ESP認証データ」を暗号化対象に含める
  認証用データは暗号化せずに付加されます。

FAQ

解答の論理構成

1. 問題文では、IP‐IP over IPsecインタフェースについて「④IP‐IP over IPsecインタフェースでは、IP Unnumbered設定が行われている」と記載されています。
2. “IP Unnumbered” は、ルータやUTMなどの論理インタフェースに対し、個別のIPアドレスを付与せずに運用する技術です。
3. つまり、IP Unnumbered設定とは「インタフェースにIPアドレスの割当てを行わない」ことを示します。
4. よって解答は「インタフェースにIPアドレスの割当てを行わない設定」となります。

誤りやすいポイント

• 「IPアドレスを省略しても自動で割り当てられる」と誤解し、DHCPなどと混同する。
• 「番号を共有する」と解釈し、他インタフェースのIPアドレスを流用する仕組みと答えてしまう。
• “IP Unnumbered” を「IPsec側でのみ有効」と限定的に考え、インタフェース一般の設定であることを見落とす。

FAQ

解答の論理構成

1. 問題文では「⑤ IP-IP over IPsec インタフェースでは、中継する TCP パケットの IP フラグメントを防止するための設定」が行われている、と述べています。
2. これはフレームサイズ（MTU）を調整し、ルータ（UTM）がフラグメントされた複数のパケットを処理しなくても済むようにする設定です。
3. 防止設定を外す（＝フラグメントが発生する）と、UTMは
   ・フラグメントごとのルックアップ
   ・再組立て（再アセンブル）や整合性確認
   ・暗号化／復号処理の複数回実行
   を行う必要があります。
4. これら追加処理はCPU・メモリ資源を占有しスループットを低下させるため、UTM自体の処理量が増えます。
5. よって、設定を行わないと「転送負荷の増大」という影響になります。

誤りやすいポイント

• 「パケットが破棄され通信不可になる」と考えがちですが、多くのUTMはフラグメントを正しくリレーできるため主因は性能劣化です。
• 「セキュリティが低下する」と答えるケースがありますが、本設問は性能面での影響を問うています。
• IPsecトンネルモード／トランスポートモードの混同により、原因を MTU ではなく暗号化方式と誤認することがあります。

FAQ

解答の論理構成

1. DMZ の Web サーバは社内サーバであり、FQDN は問題文に示された
   “a‐sha.jp : A社の社内利用ドメイン名” に属します。
   したがって引数 host には “○○.a-sha.jp” 形式が渡されます。
2. 図4 b の条件部には
   dnsDomainIs(host, ".a-sha.jp")
   が含まれており、
   “host が A 社の社内利用ドメイン名に属する場合、FindProxyForURL 関数の戻り値として "DIRECT" を返す。”
   と原文で明記されています。
3. b が成り立つと、関数はそこで終了し後続の c・d は評価されません。戻り値は “DIRECT” です。
4. “DIRECT” は【問題文】の説明どおり
   “プロキシサーバを利用せず直接通信を行う。”
   ことを示します。

誤りやすいポイント

• “社内サーバでも DMZ にあるから外部ネットワーク扱い” と誤認し、d の “proxy.a-sha.jp:8080” を選んでしまう。
• .a-sha.jp の前にドットが付いている形だけをチェックし、サブドメイン “www.a-sha.jp” は対象外だと早合点してしまう。dnsDomainIs は末尾一致で判定するためすべて対象です。
• “DIRECT＝ローカルブレイクアウトのため外部に直接出る” と読んで、本社‐支社経路は必ずプロキシ経由と決め付けてしまう（今回は社内向けなので逆）。

FAQ

解答の論理構成

1. URL から渡されるホスト名は www.example.com です。
2. PAC ファイルの最初の分岐 b は、
   “host が localhost、又は … host が A 社の社内利用ドメイン名に属する場合”
   と記載されており、社内ドメイン ".a-sha.jp" を判定します。
   しかし www.example.com は該当しないため “DIRECT” にはなりません。
3. 次に c で、
   “host が C 社 SaaS 利用ドメイン名に属する場合、又は host が C 社 SaaS 利用ドメイン名のシェルグロブ表現に一致する場合”
   を判定します。条件は ".image.cdn.example" 又は "*.c-saas.example" ですが、やはり www.example.com には一致しません。
4. したがって d の
   “b、c どちらにも該当しない場合、FindProxyForURL 関数の戻り値として "PROXY proxy.a-sha.jp:8080" を返す。”
   が実行されます。
5. ポート番号は設問で問われていないため、プロキシサーバ名のみを答えればよく、正解は
   proxy.a-sha.jp となります。

誤りやすいポイント

• example.com を ".image.cdn.example" と読み違え、c 条件に合致すると勘違いする。
• “DIRECT” 判定は IP アドレスがプライベートかどうかだけで決まると思い込み、社内ドメイン判定を見落とす。
• 返値 "PROXY proxy.a-sha.jp:8080" の ポート番号を解答に含めてしまう ミス。
• FindProxyForURL 関数は 上から順に評価 される点を忘れ、d まで到達しないと誤解する。

FAQ

解答の論理構成

1. 【問題文】では、PACファイル中で
   isInNet(ip, "172.16.0.0", "255.240.0.0")
   という条件式を用いています。これは「変数 ip が "172.16.0.0" をネットワークアドレスとし、サブネットマスク "255.240.0.0" で示される範囲内に属するか」を判定する関数です。
2. "255.240.0.0" を 2 進表記すると 11111111.11110000.00000000.00000000 であり、1 が立っているビット数は 12 ビットです。すなわち /12 プレフィックス、CIDR では 172.16.0.0/12 を示します。
3. /12 では上位 12 ビットがネットワーク部となるため、下位 20 ビット（32−12）がホスト部です。
4. ネットワークアドレス "172.16.0.0" で固定される上位 12 ビットは
   172(10101100).16(00010000) → 10101100 0001
5. 下位 20 ビットをすべて 0 にすると最小値、すべて 1 にすると最大値が得られます。
   ・最小値：172.16.0.0
   ・最大値：上位 12 ビットは固定、下位 20 ビットを 1 にすると十進で 172.31.255.255
6. よって、対象のアドレス空間は
   最初：172.16.0.0
   最後：172.31.255.255
   となります。

誤りやすいポイント

• サブネットマスク "255.240.0.0" を /20 と誤読し、計算を間違えるケース
• クラス B 私設ネットワーク（172.16.0.0～172.31.255.255）の範囲を暗記しておらず、ビット演算があいまいになるケース
• ネットワークアドレスとブロードキャストアドレスを含める・含めないの区別をつけられないまま範囲を答えてしまうケース

FAQ

解答の論理構成

1. 図4のbの説明に「host が localhost、又は a で宣した ip がプライベート IP アドレスやループバックアドレス、又は host が A 社の社内利用ドメイン名に属する場合、FindProxyForURL 関数の戻り値として "DIRECT" を返す。」とあります。
2. 問題文には「FindProxyForURL関数の戻り値が“DIRECT”ならば、プロキシサーバを利用せず直接通信を行う。」と明記されています。
3. つまりプライベート IP アドレス宛ての通信は、本社のプロキシサーバを経由せず直接アクセスされます。
4. プロキシを経由しない通信が増えれば「本社のプロキシサーバ」に掛かるトラフィック処理が減少します。
5. したがって、「負荷軽減」の効果は「本社のプロキシサーバの負荷軽減」となります。

誤りやすいポイント

• “DIRECT” を返す条件を「社内ドメインだけ」と誤解し、プライベート IP 範囲の判定を見落とす。
• 「負荷軽減」の対象を各支社のUTMプロキシサーバと取り違える。
• “DIRECT” を「インターネットへ直接出る」とだけ理解し、社内向け通信でも適用される点を忘れる。

FAQ

解答の論理構成

1. PACファイルは、FindProxyForURL 関数の戻り値として利用するプロキシサーバを文字列で指定します。問題文には
   “return "PROXY proxy.osaka.a-sha.jp:8080";”
   とあり、大阪支社では proxy.osaka.a-sha.jp を明示していることが分かります。
2. 一方、本社経由に切り替える場合は
   “return "PROXY proxy.a-sha.jp:8080";”
   と、FQDN が異なります。
3. したがって支社が変われば、proxy.<支社名>.a-sha.jp の部分が拠点ごとに固有となり、単一の PAC ファイルでは正しく動作しません。
4. このため下線⑥ “Bさんは各支社のPACファイルを作成した” という対応が必要になります。

誤りやすいポイント

• 「IPアドレスが違うから」とだけ書くと、設問は文字列で指定する FQDN の違いを問うているため減点されやすいです。
• PAC の条件分岐（.image.cdn.example など）を支社別に変更すると誤解しやすいですが、実際に支社ごとで変わるのは戻り値の FQDN 部分だけです。
• WPAD を使わない＝1 本で済むと早合点し、PAC も 1 ファイルで良いと判断してしまうケースがあります。

FAQ

解答の論理構成

1. WPAD が利用する仕組み
   引用：
   「WPADは、イやウの機能を利用して、PACファイルの場所を配布するプロトコルである。」
   DHCP の “Option 252” と DNS の “wpad.<ドメイン名>” レコードは、ともにクライアントへ PAC ファイルの所在を知らせる代表的な方法です。したがって イ＝「DHCP」、ウ＝「DNS」と決定します。
2. PAC ファイルの取得プロトコル
   引用：
   「アプリケーションレイヤープロトコルの一つであるエを利用してエサーバからPACファイルのダウンロードを試みる。」
   WPAD クライアントは上記 DHCP/DNS で得た URL に対し HTTP GET を行い wpad.dat を取得します。ここで利用するのは「HTTP」なので エ＝「HTTP」となります。
3. WPAD を使わない場合の設定項目
   引用：
   「PCやWebブラウザにはPACファイルのオを直接設定する。」
   クライアントが PAC を明示利用する際には “http://proxy.example.com/proxy.pac” のように URL を入力します。ゆえに オ＝「URL」です。
4. 結論
   イ：DHCP
   ウ：DNS
   エ：HTTP
   オ：URL

誤りやすいポイント

• 「HTTPS でダウンロードするはず」と思い込み、エ を “HTTPS” と誤答する。WPAD 仕様は基本的に HTTP。
• DHCP ではなく「NTP」「TFTP」などと混同する。Option 252 を思い出せば DHCP が正解。
• DNS と DDNS、mDNS などを混同し、ウ を誤る。
• オ を “パス” や “ファイルパス” と書いてしまう。ブラウザに入力するのは URL。

FAQ

解答の論理構成

1. 本文では「WPADは、イやウの機能を利用して、PACファイルの場所を配布するプロトコルである。」と説明しています。つまり、WPADを用いると端末はネットワーク上のサーバから“自動で”PACファイルを取得します。
2. さらに「悪意のあるイサーバやウサーバがあると⑦PCやWebブラウザが脆弱にさらされる可能性も指摘されている。」と明記されており、脅威の発生源が“悪意のあるサーバ”である点が示されています。
3. WPADで取得するPACファイルには「return "PROXY …"」のような記述でプロキシ先を任意に指定できるため、攻撃者が偽PACファイルを配布すると通信経路を乗っ取られます。
4. したがって下線⑦の脅威は「ユーザ通信が攻撃者の指定する“不正なプロキシサーバ”に転送されること」です。
5. 上記より模範解答「不正なプロキシサーバに中継される。」となります。

誤りやすいポイント

• WPAD＝自動設定と覚えるだけで、取得したPACが“信頼できない可能性”を失念しやすいです。
• 脅威を「DNSポイズニング」や「DHCPスプーフィング」と表現してしまうと、根本の被害（不正なプロキシ経由）を示せず減点対象になります。
• PACファイル自体はテキストなので「マルウェア感染」と誤解するケースがありますが、ここで問われているのは通信ハイジャックです。

FAQ