令和元年度 秋期 午後Ⅰ

本文の根拠

(1) 現行ネットワーク構成

接続先 ISP とデータセンタは異なる AS 番号で接続している。コアルータと ISP との間の冗長経路接続のためのルーティングプロトコルは，パスベクトル型ルーティングプロトコルである a が用いられている。

(1) 現行ネットワーク構成

OSPF エリアは一つであり，b エリアだけで構成されている。

(1) 現行ネットワーク構成

マスタルータが故障した際には，新しくマスタになったルータが c パケットをブロードキャストすることによって L2SW の MAC アドレステーブルを更新する。

a：異なる AS の間で経路を交換するのは EGP で，現在使われているのは BGP-4（RFC 4271）である。BGP は宛先までに通る AS の並び（AS_PATH 属性）を経路に付けて広告するのでパスベクトル型と呼ばれる。マルチホームで2つの ISP と接続するときに，AS_PATH などの属性でどちらの ISP から出入りするかを制御できる。

b：OSPF（RFC 2328）ではエリア0をバックボーンエリアと呼び，エリアを複数に分けるときは他のエリアを必ずバックボーンエリアにつなぐ。エリアが一つだけなら，そのエリアがバックボーンエリア（エリア0）になる。

c：VRRP（RFC 5798）の仮想ルータは仮想 MAC アドレスを使う。マスタが切り替わると，新しいマスタは送信元 MAC アドレスを仮想 MAC アドレスにした Gratuitous ARP（GARP：自分の IP アドレスを問い合わせる ARP）をブロードキャストする。途中の L2SW はこのフレームを受け取って，仮想 MAC アドレスの学習先ポートを新しいマスタ側に付け替える。

間違えやすい点。a は“パスベクトル型”が決め手で，距離ベクトル型の RIP やリンクステート型の OSPF と取り違えない。c は“ARP”だけでは足りない。応答を求めない通知であることを表す“Gratuitous”（GARP）まで書く。

本文の根拠

(1) 現行ネットワーク構成

L3SW 同士を接続している回線は，独立した IP セグメントになっている。

(1) 現行ネットワーク構成

L3SW の L2SW への接続ポートにはタグ VLAN を設定し，CR 経由で顧客セグメントを接続している。L3SW は VRRP によって L3SW1 と L3SW2，L3SW3 と L3SW4 がそれぞれ対になるように冗長化しており，マスタルータは L3SW1，L3SW3 である。

(1) 現行ネットワーク構成

CR に顧客が設定したデフォルトルートのネクストホップは，L3SW で構成される VRRP の仮想ルータの IP アドレス

VRRP の仮想ルータは，CR のデフォルトルートのネクストホップになる IP セグメント，つまり顧客ごとの VLAN（L3SW の L2SW 側のポート）に作られている。VRRP のアドバタイズメントは，その VLAN の中にマルチキャスト（224.0.0.18，RFC 5798）で送られる。したがって L3SW1 と L3SW2 の間のアドバタイズメントは，顧客の VLAN が通る L3SW1 −キ− L2SW1 −ケ− L2SW2 −ク− L3SW2 の経路を通る。

L3SW1 と L3SW2 を直接結ぶ回線カは“独立した IP セグメント”で，顧客の VLAN とは別のセグメントである。VRRP のアドバタイズメントはルータを越えず，そのセグメント内にしか届かないので，カは通らない。コ〜スは L2SW と CR の間の回線で，L3SW どうしの間には入らない。

間違えやすい点。L3SW1 と L3SW2 が直接つながっている回線カを答えてしまいやすい。VRRP はどのセグメントで仮想ルータを作っているかを本文から確かめる。採点講評でも正答率が低かったとされている。

採点講評（IPA）

設問1(2)は，正答率が低かった。VRRPを構成する2台の装置がどの回線を経由して，互いの正常性を確認し合うかは，VRRPを用いて冗長性を確保するに当たり重要な点であるので，よく理解しておいてほしい。

本文の根拠

(1) 現行ネットワーク構成

L2SW は顧客セグメントを収容するためのスイッチであり，各顧客セグメントへの接続のために，顧客ごとに一つの VLAN を割り当て，2 台の L2SW のそれぞれから CR に接続し，冗長性を確保している。

(1) 現行ネットワーク構成

L3SW の L2SW への接続ポートにはタグ VLAN を設定し，CR 経由で顧客セグメントを接続している。

1本の回線に複数の VLAN のフレームを通すときは，どの VLAN のフレームかを区別するために IEEE 802.1Q の VLAN タグを付ける必要がある。1本の回線に1つの VLAN しか通らないなら，タグを付けずにポート VLAN（アクセスポート）で済む。

図1で顧客全員の VLAN が通るのは，L3SW1 と L2SW1 の間（キ），L3SW2 と L2SW2 の間（ク），L2SW1 と L2SW2 の間（ケ）である。本文も“L3SW の L2SW への接続ポートにはタグ VLAN を設定し”としている。L2SW と CR の間（コ〜ス）はその顧客の VLAN だけが通るので，タグは必須ではない。ア〜カはルータや L3SW どうしをつなぐ回線で，顧客の VLAN は通らない。

間違えやすい点。ケは L2SW どうしの回線なので見落としやすい。設問1(2)でアドバタイズメントがケを通る（=顧客の VLAN がケを通る）ことと合わせて考えると，(2)と(3)の答えは同じになる。

本文の根拠

(1) 現行ネットワーク構成

ビル管理会社が提供する M/C には，1000BASE-LX 側 IF がリンクダウンしたときに 1000BASE-T 側 IF を自動でリンクダウンさせる機能はない。

(2) 増強案

① Link Aggregation Control Protocol（以下，LACP という）を設定する。

静的 LAG は，メンバの回線がリンクアップしているかどうかだけで，その回線を LAG に含めるかを決める。LACP（IEEE 802.1AX，旧 802.3ad）は，両端の装置が LACPDU を定期的に交換し，相手から LACPDU が届かなくなった回線を LAG のメンバから外す。

本文の M/C は，光ファイバ（1000BASE-LX）側が切れても 1000BASE-T 側のリンクを落とさない。L3SW やコアルータから見るとリンクは上がったままなので，静的 LAG では切れた回線にもフレームを振り分け続け，そのフレームは失われる。LACP なら LACPDU が届かないことで故障を検知し，その回線を自動で除外できる。

50字に収める。解答例は41字。要素は“リンクダウンを伴わない故障”と“故障回線を LAG のメンバから自動で除外できる”の2つ。“障害を検知できる”だけでは，静的 LAG でもリンクダウンなら検知できるので，M/C の特性に結び付けた前半が要る。採点講評でも正答率が低かったとされている。

採点講評（IPA）

設問1(4)は，正答率が低かった。LAGの利用時にLACP（Link Aggregation Control Protocol）を用いるのは一般的な構成であるが，なぜLACPを利用するのか，把握しておいてほしい。

本文の根拠

(2) 増強案

ビル 4 階の顧客について，ISP を経由する合計トラフィック量は，新規の顧客セグメントを含めて最大 2G ビット／秒とする。

(2) 増強案

Z 社データセンタ内の回線が 1 か所切れた場合でも，トラフィックを輻輳させない。

(2) 増強案

LAG を構成する回線のうち 1 本が切れた場合には，②切れた回線を含む同一 LAG を構成する IF 全てを自動的に閉塞するように設定する。

L3SW3 と L2SW3 の間は 1000BASE-T の回線2本を LAG で束ね，2G ビット／秒を流せるようにする。1本が切れた後も LAG を残すと，その区間は 1G ビット／秒しか流せない。ビル4階の顧客のトラフィックは最大 2G ビット／秒なので，1G ビット／秒を超えた分のパケットは廃棄される。

LAG の IF を全て閉塞すると，L3SW3 と L2SW3 の間が完全に切れる。すると VRRP のアドバタイズメントが L3SW4 に届かなくなって L3SW4 がマスタになり，トラフィックは 2 本の回線がそろった L2SW3 −L2SW4− L3SW4 側の LAG（2G ビット／秒）へ移る。設計方針の“回線が 1 か所切れた場合でも，トラフィックを輻輳させない”を満たすための閉塞である。

25字に収める。解答例は22字。“パケット”の字句を使う指定なので，“輻輳する”ではなく“1Gビット／秒を超えたパケットが廃棄される”と，帯域が半分になる結果をパケットの側から書く。

本文の根拠

(2) 増強案

Z 社の装置では，ハッシュ関数は［送信元 MAC アドレス，宛先 MAC アドレス］の組から計算する方法と，［送信元 IP アドレス，宛先 IP アドレス，送信元ポート番号，宛先ポート番号］の組から計算する方法の 2 通りが選択できる。

(2) 増強案

C さんは，コアルータからビル 4 階の L2SW までの回線帯域の増強を検討する必要があると考え，回線を追加し，リンクアグリゲーション（以下，LAG という）で二つの回線を束ねる方式に関して，次のように検討した。

LAG はフレームごとにハッシュ値を計算し，その値で送り出す回線を決める。同じハッシュ値のフレームは同じ回線を通るので，入力の組合せが少ないと回線の使い方が偏る。

図1で LAG を組むのはコアルータと L3SW の間，L3SW と L2SW の間などである。コアルータと L3SW の間はルータどうしの接続なので，フレームの MAC アドレスはどの通信でもコアルータと L3SW の2つの組合せしかない。L3SW と L2SW の間も，L3SW（仮想ルータ）と少数の CR の MAC アドレスの組合せしかない。MAC アドレスの組でハッシュ値を計算すると値がほとんど分散せず，1本の回線に通信が集中する。IP アドレスとポート番号の組なら，通信（コネクション）ごとに値が変わるので分散する。

50字に収める。解答例は42字。要素は“送信元と宛先 MAC アドレスの組合せが少ない”と“ハッシュ関数の計算値が分散しない”の2つ。理由を問われているので“〜から”で結ぶ。

本文の根拠

〔自社サービス提供状況の把握〕

(ⅰ) d プロトコルを利用した ping によって，各監視対象装置の管理 IF の IP アドレスに対して死活監視を行う。

〔自社サービス提供状況の把握〕

(ⅱ) SNMP によって，各監視対象装置からの状態変更通知である e を受信する。

〔自社サービス提供状況の把握〕

(ⅲ) SNMP によって，各監視対象装置から 5 分ごとに管理情報ベースである f を取得する。

d：ping は ICMP（RFC 792）の Echo Request を送り，Echo Reply が返るかで相手の到達性を確かめる。

e：SNMP で，監視対象装置（エージェント）の側から状態の変化（リンクダウンなど）を監視装置（マネージャ）に知らせるメッセージがトラップ（SNMP trap）である。マネージャから問い合わせるのではなく，エージェントから自発的に送る。

f：SNMP で取得する管理情報の集まりを MIB（Management Information Base）と呼ぶ。インタフェースの送受信バイト数などのカウンタが入っている。

間違えやすい点。e の“状態変更通知”は装置側から送る通知なので，マネージャが値を読み出す GetRequest ではなくトラップである。解答例は“SNMPトラップ”と“SNMP trap”のどちらでもよいとしている。

採点講評（IPA）

設問2は正答率が高かった。監視方式についての理解が高いことがうかがえた。

本文の根拠

〔自社サービス提供状況の把握〕

(ⅲ) SNMP によって，各監視対象装置から 5 分ごとに管理情報ベースである f を取得する。

〔自社サービス提供状況の把握〕

(ⅰ) d プロトコルを利用した ping によって，各監視対象装置の管理 IF の IP アドレスに対して死活監視を行う。

回線ごとのトラフィック量は，装置の物理インタフェースごとの送受信バイト数のカウンタ（IF-MIB の ifHCInOctets／ifHCOutOctets など，RFC 2863）で分かる。これを(ⅲ)の方法で5分ごとに取得し，前回との差を取れば，LAG を構成する回線1本ずつの5分間の平均トラフィック量が求まる。

(ⅰ)の ping は管理 IF に届くかどうかを確かめるだけで，データの流れる回線の量は分からない。(ⅱ)のトラップは状態が変わったときの通知で，量を継続して知ることはできない。

間違えやすい点。答えは本文の表記に合わせて(ⅲ)とローマ数字で答える。LAG 全体ではなく“各回線”の量を問われているが，MIB はメンバの物理インタフェースごとにカウンタを持つので(ⅲ)で足りる。

採点講評（IPA）

設問2は正答率が高かった。監視方式についての理解が高いことがうかがえた。

本文の根拠

〔自社サービス提供状況の把握〕

監視装置を，新規に設置する L2SWz2 経由で各コアルータに接続し，監視装置から顧客のデータが流れるネットワークへのパケットの疎通を確保する。

〔自社サービス提供状況の把握〕

監視装置を送信元，L3SW の VRRP の仮想 IP アドレスを宛先とする ping によって監視を行う。

〔自社サービス提供状況の把握〕

監視対象装置では管理 IF と他の IF との間でルーティングすることはできない。

追加する ping は，監視装置から L2SWz2 を経てコアルータに入り，顧客のデータが流れるネットワークを通って L3SW の VRRP の仮想 IP アドレス（そのときのマスタルータ）に届く。応答が返れば，コアルータから L3SW までの顧客のデータの経路が実際に通信できることを確かめられる。

現行の監視は管理 IF に対して行っており，管理 IF と他の IF の間ではルーティングしないので，顧客のデータが流れる経路の正常性は分からない。図2で L2SWz2 がコアルータの管理 IF（黒丸）ではなく装置そのものにつながっているのは，データのネットワーク側の IF に入れるためである。また仮想 IP アドレス宛てにすることで，VRRP でマスタが切り替わっても，その時点で顧客へのサービスを提供している L3SW までの経路を確かめられる。

間違えやすい点。本文中の字句で答える指定なので，“監視装置”や“CR”を起点・終点にしない。ping の宛先は L3SW の仮想 IP アドレスなので終点は L3SW，顧客のデータのネットワークへの入口はコアルータである。

採点講評（IPA）

設問2は正答率が高かった。監視方式についての理解が高いことがうかがえた。

本文の根拠

〔WAF サービス導入の検討〕

A 社 DNS サーバに，RDATA に IP-w1 を設定した A レコードを登録する方式と，RDATA に T 社 WAF サービスの FQDN を設定した CNAME レコードを登録する方式がある。

〔WAF サービス導入の検討〕

T 社は，IP-w1 を変更する場合があるので，① CNAME レコードを登録する方式を推奨している。

図2

“waf-asha.tsha.net.”は，A 社 Web システムで WAF サービスを利用するために，T 社から割り当てられた FQDN である。

CNAME レコード（RFC 1034）は，ある名前が別の名前の別名であることを表す。shop.asha.com を waf-asha.tsha.net. の別名にしておくと，リゾルバは続けて waf-asha.tsha.net の A レコードを引き，その時点の IP-w1 を得る。waf-asha.tsha.net の A レコードは T 社が自分のゾーン（tsha.net）で管理している。

T 社は IP-w1 を変更する場合がある。A 社の DNS サーバに IP-w1 を直接書いた A レコードを登録すると，IP-w1 が変わるたびに A 社がゾーンファイルを書き換えなければならず，書き換えが遅れると利用者が WAF サービスに届かなくなる。CNAME なら T 社が自分の A レコードを変えるだけで済み，A 社の DNS サーバは変更しなくてよい。

45字に収める。解答例は35字。“T 社が IP-w1 を変更しても”という条件と“A 社 DNS サーバの変更作業が不要”という利点を1文に入れる。T 社にとっての利点ではなく，“A 社にとっての利点”を書く。

採点講評（IPA）

設問1は，正答率が高かった。CNAMEレコードを登録すれば，WAFサービスのIPアドレスが変わったとしても，A社のゾーンファイルの変更が不要であることを是非知っておいてもらいたい。

本文の根拠

〔LB に関する検討〕

HTTP リクエストの振分け機能について，U さんは，HTTP リクエストを Web サーバに ［ ア ］ に振り分けるラウンドロビン方式を採用することにした。

〔LB に関する検討〕

U さんは，LB と Web サーバ間の通信に HTTP を用い，ポート番号に HTTP のウェルノウンポート番号を用いることにした。

表1

メッセージ“HTTP リクエスト”：宛先 IP アドレスは Web サーバの IP アドレス，ポート番号は ［ イ ］，メソッドは GET，パス名は /index.php。メッセージ“成功時の HTTP レスポンス”：ステータスコードは ［ ウ ］。

〔LB に関する検討〕

LB は，HTTP レスポンスの ［ エ ］ ヘッダフィールドにセッション ID を追加する。HTTP レスポンスを受け取った利用者の Web ブラウザは，［ エ ］ ヘッダフィールドにあるセッション ID を，次に送信する HTTP リクエストの ［ オ ］ ヘッダフィールドに追加する。

ア：ラウンドロビン方式は，リクエストを Web サーバ1，2，…，8，1，… と順番に振り分ける方式である。

イ：死活監視のリクエストは LB から Web サーバへ送る。LB と Web サーバの間は HTTP で，ポート番号は HTTP のウェルノウンポート番号とされているので 80 である。

ウ：GET で /index.php を取得して成功したときの HTTP のステータスコードは 200（OK）である（RFC 9110）。レイヤ7方式の死活監視は，この応答が返るかで WebAP が動いているかを確かめる。

エ，オ：Cookie（RFC 6265）は，サーバが HTTP レスポンスの Set-Cookie ヘッダフィールドで値を渡し，ブラウザが以後の HTTP リクエストの Cookie ヘッダフィールドでその値を送り返す仕組みである。LB は Set-Cookie でセッション ID を渡し，Cookie で戻ってきたセッション ID を見て同じ Web サーバに振り分ける。

間違えやすい点。イは利用者から見た HTTPS の 443 ではない。表1の宛先は Web サーバで，LB と Web サーバの間は HTTP である。エとオはレスポンス側が Set-Cookie，リクエスト側が Cookie と名前が違う。

本文の根拠

〔WAF サービス導入の検討〕

XFF ヘッダへの追加後に，HTTP リクエストの送信元 IP アドレスを，HTTP レスポンスが WAF サービスに送られるようにするための IP アドレス（以下，IP-w2 という）に変更する。

〔LB に関する検討〕

セッション維持機能には，HTTP リクエストの送信元 IP アドレスに基づいて行う方式と，LB によって生成されるセッション ID に基づいて行う方式がある。

WAF サービスは，転送する HTTP リクエストの送信元 IP アドレスを IP-w2 に変える。そのため LB に届くリクエストは，どの利用者からのものでも送信元 IP アドレスが IP-w2 になる。送信元 IP アドレスでセッションを維持すると，全てのリクエストが同じ利用者のものとみなされ，最初に振り分けた1台の Web サーバに集中する。Web サーバを8台に増設しても負荷が分散されない。

セッション ID（Cookie）に基づく方式なら，利用者のブラウザごとに異なるセッション ID が付くので，送信元 IP アドレスが同じでも利用者ごとに振り分けられる。

10字に収める。解答例は“負荷が偏る。”の6字。採点講評によると，“セッションの切断”などセッション自体の問題と誤った解答が多かった。送信元 IP アドレスが IP-w2 にそろうことから，起きるのは負荷の集中である。

採点講評（IPA）

設問2(2)は，正答率が低かった。“セッションの切断”など，セッション自体に問題が発生すると誤って解答した受験者が多かった。負荷分散装置が受信する通信の送信元IPアドレスは，WAFサービスのIPアドレスである。このような状況において，負荷分散装置が送信元IPアドレスに基づくセッション維持を行うと，特定のWebサーバに負荷が集中する問題が発生することを理解してほしい。(3)は，正答率が低かった。Cookieの利用，X-Forwarded-Forヘッダフィールドへの追加を行うためには，負荷分散装置で復号処理が必要であることを理解してほしい。

本文の根拠

〔LB に関する検討〕

A 社が導入する LB は，HTTP リクエストの振分け機能，死活監視機能，セッション維持機能，TLS アクセラレーション機能，HTTP ヘッダの編集（追加，変更，削除）機能をもっている。

〔LB に関する検討〕

U さんは，TLS の暗号化・復号処理の性能向上の目的と，③ LB が行うある処理のために，TLS アクセラレーション機能を利用することにした。

〔WAF サービス導入の検討〕

WAF サービスは，HTTP リクエストを再度 HTTPS で暗号化して，Web システムにアクセスするための IP アドレスである 199.α.β.2 宛てに転送する。

WAF サービスから LB（199.α.β.2）へのリクエストは HTTPS で暗号化されている。LB がセッション ID を Set-Cookie ヘッダフィールドに追加したり，Cookie ヘッダフィールドのセッション ID を読んだり，XFF ヘッダに情報を加えたりするには，HTTP のヘッダを平文で扱える必要がある。そのために LB で TLS を終端して復号する。つまり下線③の処理は HTTP ヘッダの編集である。

LB と Web サーバの間は HTTP にしているので，LB が TLS の終端になる。TLS アクセラレーション機能は，この復号と暗号化を専用ハードウェアで行って LB の負荷を下げる。

20字に収める。解答例は14字。本文の“HTTP ヘッダの編集（追加，変更，削除）機能”を“処理”の形に言い換える。“TLS の復号”は性能向上の目的と重なり，問われている“ある処理”にならない。

採点講評（IPA）

設問2(2)は，正答率が低かった。“セッションの切断”など，セッション自体に問題が発生すると誤って解答した受験者が多かった。負荷分散装置が受信する通信の送信元IPアドレスは，WAFサービスのIPアドレスである。このような状況において，負荷分散装置が送信元IPアドレスに基づくセッション維持を行うと，特定のWebサーバに負荷が集中する問題が発生することを理解してほしい。(3)は，正答率が低かった。Cookieの利用，X-Forwarded-Forヘッダフィールドへの追加を行うためには，負荷分散装置で復号処理が必要であることを理解してほしい。

本文の根拠

〔WAF サービス導入の検討〕

U さんは，FW に設定している Web システムへのアクセス制御について，IP-w2 を送信元とする通信だけを許可するように，設定を変更することにした。

図1

インターネットから Web システムへの通信について，DNS と HTTPS だけを許可するアクセス制御を，FW に設定している。

〔WAF サービス停止時の対応検討〕

U さんは，WAF サービスを経由せずに，利用者の Web ブラウザと Web システム間で直接通信させるために，WAF サービス導入時に設定変更を予定している ［ カ ］ の④設定を変更することと，図 2 中の⑤資源レコードの 1 行を書き換えることで対応できると考えた。

WAF サービスの導入時に設定を変える機器は FW である。FW は Web システムへの通信を IP-w2 を送信元とするものだけに絞る。WAF サービスを経由せずに利用者のブラウザから直接アクセスさせると，送信元は利用者ごとの IP アドレスになるので，この設定のままでは FW で遮断される。そこで，導入前と同じように，任意の IP アドレスから Web システムへの HTTPS 通信を許可する設定に戻す。

図1の注記では，導入前の FW はインターネットから Web システムへの DNS と HTTPS を許可していた。DNS はゾーンファイルの参照に必要で，WAF サービスの有無とは関係なく許可したままである。変えるのは HTTPS の送信元の条件だけである。

変更内容は35字に収める。解答例は33字。“送信元を任意の IP アドレスにする”ことと“Web システムへの HTTPS 通信を許可する”ことの2つを入れる。“全ての通信を許可する”と書くと，DNS と HTTPS に絞っていた制御まで外すことになる。

採点講評（IPA）

設問3(1)は正答率が高く，(2)(3)は低かった。WAFサービスのようなSaaSが停止したときの対応を，検討しておくことは重要である。状況記述を正確に読み取って正答を導き出してほしい。

本文の根拠

図2

“shop IN CNAME waf-asha.tsha.net.”

図3

L2SW に DNS サーバ（199.α.β.1，ns.asha.com）と LB（199.α.β.2，shop.asha.com）が接続している。

今は shop.asha.com を WAF サービスの FQDN の別名（CNAME）にしているので，利用者のブラウザは WAF サービス（IP-w1）にアクセスする。WAF サービスを経由させないためには，shop.asha.com が Web システムの入口の IP アドレスを直接指すようにする。図3で shop.asha.com に当たる LB の IP アドレスは 199.α.β.2 なので，CNAME の行を A レコード“shop IN A 199.α.β.2”に書き換える。

WAF サービスも 199.α.β.2 宛てにリクエストを転送しており，これが Web システムにアクセスするための IP アドレスである。同じ名前に CNAME と A レコードを同時に置くことはできない（RFC 1034 は CNAME のある名前に他のデータを置かないとしている）ので，行を追加するのではなく1行を書き換える。

間違えやすい点。IP アドレスは Web サーバの 192.168.1.x ではなく，LB のグローバル IP アドレス 199.α.β.2 である。$ORIGIN が asha.com. なので，名前は“shop”と書けばよい。なお，$TTL が 3600 秒なので，書き換えた後もキャッシュが切れるまで最大1時間は古い CNAME が使われうる。

採点講評（IPA）

設問3(1)は正答率が高く，(2)(3)は低かった。WAFサービスのようなSaaSが停止したときの対応を，検討しておくことは重要である。状況記述を正確に読み取って正答を導き出してほしい。

本文の根拠

〔WAF サービス導入の検討〕

WAF サービスは，アクセスを許可した HTTP リクエストの送信元 IP アドレスを，HTTP ヘッダの X-Forwarded-For ヘッダフィールド（以下，XFF ヘッダという）に追加する。

〔WAF サービス導入の検討〕

U さんは，送信元 IP アドレスの代わりに XFF ヘッダの情報を記録するように，WebAP の設定を変更することにした。

〔WAF サービス停止時の対応検討〕

U さんは，WebAP のアクセスログについて，WAF サービスの有無にかかわらず，XFF ヘッダの情報から Web システムへのアクセス時の送信元 IP アドレスを記録することとし，⑥ LB に設定を追加した。

WAF サービスを経由するときは，WAF サービスが利用者の IP アドレスを XFF ヘッダに入れてくれる。WAF サービスを経由しないときは XFF ヘッダが付かないので，WebAP は XFF ヘッダから送信元を記録できない。また，LB を経由すると Web サーバから見た送信元は LB になる。そこで LB で，受け取った HTTP リクエストの送信元 IP アドレスを XFF ヘッダに追加する。

こうすると，WAF サービス停止中は利用者の IP アドレスが，WAF サービス経由のときは WAF サービスが入れた利用者の IP アドレスに続いて IP-w2 が XFF ヘッダに入る。どちらの場合も WebAP は XFF ヘッダから送信元を記録できる。LB は HTTP ヘッダの編集機能をもち，設問2(3)のとおり TLS を終端しているので，この追加ができる。

30字に収める。解答例は23字。“XFF ヘッダに”“送信元 IP アドレスを追加する”の2点を書く。“XFF ヘッダを有効にする”のように何を入れるかが抜けると設定内容にならない。

採点講評（IPA）

設問3(1)は正答率が高く，(2)(3)は低かった。WAFサービスのようなSaaSが停止したときの対応を，検討しておくことは重要である。状況記述を正確に読み取って正答を導き出してほしい。

本文の根拠

図1 の概要

① PC の IP アドレスは，DHCP サーバによって割り当てられる。

図1 の概要

PC を接続する LAN は，各フロア二つ，計四つのセグメントに分かれている。

図1

二つ目のセグメントでは，L2SW02 にメンテナンスサーバ，DHCP サーバ，PC 管理サーバが接続している。

PC は IP アドレスを持たない状態で DHCPDISCOVER をブロードキャストする。ブロードキャストはルータ（L3SW）を越えないので，DHCP サーバが別のセグメントにあると届かない。そこで PC のセグメントのルータが DHCP リレーエージェント（RFC 1542，RFC 2131）として働き，受け取った DHCP メッセージをユニキャストで DHCP サーバに転送する。リレーエージェントは転送するメッセージの giaddr に受信したインタフェースの IP アドレスを入れ，DHCP サーバはそれを見てどのセグメント用のアドレスを払い出すかを決める。

図1で PC のセグメントを収容しているルータは，フロア1の L3SW1 とフロア2の L3SW2 である。DHCP サーバはサーバ室の L2SW02 のセグメントにある。リレーエージェントから DHCP サーバまではユニキャストなので，途中の L3SW0 は普通にルーティングするだけで，リレーエージェントを有効にする必要はない。

間違えやすい点。台数が最少になるよう選ぶ指定なので，L3SW0 を含めない。採点講評でも不必要なスイッチを含んだ解答が多かったとされている。L2SW はルータではないのでリレーエージェントにならない。

採点講評（IPA）

設問1では，不必要なスイッチを含んだ解答が多く見られた。DHCPリレーエージェント‐DHCPサーバ間はユニキャスト通信であるので，特殊な場合を除き，経路上の機器に影響しないことを理解しておいてほしい。

本文の根拠

〔LAN 通信制限方法の検討〕

正常 PC だけに IP アドレスを付与するよう，DHCP サーバに機能追加する。

〔LAN 通信制限方法の検討〕

②DHCP サーバから IP アドレスを取得した PC だけが通信可能となるように，各フロアの L2SW で DHCP スヌーピングを有効にする。

案1の DHCP サーバは，排除対象 PC に IP アドレスを払い出さない。しかし PC の利用者が IP アドレスを手で設定（固定設定）すれば，DHCP を使わずにそのセグメントで通信できてしまう。DHCP サーバだけでは，DHCP を使う PC しか制限できない。

DHCP スヌーピングを有効にした L2SW は，DHCP のやり取りを見て，どのポートにどの IP アドレス（と MAC アドレス）が払い出されたかを記録し，払い出されていない送信元 IP アドレスのパケットを捨てる。これで固定設定した PC の通信を止められる。

35字に収める。解答例は29字。要素は“IP アドレスを固定設定すれば”という抜け道と“正常 PC 以外でも通信できる”という結果の2つ。

採点講評（IPA）

設問2(1)(2)で取り上げた方式は，比較的容易に導入できるLAN不正利用対策の一つとして，覚えておいてほしい。(1)は正答率が高く，DHCPサーバだけでは課題があることは，よく理解されているようである。(2)は，(1)の解決策であるDHCPスヌーピングに関する設問であるが，正答率は低かった。両者を併せて理解しておいてほしい。

本文の根拠

〔LAN 通信制限方法の検討〕

②DHCP サーバから IP アドレスを取得した PC だけが通信可能となるように，各フロアの L2SW で DHCP スヌーピングを有効にする。

図1

L3SW1 は L2SW11，L2SW15，L2SW21，L2SW25 に線でつながっている。

DHCP スヌーピングでは，DHCP サーバからの応答（DHCPOFFER，DHCPACK）を受け付けてよいポートを“信頼するポート（trust ポート）”として設定し，それ以外のポートから来た DHCP サーバの応答は捨てる。これで偽の DHCP サーバを防ぐ。また，払い出しを記録していない送信元のパケットを捨てる制限も，PC をつなぐポートにかける。

フロアの L2SW から見ると，DHCP サーバの応答はリレーエージェントである L3SW1，L3SW2 から届く。L3SW と接続するポートを信頼するポートにしないと，正規の DHCP サーバの応答まで捨てられ，PC は IP アドレスを取得できない。L3SW のポートから来るパケットは送信元がルータやサーバで，払い出しの記録もないので，その制限も受けないようにする。

25字に収める。解答例は20字。“DHCP スヌーピングの制限を受けない”と書けば，信頼ポートの設定の意味が伝わる。採点講評によると正答率は低かった。

採点講評（IPA）

設問2(1)(2)で取り上げた方式は，比較的容易に導入できるLAN不正利用対策の一つとして，覚えておいてほしい。(1)は正答率が高く，DHCPサーバだけでは課題があることは，よく理解されているようである。(2)は，(1)の解決策であるDHCPスヌーピングに関する設問であるが，正答率は低かった。両者を併せて理解しておいてほしい。

本文の根拠

〔LAN 通信制限方法の検討〕

排除対象 PC が送信した ARP 要求を検出すると，排除対象 PC のパケット送信先が通信制限装置となるように偽装した ARP 応答を送信する。同時に，排除対象 PC 宛てパケットの送信先が通信制限装置となるように偽装した ARP 要求を送信する。

表1

送信元ハードウェアアドレス：排除対象 PC の MAC アドレス，a，c。送信元プロトコルアドレス：排除対象 PC の IP アドレス，b，d。

ARP（RFC 826）を受け取った機器は，送信元プロトコルアドレス（IP アドレス）と送信元ハードウェアアドレス（MAC アドレス）の組を ARP テーブルに覚える。ARP スプーフィングは，この組を偽って覚えさせる手法である。

a，b（ARP 応答）：排除対象 PC はアドレス解決対象の IP アドレスの MAC アドレスを尋ねている。応答の送信元を“アドレス解決対象の IP アドレス（b：ア）”と“通信制限装置の MAC アドレス（a：エ）”の組にすると，排除対象 PC はその IP アドレス宛てのフレームを通信制限装置に送る。

c，d（ARP 要求）：今度はセグメント内の相手に“排除対象 PC の IP アドレス（d：オ）”と“通信制限装置の MAC アドレス（c：エ）”の組を覚えさせる。送信先プロトコルアドレスのアドレス解決対象の機器はこの要求を受けて ARP テーブルを更新し，排除対象 PC 宛てのフレームを通信制限装置に送るようになる。

間違えやすい点。a と c はどちらも“エ”で，偽装していても送信元ハードウェアアドレスは通信制限装置自身の MAC アドレスである。偽るのは IP アドレスの側で，応答では相手の（アドレス解決対象の），要求では排除対象 PC の IP アドレスを名乗る。

採点講評（IPA）

(3)は，正答率が低かった。ARPの詳細な仕様を覚えていなくても，IPアドレスからMACアドレスを得るプロトコルであることを理解していれば，正答を導き出せるはずである。

本文の根拠

〔通信制限装置の導入〕

通信制限装置の LAN ポート数は 4 であり，各 LAN ポートの接続先は，全て異なるセグメントでなければならない。

〔通信制限装置の導入〕

③タグ VLAN を使用せず，フロア間の配線も追加しない構成

図1 の概要

PC を接続する LAN は，各フロア二つ，計四つのセグメントに分かれている。

ARP スプーフィングは ARP の届く範囲，つまり同じセグメントの中でしか働かないので，通信制限装置は監視する全てのセグメントに LAN ポートをつなぐ必要がある。PC のセグメントはフロア1に2つ，フロア2に2つの計4つである。

LAN ポートは4つあるので，数だけなら1台で4セグメントに足りる。しかしフロア間の配線を追加しないので，1台の装置からもう一方のフロアのセグメントへはつなげない。タグ VLAN を使わないので，1本の配線で複数のセグメントを通すこともできない。したがって各フロアに1台ずつ置き，それぞれのフロアの2つのセグメントに1ポートずつつなぐ。最少台数は2台である。

間違えやすい点。“ポート数4 ÷ セグメント数4 = 1台”としない。サーバ室の対策は考えなくてよいとされているので，サーバ室の分は数えない。

本文の根拠

〔通信制限装置の導入〕

④通信制限装置を接続するスイッチは，既設の L3SW とした。

図1 の概要

L3SW1，L3SW2 で設定されている VLAN は，全てポート VLAN である。

図1

フロア1では，L3SW1 の下に2つの LAN セグメントがあり，一つ目のセグメントには L2SW11〜L2SW15 と PC（複数台），二つ目のセグメントには L2SW21〜L2SW25 と PC（複数台）がある。

L3SW1 は，フロア1の2つのセグメントをそれぞれポート VLAN として収容している。L3SW1 の空きポートを2つ使い，それぞれを各セグメントの VLAN に設定して通信制限装置の LAN ポート1，2 につなげば，通信制限装置は1台で両方のセグメントの ARP を監視できる。LAN ポートは番号の小さい順に使うので，LAN ポート3，4 は空きになる。

タグ VLAN を使わないので，1本の配線で2つのセグメントにつなぐことはできず，2ポートを使う。フロア2の装置なら，同じように L3SW2 に2ポートでつなぐ。

間違えやすい点。設問は“1 台を対象として”いるので，解答例は L3SW1 と L3SW1，又は L3SW2 と L3SW2 のどちらの組でもよい。LAN ポート1，2 に L3SW1 と L3SW2 を混ぜると，フロア間の配線が要る構成になり誤りになる。

本文の根拠

〔運用の整備〕

また，不正 PC を正常 PC に復帰させる対処を行うために，不正 PC を接続するセグメント（以下，対処用セグメントという）を，フロア 1 とフロア 2 に追加することにした。

図1 の概要

PC はメンテナンスサーバを利用して，OS やアプリケーションプログラムのアップデート，ウイルス定義ファイルのアップデートなどを行う。

図1 の概要

S エージェントは，検査結果を PC 管理サーバに登録する。

不正 PC は S エージェントの検査結果が不合格の PC である。正常 PC に戻すには，まず OS やウイルス定義ファイルのアップデートなどで問題を直す。これにはメンテナンスサーバとの通信が要る。次に S エージェントが改めて検査し，合格の結果を PC 管理サーバに登録する。PC 管理サーバ上の情報が合格になって初めて正常 PC として扱われ，通信が許可される。

したがって対処用セグメントから許可する通信先は，メンテナンスサーバと PC 管理サーバの2つで足りる。業務サーバなどへの通信は，正常 PC に戻るまで要らない。

間違えやすい点。DHCP サーバを挙げたくなるが，DHCP はセグメント内の L3SW（リレーエージェント）が中継するもので，PC から DHCP サーバへ直接通信するわけではない。二つは順不同で，①②に一つずつ答える。

本文の根拠

図1 の概要

ルーティング情報は，全てスタティックに定義してある。

図1 の概要

① PC の IP アドレスは，DHCP サーバによって割り当てられる。

〔運用の整備〕

また，不正 PC を正常 PC に復帰させる対処を行うために，不正 PC を接続するセグメント（以下，対処用セグメントという）を，フロア 1 とフロア 2 に追加することにした。

L3SW0：ルーティング情報は全てスタティックに定義してある。対処用セグメントは L3SW1，L3SW2 の下に新しく作るので，サーバ室の L3SW0 は，そのセグメント宛てのパケットを L3SW1，L3SW2 に送る経路を知らない。メンテナンスサーバや PC 管理サーバからの応答を対処用セグメントに返せるよう，L3SW0 に対処用セグメント宛ての経路を追加する。

DHCP サーバ：対処用セグメントの PC も DHCP で IP アドレスを受け取る。DHCP サーバには，対処用セグメントで払い出すアドレスの範囲（アドレスプール）を追加する。

変更内容はそれぞれ30字に収める。解答例は24字と22字。採点講評によると，L3SW0 について“対処用セグメントからのパケットをルーティングする設定”とした解答が散見された。サーバ室のサーバ宛ての経路は前からあるので，足りないのは対処用セグメント“へ”の経路である。ルーティングは宛先 IP アドレスで決まる片方向の転送なので，行きと帰りを分けて考える。

採点講評（IPA）

設問4(2)では，L3SW0の設定内容として，対処用セグメントからのパケットをルーティングする設定という解答が散見されたが，対象サーバ宛てのルーティングは，対処用セグメントが追加される前から行われている。ルーティングが宛先IPアドレスに基づいた単方向の転送であることを，よく理解しておいてほしい。