平成30年度 秋期 午後Ⅰ

本文の根拠

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

社内 PC からインターネットへは，Web アクセスだけが許可されており，プロキシサーバを経由して通信を行っている。

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

F 社のプロキシのように ［ ア ］ プロキシは，社内に対して，アクセス先 URL のログ取得や，外部サーバのコンテンツをキャッシュして使用帯域を削減する目的で用いられる。

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

［ イ ］ プロキシは，外部から公開サーバのオリジナルコンテンツに直接アクセスさせないことによる改ざん防止，キャッシュによる応答速度の向上，及び複数のサーバでの負荷分散を行う目的で用いられる。

プロキシは，どちら側の代理をするかで2種類に分かれる。フォワードプロキシはクライアント（社内 PC）の側に置き，クライアントの代わりに外部のサーバへアクセスする。リバースプロキシはサーバの側に置き，外部のクライアントからのアクセスをいったん受けてから，後ろにある本物のサーバへ中継する。

アは，F 社のプロキシのように社内 PC がインターネットへ出るときに経由するもので，アクセス先 URL のログ取得や外部コンテンツのキャッシュに使う。これはクライアント側の代理なのでフォワードプロキシである。イは，外部から公開サーバのオリジナルコンテンツに直接アクセスさせない，複数のサーバで負荷分散する，という公開サーバ側の役割なのでリバースプロキシである。

間違えやすい点。「透過型プロキシ」は PC にプロキシを設定させずに通信を横取りする設置の仕方の違いで，ここでの対（社内向けか公開サーバ向けか）とは軸が違う。

本文の根拠

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

アクセス先 URL と利用者 ID

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

社内 PC からインターネットへの Web アクセスでは①プロキシサーバにおいて認証を行う。

プロキシサーバが認証をしないと，ログに残るのは送信元 IP アドレスとアクセス先だけで，誰がアクセスしたかは分からない。PC の IP アドレスは DHCP などで変わることもあるので，人との対応付けは難しい。プロキシ認証（HTTP ではプロキシが 407 応答で認証を求め，ブラウザが Proxy-Authorization ヘッダで利用者の資格情報を送る）を行えば，プロキシサーバは要求ごとに利用者を特定でき，ログに利用者 ID を付けられる。

本文は，プロキシサーバで取得するログとして「アクセス先 URL と利用者 ID」「G 社 SaaS のファイルアップロード／ダウンロードのログと利用者 ID」を挙げている。どちらも利用者 ID を含むので，下線①の認証はこの利用者 ID をログに残すためのものだと分かる。

間違えやすい点。「パスワード」や「IP アドレス」ではない。IP アドレスは認証しなくてもログに残る。問われているのは認証によって新たに付加できる情報である。

本文の根拠

〔G 社 SaaS の試用〕

プロキシサーバで HTTPS のアクセスログを確認したところ，②アクセス先のホスト名は記録されていたが，URL は記録されていなかった

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

社内 PC からインターネットへは，Web アクセスだけが許可されており，プロキシサーバを経由して通信を行っている。

クライアントがプロキシ経由で HTTPS のサイトへアクセスするときは，まずプロキシに対して CONNECT メソッド（HTTP/1.1，RFC 7231）で「ホスト名:ポート番号」を指定し，プロキシにその宛先との TCP 接続を張らせる。以後プロキシは両側のバイトをそのまま中継する（トンネル）だけで，TLS で暗号化された中身は見えない。プロキシが知ることができるのは CONNECT 要求に書かれたホスト名とポート番号までなので，下線②のようにホスト名は記録されても，その先の URL（パス）は記録されない。

対策：CONNECT は宛先ポートを自由に指定できるので，そのままにしておくと，社内に侵入したマルウェアが CONNECT で任意のポートへトンネルを張り，HTTPS 以外の通信（独自プロトコルでの C&C 通信など）をプロキシ経由で外に出せてしまう。社内 PC から許しているのは Web アクセスだけなので，CONNECT の宛先ポートを HTTPS の 443 番に限り，それ以外のポートへの CONNECT を拒否すればよい。

30字に収める。解答例は「HTTPS以外のポートのCONNECTを拒否する。」で25字。「CONNECT を拒否する」だけでは HTTPS も使えなくなるので，「HTTPS 以外のポート」という条件を必ず入れる。採点講評でも正答率が低かったとされている。

採点講評（IPA）

設問2(1)は，暗号化されているHTTPSプロトコルをプロキシサーバで処理するために必要なHTTPのCONNECTメソッドについて出題したが，正答率は低かった。HTTPSの利用が増えてきた今日，CONNECTメソッドは，便利な技術である反面セキュリティホールとなる可能性のある技術であるので，よく理解しておいてほしい。

本文の根拠

〔G 社 SaaS の試用〕

アクセス先の URL を把握するために，プロキシサーバで暗号化通信を一旦復号し，必要な処理を行った上で再度暗号化した。しかし，社内 PC でエラーメッセージ“証明書が信頼できない”が表示されたので，社内 PC に ［ ウ ］ をインストールして解決した。

プロキシサーバで HTTPS を復号するには，プロキシが社内 PC との間で TLS を終端しなければならない。このときプロキシは，アクセス先のホスト名に合わせたサーバ証明書をその場で作り，自分の CA 鍵で署名して PC に提示する。PC のブラウザは，その証明書の発行元（プロキシの CA）を信頼できるルート証明書の一覧に持っていないので，「証明書が信頼できない」と警告する。

そこで，プロキシサーバの CA のルート証明書を社内 PC の信頼されたルート証明書として入れておけば，プロキシが作ったサーバ証明書の検証が通り，警告は出なくなる。本文の「一旦復号し，…再度暗号化した」と，その直後の“証明書が信頼できない”のエラーが，この仕組みを使う場面である。

20字に収める。解答例は「プロキシサーバのルート証明書」で14字。単に「ルート証明書」「サーバ証明書」では不十分で，誰の（プロキシサーバの）ルート証明書かを書く。PC にサーバ証明書を入れても，信頼の起点にはならない。

本文の根拠

(1) SD-WAN ルータの概要

SDN は，利用者の通信トラフィックを転送するデータプレーンと，通信装置を集中制御する ［ エ ］ プレーンから構成されており，［ エ ］ プレーンのソフトウェアでデータ転送を制御する方式である。

(1) SD-WAN ルータの概要

SD-WAN ルータの設定は，SD-WAN コントローラによって集中制御される。

SDN は，ネットワーク機器の機能を，パケットを実際に転送するデータプレーン（転送プレーン）と，経路や転送のルールを決めて機器に指示するコントロールプレーン（制御プレーン）に分け，コントロールプレーンをソフトウェア（コントローラ）に集めて集中制御する考え方である。

本文では，F 社の SD-WAN ルータの設定は SD-WAN コントローラによって集中制御される。コントローラがコントロールプレーンの役割を担い，各拠点の SD-WAN ルータはデータプレーンとして転送を行う。

間違えやすい点。「管理プレーン（マネジメントプレーン）」は機器の設定・監視の操作を指す用語で，SDN で「データプレーン」と対になる語はコントロールプレーンである。

採点講評（IPA）

設問3は，SD-WANによってSaaSへのトラフィックだけを迂回する方法について出題した。アプリケーションの通信先を制御するためには，ルーティングの変更とアプリケーションの経由先変更の両方に目を向ける必要があることに注意してほしい。

本文の根拠

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

デフォルトルートのネクストホップを FW に設定している。

(2) SD-WAN ルータを用いたときの通信

社内 PC から G 社 SaaS への Web アクセスは，プロキシサーバを経由せず各 SD-WAN ルータを経由する。

(2) SD-WAN ルータを用いたときの通信

L3SW にプロキシサーバへの静的経路情報を追加する。

(2) SD-WAN ルータを用いたときの通信

③G 社 SaaS の IP アドレスが変更された場合でもその都度 L3SW を設定しなくても済むように，L3SW の静的経路情報を設定変更する。

現行の L3SW はデフォルトルートのネクストホップを FW にしている。構成案では，G 社 SaaS への通信はプロキシも FW も通らず SD-WAN ルータからインターネットへ出す。L3SW に「G 社 SaaS の IP アドレス宛ては SD-WAN ルータへ」という経路を個別に書くと，G 社 SaaS のアドレスが変わるたびに L3SW を設定し直さなければならない。そこでデフォルトルートのネクストホップを SD-WAN ルータに変え，宛先の決まっていない通信は全て SD-WAN ルータへ送る。

それでも G 社 SaaS 以外の Web アクセスが FW 側へ行けるのは，社内 PC がそれらをプロキシサーバ宛てに送るからである。本文の「L3SW にプロキシサーバへの静的経路情報を追加する」がそのための経路で，プロキシサーバ（DMZ）宛てだけは FW へ向ける。G 社 SaaS のアドレスブロックの管理は SD-WAN ルータ側（(3)の運用）に任せられる。

35字に収める。解答例は「ネクストホップがSD-WANルータとなるデフォルトルート」で28字。「どの宛先の経路か（デフォルトルート）」と「ネクストホップ（SD-WAN ルータ）」の2つを必ず書く。

採点講評（IPA）

設問3は，SD-WANによってSaaSへのトラフィックだけを迂回する方法について出題した。アプリケーションの通信先を制御するためには，ルーティングの変更とアプリケーションの経由先変更の両方に目を向ける必要があることに注意してほしい。

本文の根拠

(1) SD-WAN ルータの概要

SD-WAN ルータの設定は，SD-WAN コントローラによって集中制御される。

(3) SD-WAN ルータの運用

F 社は，RSS 配信された IP アドレスブロックを検知するツールを作成して，自動的にツールから ［ オ ］ に指示を行い，全社の SD-WAN ルータの設定を変更することにした。

全社の SD-WAN ルータの設定を変えるには，1台ずつ設定するのではなく，全ての SD-WAN ルータを集中制御している機器に指示すればよい。本文の仕様で，SD-WAN ルータの設定は SD-WAN コントローラによって集中制御されるとあるので，ツールの指示先は SD-WAN コントローラである。

図2では SD-WAN コントローラは本社にあり，注記で接続構成は省略されている。SDN のコントロールプレーン（設問3(1)）に当たる機器であり，ツールはコントローラの API などを通じて変更を指示することになる。

間違えやすい点。「図2中の機器名で」とあるので，図の表記どおり「SD-WAN コントローラ」と書く。「SD-WAN ルータ」では全社のルータを一度に変更する仕組みにならない。

採点講評（IPA）

設問3は，SD-WANによってSaaSへのトラフィックだけを迂回する方法について出題した。アプリケーションの通信先を制御するためには，ルーティングの変更とアプリケーションの経由先変更の両方に目を向ける必要があることに注意してほしい。

本文の根拠

(2) SD-WAN ルータを用いたときの通信

社内 PC から G 社 SaaS への Web アクセスは，プロキシサーバを経由せず各 SD-WAN ルータを経由する。

(3) SD-WAN ルータの運用

さらに，社内 PC から参照する④プロキシ自動設定ファイルを作成することにした。

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

G 社 SaaS との通信は，HTTPS によって暗号化する。

プロキシ自動設定ファイル（PAC ファイル）は，ブラウザがアクセス先ごとに「プロキシを使うか，直接（DIRECT）接続するか」を判定するための JavaScript のファイルである。L3SW のデフォルトルートを SD-WAN ルータに向けても，PC がプロキシを使う設定のままなら G 社 SaaS への通信もプロキシサーバ宛てに送られてしまう。そこで PAC ファイルで G 社 SaaS 宛ての通信だけを DIRECT にし，プロキシから外す。

本文では G 社 SaaS への Web アクセスはプロキシサーバを経由せず SD-WAN ルータを経由し，G 社 SaaS との通信は HTTPS で暗号化する。試用で問題になったのは G 社 SaaS へのセッション数と転送量なので，除外するのは G 社 SaaS への HTTPS 通信である。G 社のアドレスブロックが変わっても，ホスト名で判定すれば PAC ファイルを変えずに済む。採点講評も，ルーティングの変更とアプリケーションの経由先の変更の両方に目を向ける必要があると述べている。

20字に収める。解答例は「G社SaaSへのHTTPS通信」で15字。宛先（G 社 SaaS）とプロトコル（HTTPS）を入れる。

採点講評（IPA）

設問3は，SD-WANによってSaaSへのトラフィックだけを迂回する方法について出題した。アプリケーションの通信先を制御するためには，ルーティングの変更とアプリケーションの経由先変更の両方に目を向ける必要があることに注意してほしい。

本文の根拠

(2) SD-WAN ルータを用いたときの通信

社内 PC から G 社 SaaS への Web アクセスは，プロキシサーバを経由せず各 SD-WAN ルータを経由する。

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

出張先の PC から直接 G 社 SaaS を利用できるようにするために，G 社 SaaS では送信元 IP アドレスの制限を行わない。

〔F 社の現行ネットワーク構成と G 社 SaaS 導入に合わせたセキュリティ対策〕

G 社 SaaS のファイルアップロード／ダウンロードのログと利用者 ID

(4) G 社 SaaS アクセスログの取得

G 社 SaaS へのアクセスログは，⑤プロキシサーバからではなく，G 社 SaaS の API にアクセスして取得することにした。

F 社は当初，G 社 SaaS のファイルアップロード／ダウンロードのログと利用者 ID をプロキシサーバで取る予定だった。しかし構成案では2つの理由でプロキシサーバでは取りきれない。①社内 PC から G 社 SaaS へのアクセスはプロキシサーバを経由しなくなる（設問3(2)(4)の変更による）ので，そもそもプロキシサーバにログが残らない。②出張先の PC は F 社のネットワークを通らずインターネットから直接 G 社 SaaS を使うので，これもプロキシサーバには記録されない。G 社 SaaS 側のログであれば，どこからのアクセスでも全て記録されている。

本文の「プロキシサーバを経由せず各 SD-WAN ルータを経由する」が①の，「出張先の PC から直接 G 社 SaaS を利用できるようにする」「送信元 IP アドレスの制限を行わない」が②の根拠である。

40字に収める。解答例は①「社内PCからG社SaaSへのアクセスがプロキシサーバを経由しなくなるから」36字，②「出張先のPCからG社SaaSへのアクセスが記録されるから」28字。①と②は順不同。①は「プロキシを経由しない」，②は「出張先からのアクセスも記録できる」という，別々の観点を1つずつ書く。

採点講評（IPA）

設問3は，SD-WANによってSaaSへのトラフィックだけを迂回する方法について出題した。アプリケーションの通信先を制御するためには，ルーティングの変更とアプリケーションの経由先変更の両方に目を向ける必要があることに注意してほしい。

本文の根拠

〔監視サーバの概要〕

ping 監視には，RFC 792 で規定されているプロトコルである ［ ア ］ を利用する。echo request パケットの宛先として，監視対象機器には ［ イ ］ を割り当てる必要がある。

〔監視サーバの概要〕

SYSLOG は，トランスポートプロトコルとして RFC 768 で規定されている ［ ウ ］ を用いている。

〔ネットワーク監視の改善策の立案〕

SNMP エージェントと SNMP マネージャは，同じグループであることを示す ［ エ ］ を用いて，機器の管理情報（以下，MIB という）を共有する。

ア：ping は ICMP（RFC 792）の Echo（echo request）を送り，Echo Reply が返るかで相手の死活を確かめる。イ：ICMP は IP の上で動くので，echo request の宛先には IP アドレスが要る。コア SW 以外の監視対象（サーバ SW，フロア SW）はレイヤ2スイッチ（図1注記2）で，転送だけならアドレスは不要だが，ping 監視を受けるには管理用の IP アドレスを割り当てておく必要がある。ウ：RFC 768 は UDP である。SYSLOG は従来 UDP の 514 番ポートで送られ，送達確認が無い。エ：SNMPv1/v2c では，エージェントとマネージャが同じコミュニティ名（コミュニティ文字列）を共有し，これが一致する要求だけに応答する。

本文が RFC 番号を示しているので，ア・ウは RFC 番号と名前の対応の知識で決まる。ウの UDP に送達確認が無いことは，設問3(2)・設問4(2)で SYSLOG やトラップのメッセージが失われる話につながる。

間違えやすい点。エは SNMPv2c の用語である。「コミュニティ名」「コミュニティ」どちらでもよい。SNMPv3 の「ユーザ名」や「エンジン ID」とは違う。採点講評ではエの正答率が低かったとされている。

採点講評（IPA）

設問1のエは，SNMPの基本的な用語だが，正答率が低かった。

本文の根拠

〔A 社 LAN の概要〕

コア SW には，①VRRP が設定してあり

図1

注記1 コアSW1，コアSW2 は，レイヤ3スイッチである。

VRRP（RFC 5798 など）は，複数のルータで1つの仮想ルータを作り，仮想 IP アドレス（と仮想 MAC アドレス）をマスタルータが引き受ける仕組みである。PC やサーバは，他のサブネットへ送るときの宛先として，デフォルトゲートウェイにこの仮想 IP アドレスを設定しておく。マスタが止まればバックアップが同じ仮想 IP アドレスを引き継ぐので，PC やサーバの設定を変えずに通信を続けられる。

図1でコア SW1，コア SW2 はレイヤ3スイッチで，VLAN100（サーバ），VLAN200・VLAN300（フロア）の間をルーティングしている。PC やサーバから見ると，コア SW はデフォルトゲートウェイであり，VRRP はこれを冗長化している。

15字に収める。解答例は「デフォルトゲートウェイ」で11字。「PC 及びサーバに設定する情報に着目して」とあるので，「コア SW」「ルータ」のような機器名ではなく，端末側に設定する項目名で答える。

本文の根拠

〔A 社 LAN の概要〕

②正常時は，コア SW1 がマスタルータで，コア SW2 がバックアップルータとなるように設定している。

VRRP では，マスタルータが一定間隔（既定では1秒）で VRRP アドバタイズメント（ADVERTISEMENT）をマルチキャスト（224.0.0.18）で送り，自分が動いていることを知らせる。バックアップルータはこれを受け続けている間は待機し，一定時間（Master_Down_Interval）受信しなくなるとマスタが停止したとみなして，自らマスタルータに切り替わる。VRRP のメッセージの種類は ADVERTISEMENT だけである（RFC 5798）。

下線②のとおり，正常時はコア SW1 がマスタで，コア SW2 はコア SW1 からのアドバタイズメントを待ち受けている。

15字に収める。解答例は「VRRPアドバタイズメント」で13字。採点講評では VRRP と異なるプロトコルについて述べた解答が目立ったとされている。HSRP の「Hello」や，STP の「BPDU」と取り違えない。

採点講評（IPA）

設問2(2)では，VRRPについての説明を求めたが，VRRPと異なるプロトコルについて述べた解答が目立った。VRRPは冗長化設計で用いられる基本的な技術であり，正しく理解しておいてほしい。

本文の根拠

〔A 社 LAN の概要〕

コア SW の p1 ポート，p2 ポート及び p3 ポートはアクセスポートで，③p4 ポートを IEEE 802.1Q を用いたトランクポートに設定している。

図1

サーバSW はコアSW1 の p1（VLAN100）とコアSW2 の p1（VLAN100）に接続している。

図1

コアSW1 の p2（VLAN200）はフロアラック1 のフロアSW1 に，コアSW1 の p3（VLAN300）はフロアラック2 のフロアSW3 に接続している。

図1

コアSW2 の p2（VLAN200）はフロアラック1 のフロアSW2 に，コアSW2 の p3（VLAN300）はフロアラック2 のフロアSW4 に接続している。

図1で，コア SW1 とコア SW2 はどちらも VLAN100・VLAN200・VLAN300 のアクセスポートを1つずつもっている。VRRP は VLAN（サブネット）ごとに動くので，3つの VLAN それぞれでマスタのコア SW1 からバックアップのコア SW2 へ VRRP アドバタイズメントが届かなければならない。また，レイヤ2の経路としても，片方のコア SW とフロア SW の間が切れたとき，その VLAN のフレームはもう一方のコア SW から p4 を通って届く必要がある（設問3の障害はまさにこの経路を使う）。したがって p4 のトランクには3つの VLAN を全て通す。

本文の「p1 ポート，p2 ポート及び p3 ポートはアクセスポート」と，図1の注記4（VLAN100，VLAN200，VLAN300 はアクセスポートの VLAN ID）を合わせると，コア SW 上にある VLAN はこの3つである。

間違えやすい点。「全て答えよ」なので，VLAN100・VLAN200・VLAN300 を漏れなく書く。サーバ用の VLAN100 はサーバ SW で両コア SW がつながっているから不要，と考えて外さない。

本文の根拠

〔A 社 LAN の概要〕

正常時はコア SW1 がルートブリッジとなるように設定している。

図2

コアSW1 の p2 とフロアSW1 の p1 はケーブル1 で接続しており，ケーブル1 は破線（断線）である。コアSW2 の p2 とフロアSW2 の p1 は実線で接続している。

〔障害発生時の状況確認〕

ケーブル1の断線によって，④フロア SW2 の p1 ポートの STP のポート状態がブロッキングから，リスニング，ラーニングを経て，フォワーディングに遷移した。

STP（IEEE 802.1D）では，ルートブリッジが定期的に BPDU を送り，各ブリッジはルートポートで受けた BPDU を元に，自分の指定ポートから下流へ BPDU を送り出す。正常時，ルートブリッジはコア SW1 である。フロア SW2 は p1（コア SW2 側）と p2（フロア SW1 側）の両方からルートの BPDU を受けており，下線④で p1 がブロッキングだったことから，ルートポートは p2 だったと分かる（コア SW1 → フロア SW1 → フロア SW2 p2 の経路）。

ケーブル1が切れるとフロア SW1 はルートへの経路を失い，ルートからの BPDU をフロア SW2 へ中継できなくなる。フロア SW2 から見ると，p2 でルートからの BPDU を受信しなくなる。保持していた情報が最大エージ（既定20秒）で消えると，フロア SW2 は p1 を新しいルートポートにし，p1 はリスニング，ラーニング（既定では各15秒の転送遅延）を経てフォワーディングになる。これが下線④の遷移である。

間違えやすい点。p1 はブロッキング中も BPDU を受けていたポートなので答えにならない。図2の字句で答えるので「p2」と書く。

本文の根拠

〔障害発生時の状況確認〕

ケーブル2の断線に伴って⑤フロア SW1 が送信した，リンク状態遷移を示す SYSLOG メッセージが監視サーバに到達できなかった。

〔障害発生時の状況確認〕

ケーブル1の断線によって，④フロア SW2 の p1 ポートの STP のポート状態がブロッキングから，リスニング，ラーニングを経て，フォワーディングに遷移した。

〔監視サーバの概要〕

リンクダウンなどの異常が発生した機器は，監視サーバに対して直ちに SYSLOG メッセージを送信する。

ケーブル1とケーブル2は同時に断線した。フロア SW1 はケーブル2のリンクダウンを検知して直ちに SYSLOG メッセージを送るが，そのときフロア SW1 から監視サーバへの経路は，ケーブル1が切れているのでフロア SW2 → コア SW2 を通るしかない。ところがフロア SW2 の p1 はまだブロッキングで，リスニング，ラーニングを経てフォワーディングになるまでフレームを転送しない。STP の再構築が終わるまでの間に送られた SYSLOG メッセージは，ここで捨てられた。

SYSLOG は UDP（設問1ウ）で送られ，送達確認も再送も無い。そのため一度失われたメッセージは監視サーバに届かず，ケーブル2のリンク状態遷移は検知されなかった。一方，ケーブル1のリンク状態遷移は，コア SW1 側から監視サーバへ送られたので検知できた。

25字に収める。解答例は「スパニングツリーが再構築中だったから」で18字。「スパニングツリー」を使う指定なので，「経路が切れていたから」ではなく，ツリーの再構築中（ポートがまだ転送状態でない）であったことを書く。

本文の根拠

〔ネットワーク監視の改善策の立案〕

SNMP は機器を管理するためのプロトコルで，⑥SNMP エージェントと SNMP マネージャで構成される。

〔監視サーバの概要〕

監視対象機器は，コア SW，サーバ SW 及びフロア SW である。

SNMP エージェントは管理される機器の側で動き，自分の MIB を保持して，問合せに応答したりトラップを送ったりする。SNMP マネージャは管理する側で，エージェントに問合せをし，通知を受け取る。

A 社で管理される側は監視対象機器，つまりコア SW1・コア SW2，サーバ SW，フロア SW1〜フロア SW4 で，このうちどれか一つを答えればよい。管理する側は監視サーバである。

間違えやすい点。図1中の機器名で答えるので，「コア SW」ではなく「コア SW1」のように図の名前で書く。SW1〜SW32 やファイルサーバは本文の監視対象機器に入っていないので避ける。

本文の根拠

〔ネットワーク監視の改善策の立案〕

ポーリングは，SNMP マネージャが，SNMP エージェントに対して，例えば5分ごとといった定期的に MIB の問合せを行うことによって，機器の状態を取得できる。

〔ネットワーク監視の改善策の立案〕

一方，トラップは，MIB に変化が起きた際に，SNMP エージェントが直ちにメッセージを送信し，SNMP マネージャがメッセージを受信することによって，機器の状態を取得できる。

〔ネットワーク監視の改善策の立案〕

C さんは，⑦5分間隔のポーリング，又はトラップを使用して監視しても，今回発生したネットワークの異常においてはそれぞれ問題があることが分かった。

ポーリング：マネージャが5分ごとに問い合わせるので，異常が起きてから次の問合せまで最大で5分近く気付けない。今回の障害は STP の再構築（数十秒）が終われば経路が戻るので，ポーリングならいずれは状態を取れるが，検知は多くの場合遅れる。トラップ：エージェントが変化を直ちに送るので速いが，SNMP は UDP で送られ，トラップには受信側からの確認応答が無い。今回のように STP の再構築中に送られると，SYSLOG と同じくメッセージが失われ，エージェントもそれに気付けない。

本文でポーリングは「例えば5分ごとといった定期的に」，トラップは「直ちにメッセージを送信し」とだけ書かれ，インフォームの説明で初めて「確認応答を待つ」「再送信を行う」が出てくる。この対比から，トラップの問題は確認応答（到達確認）が無いことだと読める。

35字に収める。解答例はポーリングが「5分ごとに状態を取得するので多くの場合異常検知が遅れる。」で28字，トラップが「到達確認がないのでメッセージが失われる可能性がある。」で26字。それぞれ「原因（5分間隔／到達確認なし）」と「結果（検知の遅れ／メッセージの消失）」を組にして書く。採点講評では的外れな解答が目立ったとされている。

採点講評（IPA）

設問4(2)ではSNMPポーリングとSNMPトラップの特徴を踏まえての解答を期待したが，的外れな解答が目立った。監視に用いられる技術の特徴を正しく把握することは，ネットワーク監視を設計する上で非常に重要である。ネットワーク技術者として是非知っておいてもらいたい。

本文の根拠

〔ネットワーク監視の改善策の立案〕

SNMP のインフォームでは，MIB に変化が起きた際に，SNMP エージェントが直ちにメッセージを送信し，SNMP マネージャからの確認応答を待つ。確認応答を受信できない場合，SNMP エージェントは，SNMP マネージャがメッセージを受信しなかったと判断し，メッセージの再送信を行う。

〔ネットワーク監視の改善策の立案〕

C さんは，⑧今回と同様なネットワークの異常が発生した場合に備えて，SNMP マネージャがインフォームの受信を行えるよう，SNMP エージェントの設定パラメタを考えた。

〔障害発生時の状況確認〕

ケーブル1の断線によって，④フロア SW2 の p1 ポートの STP のポート状態がブロッキングから，リスニング，ラーニングを経て，フォワーディングに遷移した。

インフォームは確認応答が来なければ再送するが，再送の回数と間隔（タイムアウト）には上限がある。今回と同じ異常では，STP の再構築が終わってフロア SW2 の p1 がフォワーディングになるまで，フロア SW1 から監視サーバへの経路が無い。再送をその前に打ち切ってしまえば，インフォームもトラップと同じく届かない。そこで，再送の回数と間隔を，スパニングツリーの再構築にかかる時間（IEEE 802.1D の既定値なら最大エージ20秒と転送遅延15秒×2で約50秒）を超えて再送し続けるように設定する。

本文は，インフォームが「確認応答を受信できない場合」に「再送信を行う」と説明したうえで，「今回と同様なネットワークの異常」に備えるパラメタを問うている。今回の異常とは，設問3(2)で見た「スパニングツリーの再構築中」に経路が無い状態である。

40字に収める。解答例は「スパニングツリーが再構築するまでインフォームの再送信を繰り返す。」で32字。「いつまで（再構築が終わるまで）」と「何をする（再送信を繰り返す）」を入れる。「インフォームを使う」だけでは設定パラメタの内容にならない。採点講評では正答率が低かったとされている。

採点講評（IPA）

設問4(3)は正答率が低かった。問題文をよく読み，設問で何が問われているかを正しく理解し，注意深く解答してほしい。

本文の根拠

(2) IP-VPN 及び IPsec の概要

利用者のネットワークと事業者閉域 IP 網との接続点において，利用者が設置する CE（Customer Edge）ルータから送られたパケットは，通信事業者の PE（Provider Edge）ルータで ［ ア ］ と呼ばれる短い固定長のタグ情報が付与される。

(2) IP-VPN 及び IPsec の概要

事業者閉域 IP 網内では，②タグ情報を参照して中継され，［ ア ］ は対向側の ［ イ ］ で取り除かれる。

(2) IP-VPN 及び IPsec の概要

IPsec は，OSI 基本参照モデルの ［ ウ ］ レイヤで動作する。

(1) WAN 構成の見直し方針案

通常時は拠点間通信に IP-VPN を用いるが，IP-VPN の障害時にはインターネット VPN をバックアップ回線として用いる。

〔冗長化ルーティングの検討〕

図2のネットワーク構成で拠点間通信を行う場合，正常時は ［ エ ］ を利用するが，［ エ ］ の障害時は ［ オ ］ に切り替える必要がある。

ア・イ：IP-VPN は MPLS（RFC 3031）で作られている。MPLS では，網の入口のルータがパケットに短い固定長のラベル（MPLS ヘッダの中の20ビットの値）を付け，網内のルータは IP ヘッダではなくラベルを見て転送する。利用者の CE ルータから受けたパケットにラベルを付けるのは入口の PE ルータで，網を出るときに対向側の PE ルータがラベルを取り除いて CE ルータへ渡す。ウ：IPsec は IP パケットを守るプロトコルで，IP と同じネットワーク層（第3層）で動作する。TLS のようにトランスポート層の上で動くものとは違う。エ・オ：方針案で，通常時の拠点間通信は IP-VPN，IP-VPN の障害時はバックアップ回線としてインターネット VPN を用いると決めている。

イは本文の字句で「PE ルータ」と答える（CE ルータは利用者側の機器で，ラベルを扱わない）。エ・オは本文の方針案の字句「IP-VPN」「インターネット VPN」をそのまま入れる。

間違えやすい点。アの「タグ」は本文の説明の言葉で，MPLS での正式な名前は「ラベル」である。ウは「ネットワーク層」でも「ネットワーク」でもよいが，「IP レイヤ」「第3」と書くより OSI の層の名前で書く。採点講評では設問1・設問2（MPLS の基本事項）の正答率が低かったとされている。

採点講評（IPA）

設問1及び設問2は，主にMPLSの基本事項について出題したが，正答率は低かった。MPLSはIP-VPNサービスの中核を成す技術であり，MPLSを理解することは，VPN技術を理解するためにも役に立つので基本は押さえておいてほしい。

本文の根拠

(2) IP-VPN 及び IPsec の概要

IP-VPN は，①事業者閉域 IP 網内で複数の利用者のトラフィックを中継するのに，RFC 3031 で規定された方式が用いられる。

RFC 3031 は「Multiprotocol Label Switching Architecture」，つまり MPLS のアーキテクチャを定めた RFC である。通信事業者の IP-VPN サービスは，この MPLS の上に，利用者ごとの経路を分けて配る仕組み（BGP/MPLS IP VPN，RFC 4364）を載せて提供されるのが一般的である。

本文の下線①が RFC 番号で方式を指定しており，続く箇条で「短い固定長のタグ情報」を付けて「タグ情報を参照して中継」する，というラベルスイッチングの特徴が説明されている。

間違えやすい点。「IP-VPN」や「ラベルスイッチング」ではなく，技術の名前として「MPLS」と答える。

採点講評（IPA）

設問1及び設問2は，主にMPLSの基本事項について出題したが，正答率は低かった。MPLSはIP-VPNサービスの中核を成す技術であり，MPLSを理解することは，VPN技術を理解するためにも役に立つので基本は押さえておいてほしい。

本文の根拠

(2) IP-VPN 及び IPsec の概要

IP-VPN は，通信事業者が運営する閉域 IP ネットワーク（以下，事業者閉域 IP 網という）を利用者のトラフィック交換に提供するサービスである。

(2) IP-VPN 及び IPsec の概要

IP-VPN は，①事業者閉域 IP 網内で複数の利用者のトラフィックを中継するのに，RFC 3031 で規定された方式が用いられる。

(2) IP-VPN 及び IPsec の概要

事業者閉域 IP 網内では，②タグ情報を参照して中継され

事業者閉域 IP 網には複数の利用者（企業）のトラフィックが流れる。各社はプライベート IP アドレスを使うので，A 社と B 社が同じ 10.0.0.0/8 を使っていることもあり，IP アドレスだけでは「どの利用者のパケットか」「どの拠点へ届けるか」を決められない。そこで入口の PE ルータが，利用者（VPN）を識別するラベルを付け，網内と出口の PE ルータはそのラベルを見て，利用者ごとに分けて中継する（BGP/MPLS IP VPN では，拠点ごとの VPN を識別するラベルと，網内を運ぶためのラベルを重ねて付ける）。

本文の下線①が「複数の利用者のトラフィックを中継する」場面であり，その中継でタグ情報を参照するのは，利用者どうしのトラフィックを混ぜないためである。

25字に収める。解答例は「利用者ごとのトラフィックを区別するため」で19字。「高速に転送するため」も MPLS の特徴ではあるが，ここは「利用者トラフィック中継処理において」と問われているので，利用者の区別を書く。

採点講評（IPA）

設問1及び設問2は，主にMPLSの基本事項について出題したが，正答率は低かった。MPLSはIP-VPNサービスの中核を成す技術であり，MPLSを理解することは，VPN技術を理解するためにも役に立つので基本は押さえておいてほしい。

本文の根拠

〔冗長化ルーティングの検討〕

各拠点間の IPsec トンネル及び各拠点内 LAN のルーティングは，OSPF を利用する。

〔冗長化ルーティングの検討〕

各拠点間の IPsec トンネル接続では，③GRE over IPsec を利用する。

OSPF はルータどうしが Hello やリンク状態の更新を IP マルチキャスト（224.0.0.5，224.0.0.6）で交換して隣接関係を作る（RFC 2328）。ところが IPsec のトンネル（特に拠点間 VPN でよく使う，宛先・送信元の範囲をポリシーで決める方式）は，ユニキャストの IP パケットを保護する前提で作られており，マルチキャストのパケットはそのままではトンネルに入れられない。そこで GRE（RFC 2784）でマルチキャストを含む任意のパケットをいったんユニキャストの GRE パケットに包み，その GRE パケットを IPsec で暗号化する。これが GRE over IPsec である。

本文では，IPsec トンネルの上で OSPF を動かすと決めている。OSPF を IPsec トンネル越しに動かすために必要なのが，マルチキャストを通せる GRE である。

25字に収める。解答例は「OSPFのマルチキャスト通信を通すため」で19字。「暗号化するため」は IPsec の役目で，GRE を重ねる理由にならない。採点講評では正答率が低かったとされている。

採点講評（IPA）

設問3(1)は，OSPFネットワーク内のIPsecトンネル上でのGRE over IPsecの利用についてその目的を出題したが，正答率は低かった。IPsecトンネル上でのGRE over IPsecの利用はOSPFネットワークでは必要な技術であるので，理解しておいてほしい。

本文の根拠

〔冗長化ルーティングの検討〕

CE ルータでもある各拠点の L3SW は，IP-VPN 側で隣接する PE ルータと BGP4 で経路交換する。具体的には，各拠点の L3SW は，自拠点の経路情報を PE ルータに広告するとともに，④PE ルータから経路情報を受信する。

各拠点の L3SW は自拠点のネットワークの経路を PE ルータに広告する。IP-VPN はこれを同じ利用者のほかの拠点の PE ルータへ配り，そこから各拠点の L3SW に届ける。したがって，ある拠点の L3SW が PE ルータから受け取るのは，IP-VPN を通って届く，ほかの拠点のネットワークへの経路である。

本文は「自拠点の経路情報を PE ルータに広告するとともに」と書いているので，受け取る側はその対になる「ほかの拠点」の経路情報だと分かる。

15字に収める。解答例は「ほかの拠点への経路情報」で11字。「IP-VPN の経路」「BGP の経路」では，どの宛先への経路かが書けていない。

本文の根拠

〔冗長化ルーティングの検討〕

図2のネットワーク構成で拠点間通信を行う場合，正常時は ［ エ ］ を利用するが，［ エ ］ の障害時は ［ オ ］ に切り替える必要がある。

〔冗長化ルーティングの検討〕

各拠点の L3SW は，⑤複数のルーティングプロトコルから得た同一宛先への異なる経路情報から，適切な経路を選択する。

〔冗長化ルーティングの検討〕

CE ルータでもある各拠点の L3SW は，IP-VPN 側で隣接する PE ルータと BGP4 で経路交換する。

各拠点の L3SW は，ほかの拠点への経路を2通りで知る。IP-VPN を通る経路は PE ルータから BGP4 で，インターネット VPN（IPsec トンネル）を通る経路は OSPF で届く。異なるルーティングプロトコルから同じ宛先の経路を得たとき，ルータはメトリックでは比べられないので，プロトコルごとの優先度（製品によって管理距離，ディスタンスなどと呼ぶ）で選ぶ。正常時は IP-VPN（エ）を使う方針なので，BGP4 から得た経路を OSPF から得た経路より優先させる。IP-VPN に障害が起きて BGP4 の経路が消えると，残った OSPF の経路（インターネット VPN）が使われ，自動で切り替わる。

本文の「正常時は ［ エ ］ を利用するが，［ エ ］ の障害時は ［ オ ］ に切り替える」が選択の基準で，「CE ルータでもある各拠点の L3SW は…BGP4 で経路交換する」が，IP-VPN の経路が BGP4 から来ることを示している。

25字に収める。解答例は「BGP4から得られた経路を優先する。」で18字。「IP-VPN を優先する」でも方針としては正しいが，問われているのは「複数のルーティングプロトコルから得た」経路の選び方なので，プロトコル名（BGP4）で書く。

本文の根拠

〔拠点追加の場合の IPsec トンネル接続追加の検討〕

図2のような⑥フルメッシュの IPsec トンネルのネットワーク構成に，追加拠点向け IPsec トンネルを手動で追加設定するネットワーク拡張方式は望ましくないと考え

(2) IP-VPN 及び IPsec の概要

3拠点間には，バックアップ回線として3本の IPsec トンネルが必要である。

フルメッシュでは全ての拠点の組に1本ずつトンネルを張るので，n 拠点では n(n−1)/2 本になる（3拠点で3本，4拠点で6本）。新しい拠点を1つ足すと，その拠点から既存の全拠点へのトンネルが要り，新拠点だけでなく既存の全拠点の FW にも対向の設定を追加しなければならない。拠点が増えるほど作業量と設定ミスの機会が増える。

本文の「3拠点間には…3本の IPsec トンネルが必要」と，図2で FW1・FW2・FW3 が互いに3本のトンネルで結ばれていることが，フルメッシュの構成の根拠である。

30字に収める。解答例は「新拠点追加のときに全拠点の設定変更が必要になるから」で25字。「トンネル数が増えるから」だけでなく，既存の全拠点の設定を変える必要がある，という運用上の負担まで書く。採点講評では正答率が高かったとされている。

採点講評（IPA）

設問4(1)は，フルメッシュなIPsecトンネルのネットワークにおける課題を出題したが，正答率は高かった。ネットワークトポロジに関する基本的な理解がうかがわれた。

本文の根拠

〔拠点追加の場合の IPsec トンネル接続追加の検討〕

NHRP は，IPsec トンネル確立に必要な対向側 IP アドレス情報を，トンネル確立時に動的に得るのに利用される。

〔拠点追加の場合の IPsec トンネル接続追加の検討〕

例えば，名古屋支店内の PC から大阪支店内のサーバへの通信が行われる場合，⑦名古屋支店の FW3 は NHRP によって得られた情報を利用して S-S トンネルを確立する。

NHRP（RFC 2332）は，トンネルの中で使う論理的なアドレス（トンネルインタフェースの IP アドレス）から，その相手に実際に届けるための下位網のアドレス（ここではインターネット上のアドレス）を引く仕組みである。スポークはハブに自分の対応を登録しておき，別のスポークと通信したくなったらハブに問い合わせて相手の実アドレスを得る。FW3 がトンネルを張る相手は大阪支店の FW2 で，IPsec の相手として指定するのは FW2 のインターネット側のアドレス，つまりグローバル IP アドレスである。

本文は NHRP を「IPsec トンネル確立に必要な対向側 IP アドレス情報」を得るものと説明している。例の通信は名古屋支店から大阪支店へなので，対向側は大阪支店の FW2 である。

25字に収める。解答例は「大阪支店のFW2のグローバルIPアドレス」で20字。「対向側の IP アドレス」だけでは足りず，どの機器の（大阪支店の FW2 の）どのアドレス（インターネット側のグローバル IP アドレス）かまで書く。

本文の根拠

〔拠点追加の場合の IPsec トンネル接続追加の検討〕

本社をハブ拠点，支店の2拠点をスポーク拠点とするハブアンドスポーク構成とし，ハブ拠点とスポーク拠点間の IPsec トンネルを従来どおり固定的に設定する。

〔拠点追加の場合の IPsec トンネル接続追加の検討〕

S-S トンネルは，一定時間トラフィックがなければ自動的に切断するようにする。

〔拠点追加の場合の IPsec トンネル接続追加の検討〕

“スポークとなる機器が OSPF の代表ルータに選出されてしまうと，スポーク拠点間の IPsec トンネルが解放されなくなってしまうので，それを防ぐために，スポークとなる機器の OSPF に追加の設定が必要になる”

OSPF のマルチアクセス網では代表ルータ（DR）を選び，ほかのルータは全て DR と隣接関係を結んで，Hello を交わし続ける（RFC 2328）。スポークの FW が DR になると，もう一方のスポークはその FW との間で OSPF の通信を続けるので，S-S トンネルに「一定時間トラフィックがない」状態が来ず，トンネルが切れなくなる。DR は常にハブ（本社）にあるべきなので，スポークの FW が DR（と BDR）に選ばれないようにする。OSPF のルータプライオリティを0にしたルータは DR・BDR の選出対象にならない。

本文でスポークは支店の2拠点で，図2でその FW は大阪支店の FW2 と名古屋支店の FW3 である。指摘の「スポークとなる機器が OSPF の代表ルータに選出されてしまうと」「スポークとなる機器の OSPF に追加の設定が必要」が，設定する機器と目的を示している。

設定は25字に収める。解答例は「OSPFのプライオリティを0に設定する。」で20字。値まで書く（「プライオリティを下げる」では，ほかに低い値の機器があると DR に選ばれうる）。機器は「全て答えよ」なので FW2 と FW3 の両方を書き，ハブの FW1 は入れない。